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.
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.
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.
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.
In the case of forwarding, it even requires correlation across multiple
postings!
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.
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?"
When the "Source" is faked to be the original rfc2821.mailfrom,
MailFrom does not specify Source.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net