ietf-mxcomp
[Top] [All Lists]

my working definition of 2821.mail-from

2004-05-11 14:20:37

On Tue, May 11, 2004 at 01:57:39PM -0700, Dave Crocker wrote:
| 
|   In any event, we need to establish a very explicit working group rough
|   consensus about the semantics of RFC2821.MailFrom, given its
|   fundamental role in working group discussions.

My working interpretation of 2821.mail-from, under the new paradigm, is:

    2821.mail-from should identify the entity willing to accept
    responsibility for the presence of the message in the mailstream.  It
    does not describe the author of the message, and does not necessarily
    identify the entity willing to accept responsibility for the content
    of the message.

Diagram: http://spf.pobox.com/mailflows.html

In a direct model, the mail-from is often the author of the message.
This path is MTA2 to MTA9.

In application-level store-and-forward, such as mailing lists and
acm.org forwarding, the 2821 should change, because the entity
responsible for *originally* injecting the message into the mailstream
is different from the entity responsible for *reinjecting* the message
into the mailstream.  These paths include MTA6 and MTA7.

In transport-level store-and-forward, such as intramural relaying to a
smarthost or deferral relay, the entity does not change.  These paths
include MTA1 to MTA2, and MTA9 to MTA10.

The 2821.mail-from is often the entity interested in receiving message
delivery or nondelivery notifications.  In the case of direct mail,
nondelivery notifications go to the sender who is also the author.  In
the case of a mailing list, nondelivery notifications should go to the
MLM, which needs to monitor the deliverability of the destination
address for purposes of eventual unsubscription.  In the case of
acm.org style forwarding, nondelivery notifications are of interest to
both the original sender/author and the forwarding service: the
original sender needs to try sending their message through an
alternative channel, and the forwarding service needs to monitor the
deliverability of the destination address for purposes of eventual
deactivation.

In the case of mailing lists, 2821.mail-from rewriting already
satisifies the above relationship.  Encapsulation as provided by SRS
would satisfy the requirements of forwarding services.

The rise of LMAP/MARID sender verification imposes a new semantic on
forwarding services: where previously they got away with pretending to
be transport-level store-and-forward, they are unmasked as
application-level store-and-forward.  The difference is that
application-level forwarding is sensitive to the localpart of the
forwarding alias, and transport-level forwarding is generally
insensitive to the localpart if not the domain part as well.  In the
case of a mailing list, the localpart of the forwarding alias is the
name of the mailng list.  In the case of acm.org, the localpart is a
user-specific string defined at the application level of the service.