The following is the PRA algorithm from the current draft:
-------------------------------------------------------------------------
1. Locate the first non-empty Resent-Sender header in the message.
If no such header is found, continue with step 2. If it is preceded
by a non-empty Resent-From header and one or more Received or
Return-Path headers occur after said Resent-From header and before the
Resent-Sender header, continue with step 2. Otherwise, proceed to step 5.
2. Locate the first non-empty Resent-From header in the message. If a
Resent-From header is found, proceed to step 5. Otherwise, continue with
step 3.
3. Locate all the non-empty Sender headers in the message. If there are
no such headers, continue with step 4. If there is exactly one such
header, proceed to step 5. If there is more than one such header,
proceed to step 6.
4. Locate all the non-empty From headers in the message. If there is
exactly one such header, continue with step 5. Otherwise, proceed to step 6.
5. A previous step has selected a single header from the message. If
that header is malformed (e.g. it appears to contain multiple mailboxes,
or the single mailbox is hopelessly malformed, or the single mailbox
does not contain a domain name), continue with step 6. Otherwise, return
that single mailbox as the Purported Responsible Address.
6. The message is ill-formed, and it is impossible to determine a
Purported Responsible Address.
-------------------------------------------------------------------------
The algorithm looks at the following headers in order:
1. First non-empty Resent-Sender.
2. First non-empty Resent-From.
3. Sender.
4. From.
The PRA draft states that:
"Note that steps 1 and 2 above extract the Resent-Sender or Resent- From
header from the first resent block (as defined by section 3.6.6 of
[RFC2822]) if any. Steps 3 and 4 above extract the Sender or From
header if there are no resent blocks."
RFC 2822 is clear that (section 3.6.6):
"Each of the resent fields corresponds to a particular field elsewhere
in the syntax."
Therefore, Resent-Sender and Resent-From correspond to "Sender" and
"From" headers. Precendence of "Sender" over "From" and by extension of
"Resent-Sender" over "Resent-From" is clear from section 3.6.2 of RFC 2822:
"The originator fields of a message consist of the from field, the
sender field (when applicable)"
and
"The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible for
the writing of the message. The "Sender:" field specifies the mailbox
of the agent responsible for the actual transmission of the message.
"
As we all know, all RFCs are under intellectual property of the IETF and
held by ISOC.
More prior art, for example documentation for fetchmail written by ESR
states as follows (http://catb.org/~esr/fetchmail/fetchmail-man.html):
--------------------------------------------------------------------------
INTERACTION WITH RFC 822
When trying to determine the originating address of a message, fetchmail
looks through headers in the following order:
Return-Path:
Resent-Sender: (ignored if it doesn’t contain an @ or !)
Sender: (ignored if it doesn’t contain an @ or !)
Resent-From:
From:
Reply-To:
Apparently-From
--------------------------------------------------------------------------
The only difference from PRA is the fact that Sender appears before
Resent-From.
RFC 3028 which defined SIEVE has the following (section 5.1):
--------------------------------------------------------------------------
"5.1. Test address
Syntax: address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE]
<header-list: string-list> <key-list: string-list>
The address test matches Internet addresses in structured headers
that contain addresses. It returns true if any header contains any
key in the specified part of the address, as modified by the
comparator and the match keyword.
....
Implementations MUST restrict the address test to headers that
contain addresses, but MUST include at least From, To, Cc, Bcc,
Sender, Resent-From, Resent-To, and SHOULD include any other header
that utilizes an "address-list" structured header body.
--------------------------------------------------------------------------
I didn't have the time, but we can check any of the implementations
listed on http://www.cyrusoft.com/sieve/ to see the exact way they do
it. I wound guess that they following a similar algorithm.
SpamAssassin configuration file
(http://spamassassin.apache.org/doc/Mail_SpamAssassin_Conf.html):
--------------------------------------------------------------------------
WHITELIST AND BLACKLIST OPTIONS
whitelist_from add(_at_)ress(_dot_)com
Used to specify addresses which send mail that is often tagged
(incorrectly) as spam; it also helps if they are addresses of big
companies with lots of lawyers. This way, if spammers impersonate them,
they'll get into big trouble, so it doesn't provide a shortcut around
SpamAssassin. If you want to whitelist your own domain, be aware that
spammers will often impersonate the domain of the recipient. The
recommended solution is to instead use whitelist_from_rcvd as explained
below.
.....
The headers checked for whitelist addresses are as follows: if
Resent-From is set, use that; otherwise check all addresses taken from
the following set of headers:
Envelope-Sender
Resent-Sender
X-Envelope-From
From
In addition, the ``envelope sender'' data, taken from the SMTP envelope
data where this is available, is looked up
--------------------------------------------------------------------------
Qmail documentation
(http://qmail.sg.feratech.com/qmail-manual-html/man5/qmail-header.html):
--------------------------------------------------------------------------
SENDER ADDRESSES
qmail-inject looks for sender address lists in the following
fields: Sender, From, Reply-To, Return-Path, Return-
Receipt-To, Errors-To, Resent-Sender, Resent-From, Resent-
Reply-To.
--------------------------------------------------------------------------
iPlanet documentation from Sun
(http://docs.sun.com/source/816-6091-10/contents.htm):
--------------------------------------------------------------------------
The email message's originator address is taken from one of the
following five sources, shown in decreasing order of preference:
1. Resent-from: 4. Sender:
2. From: 5. Envelope From:
3. Resent-sender:
--------------------------------------------------------------------------
Another piece of code
(http://email.uoa.gr/projects/fromfilter/doc/fromfilter.html):
--------------------------------------------------------------------------
For now, the only headers we are interested in are From and Sender or,
if this message has been forwarded and the sender has retained the
original headers, the Resent-From and Resent-Sender.
--------------------------------------------------------------------------
Another example (http://h71000.www7.hp.com/wizard/wiz_7493.html):
--------------------------------------------------------------------------
(The list of SMTP return addresses that are checked for and used by
OpenVMS include the following (ordered) list of fields:
Resent-Reply-To
Resent-From
Reply-To
From
Resent-Sender
Sender
Return-Path)
--------------------------------------------------------------------------
The only differences are order of fields and some semantics. I am sure
there are more examples.
Yakov