Meng Weng Wong wrote:
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.
Apparently, there are aspects of this position that give some of us
problems.
MAIL FROM seems to be generally considered as supplying a suitable
destination for delivery failure reports applying to a particular injection
into the MTS (NB, I don't say "message", as this can lead to confusion). So
of course, it need not be the author, it can be an entity asserted by the
author to be their "agent" in this, or the role may asserted by (? claimed
for?) any other entity. We're interested in identifying false assertions.
I'm not certain that a "new paradigm" is called for, although I can imagine
that it must be intoxicating to feel that one is the champion of such a
thing.
In the interest of consensus (and to avoid rehashing some old discussions),
it might be better if we leave out "responsibility". It's not clear to me
that it's crucial in what we're trying to do, which is to provide a means
of determining if a domain is "happy" to have its name used in this field.
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.