Meng,
MWW> My working interpretation of 2821.mail-from, under the new paradigm, is:
I think you mean "new specification" rather than "working
interpretation", since you are significantly changing the real-world
semantics of the string.
At that, your definition does not require the actual string value
2821.mailfrom to have anything in common with 2822.sender. This seems
to be different from Pete's view.
In any event, one should be very careful about making a significant
change to such a fundamental bit of semantics for a service with a very
large installed base.
Typically, new semantics need to be introduced in new fields. In this
case, it is also essential to avoid overloading a field with competing
semantics. A bounce address necessarily needs to be independent from the
address that is held accountable the message.
MWW> In a direct model, the mail-from is often the author of the message.
"Often" is not the same as "required to be".
MWW> In application-level store-and-forward, such as mailing lists and
MWW> acm.org forwarding, the 2821 should change, because the entity
MWW> responsible for *originally* injecting the message into the mailstream
"Should" is not the same as "must be". There are valid and reasonable
scenarios in which the bounce address -- and even the "responsible"
address -- is be retained.
MWW> In transport-level store-and-forward, such as intramural relaying to a
MWW> smarthost or deferral relay, the entity does not change. These paths
MWW> include MTA1 to MTA2, and MTA9 to MTA10.
If you mean mail transfer-level, the question of where the
boundaries of responsibility are can certainly get interesting. The
exact roles, responsibilities at such boundaries should be considered
extremely carefully, since the classic email model does not deal with
them at all. The closest that we come to such boundaries are email
gateways, which means that they are application translation devices and
can do anything they want.
If you meant something else, by "transport-level", then please explain.
At any rate, if we want to specify some new sort of entity that is more
than a basic MTA and less than an all-powerful gateway, that's fine, but
it is a discrete and ambitious task.
MWW> The 2821.mail-from is often the entity interested in receiving message
MWW> delivery or nondelivery notifications.
No. It is _always_ the entity designated to receive those notifications.
In fact, that is only and exactly the current, real-world meaning of
that field.
MWW> In the case of direct mail,
By "direct mail" do you mean a single SMTP hop between originator and
recipient? I'm trying to think of the last time I saw a message with a
Received trace that showed only one hop.
Nope. Can't recall it.
MWW> nondelivery notifications go to the sender who is also the author.
That is a very, very long way from a requirement in the current email
service. And it constitutes a significant change to that service.
MWW> In
MWW> the case of a mailing list, nondelivery notifications should go to the
MWW> MLM, which needs to monitor the deliverability of the destination
MWW> address for purposes of eventual unsubscription.
That is the most common scenario for mailing lists, yes, but it is not
the only valid and reasonable scenario. For example, a collaborative
group that has shared responsibility for the mailing list, could quite
easily designate bounces to be the responsibility of the originator.
MWW> In the case of mailing lists, 2821.mail-from rewriting already
A mailing list is a user-level service. It is not "re-writing" mailfrom.
It is setting a new value, when the mailing list when it does the new
submission.
MWW> The rise of LMAP/MARID sender verification imposes a new semantic on
MWW> forwarding services: where previously they got away with pretending to
MWW> be transport-level store-and-forward, they are unmasked as
MWW> application-level store-and-forward.
They've always been application-level.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>