I agree with Frank here: we should *not* spend a lot of time on this.
If there are any *specific* cases where the use of "sender" is
ambiguous, please raise them, and they can be fixed.
Otherwise, this one is not a priority.
Tony Hansen
tony(_at_)att(_dot_)com
Frank Ellermann wrote:
John C Klensin wrote:
Would it be possible to use SMTP-Sender instead of just sender?
Possible? yes. I'll have to leave to others to figure out if
this is a priority.
Maybe a case by case approach, not a global modification effort.
Anything related to terms like "sender", "originator", "return
path", "reverse path", etc. is obviously critical, their meaning
in RFC 821 depends on the original design, and the context when
it was designed.
Nobody would try "mail from B" for mail actually sent from A with
the known exceptions like "different local part is okay", or "as
long as A and B are behind the same MX it's fine". It would be a
bad plan if something on the route from A to the receiver doesn't
work, to introduce an unrelated route to B for the error reports.
An additional route is a potential source for more trouble, and
if error reports don't make it they're lost, empty reverse path.
All considerations in this direction were likely "obvious" when
RFC 821 was written, it could afford to be sloppy with some terms.
What should a "mail from" be, certainly no arbitrary "bounces to"
a 3rd party. From the ten or more aliases of this beast I think
"envelope sender" as used in RFC 3461 is the best. It avoids any
confusion of (2)821 and (2)822, it doesn't mention the less clear
"from", it doesn't talk about reverse paths and return routes, and
it says "sender", the entity found guilty to have sent a mail. On
whose behalf it sent the mail is beside the point. The "envelope
sender" is related to the header field (Resent-) Sender, i.e. the
responsible agent for the message. For the "envelope sender" it's
the responsible agent wrt SMTP.
IOW, be careful with those "senders", please.
Everyone should remember that this was supposed to be a quick
effort.
If anybody promised that this would be a "quick effort" then their
definition of "quick effort" is "not as bad as 2026bis, more like
2616bis or 3490bis, nothing to worry about, no grandson-of-1036" :-)
I'd rather just declare the effort to switch to "client-server"
terminology a failure. That would mean going back to the 821
terminology of "sender-SMTP" and "receiver-SMTP"
Possible, but not desirable, "client" and "server" is clear in all
contexts with two MTAs talking. It's somewhat more confusing in
RFC 4408, where "the client" is actually an SMTP-server in its role
as DNS-client of a name server related to the alleged sender. If
you use the client-server terminology only for SMTP, not for DNS,
it should be clear.
not introducing more and entirely new terminology like
"transmitter" or "transmitting-client"
Yes, RFC 2822 uses "transmitter", but it's unnecessary in 2821bis,
and "transmitting-client" would be a mouthful, also unnecessary.
Frank