Hector Santos wrote:
Sorry, Hector, I think that's hogwash.
Niceeeeeee!
Yeah, my flame thrower was hot after I read Dave's statement:
| The field does not define a sender. It defines a receiver.
<http://permalink.gmane.org/gmane.ietf.smtp/6224>
After considering suggestions for question 1.f in RFC 4858
I somehow managed to attack only your unrelated article. ;-)
[The SHOULD about DSNs in 2821]
Good, because unless you have $60 grand to fund the
reprogramming of our system, it ain't going to happen
anytime soon.
Right, that's your business. We could discuss what a BCP 14
"SHOULD" means, but after that it's still your business, and
nobody proposed to replace it by MUST in 2821bis or UTF8SMTP.
Terminologies, especially in regards to the "BOUNCE ADDRESS",
whether it is RETURN PATH, RETURN ADDRESS, SENDER ADDRESS,
etc, is always going to be understood by SMTP developers and
operators.
Yes, and the fun starts when they understand it differently,
with effects like "accept-and-bounce". Or RFC 1123 5.3.6(a).
When you refer to end-users or even help desk and/or management
or marketing, Envelope Sender Address doesn't guarantee
understanding as much as anything else.
It's not difficult to figure out "envelope sender address",
it fits into the usual snail mail analogies. It's also hard
to come to a wrong understanding, e.g. confuse it with a PRA
or a 2822-Sender.
Return Address or Sender Address is probably the BEST choice
"Sender Address" is even worse than "Bounce Address", the 2822
Sender isn't necessarily related to the envelope sender.
"Return address" might work. It kind of misses the point that
there's a responsible actor, the "originator", who submitted
the mail and has to deal with the consequences of this action,
like error reports and other auto-replies.
"Return path" and "return address" are not exactly identical.
IMO "envelope sender address" is a modern term for what used
to be known as "return path", but isn't a path anymore.
Frank