Re: [Asrg] More e-mail oddities; SPF thoughts

[Dave Crocker <dhc at dcrocker.net>]

Danny Angus wrote:
> > I've just realized that the .forward capability in sendmail operates
> > differently than my MUA, thunderbird, does when I manually forward..
>
> Two different rules for two different roles, an MTA is actually re-routing
> the original message the MUA is forwarding the content of the message in a
> new message.
> This is how it is supposed to work, whether or not it is a wholly Good
> Thing is another matter.


To drive your point home even further, and with crushingly boring detail:

The .forward mechanism is a cooperative action between the recipient specified 
in the SMTP RCPT-TO envelope address and that recipient's email service delivery 
agent (MDA).  It's effect is to re-submit exactly the same message, with one 
significant difference:  There is a new SMTP RCPT-TO address.  (I am ignoring 
whether there are additional Received headers, because they do not matter for 
this discussion.)  Even though the .forward mechanism uses information created 
by the recipient, it really is best to view it as an enhancement to the email 
transfer infrastructure.

By contrast, the use of a Forward command in an MUA creates a brand new user 
message and adds the previous message to its body.  To stress the key point:  It 
is entirely a user-level activity.  The email infrastructure has nothing to do 
with it, other than the usual process of transferring a new message.  The MUA 
can add the forwarded message as in-line text, as part of a single, unified 
message body, or it can add it as an attachment (the message/rfc822, as 
mentioned earlier.)

A message that is re-routed by .forward is FROM the original author.  A message 
re-routed by an MUA is FROM the user of that MUA.

The "redirect" or "resend" MUA command attempts to perform something akin to the 
action of the .forward function, but the results usually are different and 
variable.  The concept of redirect is, really, to re-assign the message to an 
alternate recipient.  Therefore, the original FROM is preserved -- rather than 
having the FROM address be that of the recipient doing the redirecting, even 
though the user doing the re-directing might add a bunch to the message body, 
such as instructions for how the new recipient is to deal with the message. (The 
FROM field often shows some commentary text to indicate who did the redirecting. 
 There also are some resent-* header fields added.)

d/
--

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg