On Mon, 13 Sep 2004, Jim Lyon wrote:
On Monday, September 13, 2004 at 1:47:32 AM. William Leibzon quotes RFC
2822 and argues that SenderID's use of Resent-From is inconsistent with
RFC 2822. I disagree.
RFC 2822 specifies Resent-From is not for "forwarding", in either of the
following two senses:
1. Quoting from RFC 2822:
One sense of forwarding is that a mail reading program
can be told by a user to forward a copy of a message to
another person, making the forwarded message the body
of the new message. A forwarded message in this sense
does not appear to have come from the original sender,
but is an entirely new message from the forwarder of the
message.
This sense of "forwarding" is normally activated by a user
pressing a "Forward" button in a UI (or similar action.) I
completely agree that "Resent-From" has no place in this sense
of forwarding.
I also agree with your interpretation of above quoted RFC2822 text.
2. Quoting from RFC 2822 again:
On the other hand, forwarding is also used to mean when
a mail transport program gets a message and forwards it
on to a different destination for final delivery.
I believe that what RFC 2822 refers to here as "forwarding" is
what we today more commonly refer to as "relaying". That is,
when an MTA merely accepts a message destined for a particular
mailbox, and sends the message along to another MTA because
the first MTA doesn't own the mailbox.
I disagree with your interpretation here. I think RFC2822 may have meant
that use of Resent-From is inappropriate in all cases of forwarding,
including for example when MTA finds that new email address is contained
in its configuration (like /etc/aliases on unix systems) and has to
forward the message further. I note that sendmail for example treats
forwarding based on aliases in quite similar way to relaying.
I would also like to add that RFC2822 may indicate that use of Resent-From
is inappropriate for forwarding by other text as well. In particular
the original use of From header is indicated as follows:
3.6.2. Originator fields
In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message
That clearly implies that "From:" is to be used to indicate only the
author of the message and not anybody else. I understand that we're
talking about "Resent-From:" (and not "From:"), but when RFC2822
first introduces Resent fields it seems to indicate that their use
should be comparable to the original fields, i.e.:
3.6.6. Resent fields
Resent fields SHOULD be added to any message that is reintroduced by
a user into the transport system. A separate set of resent fields
SHOULD be added each time this is done.
...
Each of the resent fields corresponds to a particular field elsewhere
in the syntax. For instance, the "Resent-Date:" field corresponds to
the "Date:" field and the "Resent-To:" field corresponds to the "To:"
field.
I note that in above quoted text RFC2822 seems to indicate that use of
Resent fields is only appropriate if message is reitroduced by the user
(and its not clear how that implies in case of MTA is doing forwarding
as in example I provided above). Additionally it seems to imply that
Resent fields have the same meaning as original fields which I take
as position that Resent-From field may only be used by user who is
willing to become new author of the message (but does not make any
alterations to the content when forwarding the message). I do not
believe this applies to the case when user is the original recepient
and when MTA automaticly uses his email when adding Resent-From.
The position that this sense of "forwarding" really means
"relaying" is bolstered by the fact that RFC 2822 nowhere
contains the words "relay" or "relaying".
I completely agree with RFC 2822 that "Resent-From" has no place
in this sense of forwarding.
I also agree that "Resent-From" headers should not be used in this
situaton.
I would however add that some cases of such relaying email may pass
through network boundary and in such situation the existing PRA algorithm
can fail.
For example email recepient may use several secondary MX servers
that are not on his network or controlled by it. When email comes
in first to one of those secondary MXs, the secondar MX servers
maybe able to verify email based on PRA algorithm (i.e. it comes
directly from the Sender and only has "From:" header and that header
has domain address for which SPF record lists ip address of the sender
system). Now when this secondary MX has to relay the email to primary
MX (which lets say for simplicity is only MTA in destination network),
then secondary MX per your understanding about relaying should not
add new new "Resent-From:" or other header. In such a case the
primary MX when it finally receives the email would still derive
same PRA address based on the headers, but ip address would be
that of secondary MX server and would fail SPF test. Now I'm hoping in
this case the primary MX would be smart enough to recognize that its
one if its secondary MX servers and whiltelist the email, but I can
imagine there could be different simular scenarios where such thing
would no longer work properly and where use of PRA would fail when
relaying between independent networks is involved.
It would probably be a good idea for Pete Resnick (editor of RFC 2822)
to chime in on this interpretation.
Indeed his help in interpreting RFC2822 would be much appreciated.
And if he's willing to do it, I would also be interested in seeing his
interpretation on if PRA algorithm represents an obvious derivitive
or interpretation of RFC2822.
In particular I note that RFC2822 says in section 3.6.2:
The "Sender:" field specifies the mailbox of the agent responsible for
the actual transmission of the message. For example, if a secretary
were to send a message for another person, the mailbox of the secretary
would appear in the "Sender:" field and the mailbox of the actual author
would appear in the "From:" field. If the originator of the message can
be indicated by a single mailbox and the author and transmitter are
identical, the "Sender:" field SHOULD NOT be used. Otherwise, both
fields SHOULD appear.
That clearly indicates that when email leaves MSA, the Sender field
should correspond to the "originator of the message". And if it is
not there, we can assume that it would have been the same as "From:"
and that is why it was omited.
Now during processing email may have been reintroduced by user and
in such cases Resent headers would have been added. As per text
I already quoted, these headers carry similar meaning as original
"From:" and "Sender:" headers, so if they are present, the top set of
these headers would (in some, but not all cases) correspond to the the
latest reintroduction and so if Resent-Sender and Resent-From are present
they should be checked in the same order and same way as original
Sender and From. So what we get is the following order:
1. Resent-Sender (only if present as part of set together with Resent-From)
2. Resent-From
3. Sender
4. From
And that is pretty much what PRA algorithm has listed.
And to me this all does not even appear to apply a derivitive, but simply
an interpretation of RFC2822 when looking for information of the party
responsible for last introduction of email by some user.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/