On Mon, 28 Feb 2005, Dave Crocker wrote:
It does not change envelope information. Therefore, if
"rfc2821.rcptto" changes, a new message was created.
I should note that there is some controversy to this assertion. I
think most people would not expect to call this a new message.
My reason for claiming that it IS is that the .forward mechanism really
should take responsibility for originating the message. Any handling
that occur after that cannot be viewed as the responsibility of the
content originator or the original rfc2822.sender.
No. .forward forwarder is just an agent of the recipient. The responsibility
for the message is still the same - its the responsibility of whoever
created that message and its content and its still the same message too.
The issue I addressed was the supposed SPF forwarder problem.
There is no such problem. Once a message is no longer directed
to the original RFC2821.RcptTo, the message was delivered.
Internet Email is not Instant Message, current email system is more
complex and message is not delivered until MDA puts it in the mailbox.
And up to that point it may go through many systems, some of them simple
relays, some relays that add "Sender:" some forwarders that change
rfc2821.rcpto and may change other things, some mail lists (chaning
rfc2821.rcpto, rfc2821.mailform and often Sender) and its still the same
message with same Message-ID and would have same content (with few
exceptions like additionals of footer done by mail lists or meta-tag
added to subject).
Unfortunately, that's not quite true.
The challenge of registering all the forwarding sites in a domain
record associated with an rfc2822.from or RFC2821.MailFrom is actually
quite daunting.
Yep.
This difficulty is directly due to what is best viewed as a layer
violation. The authenticating agent is at a layer above the
authenticated identity.
More like multi-layer violation - not that it makes any difference :)
In the case of forwarding, it even requires correlation across multiple
postings!
That I disagree with, it is still the same "posting", although as
"posting" is not defined maybe we understand this term differently.
When the message is given to a forwarder, it is delivered.
To stay in terms of the crocker draft: the MTA on the
forwarder's domain is "Dest" and the process rewriting
the envelope, thereby changing the rfc8221.rcptto, and
submitting a message again is the "Recipient" and also
the "Originator" of a new message.
Well, that's what makes forwarding interesting. Typically, it does NOT
change the Originator.
Nor should it.
Note: I do not view changes to RFC2821.MailFrom done by SRS as changing
the Originator - the originator is still the same and embedded as part
of srs, but actual rfc2821.mailfrom address is rewritten so that path
authentication does not fail, its a track and basicly return to rfc821
source routes.
Whether it changes the rfc2821.mailfrom apparently is not all that
straightforward, with the obvious determining question being "where
should bounces and other notifications go?"
Where do you expect them to go? Of course, to the person who send the
email! You don't expect postal mail that was forwarded because you
changed addresss to be returned to the post office that forwarded
it do you? No, you expect it to be returned to the original person
whose address appears on the upper right corner ("From:" address
if you're not familiar with US Post).
When the "Source" is faked to be the original rfc2821.mailfrom,
MailFrom does not specify Source.
It kind of both does and does not. Like with postal mail, we only
have "From:" address on the envelope and its where the bounces go to,
but its also who/what is considered to be source of that mail.
We really should separate the concepts though, but I fear it will
require agrreed upon change to email architecture and trying to do it
with "clarifying" draft like you're trying is not a way to go - the
issue is bigger then just clarification.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net