[Top] [All Lists]

Re: Bounce address

2007-10-16 07:16:40

Frank Ellermann wrote:
Hector Santos wrote:

My only opposition to using exclusively the NDN terminology
(because it better matches Moore's document), is the possible
notion that Moore's RFC might be interpreted to mean it is
now an SMTP requirement which is it not.

Sorry, Hector, I think that's hogwash.


RFC 2821, I-D.2821bis,
UTF8SMTP, and Dave's I-D already have NORMATIVE references to
some DSN RFCs (if that's what you dub as "Moore's RFC").  It's
actually a SHOULD in RFC 2821 and I-D.2821bis.

Good, because unless you have $60 grand to fund the reprogramming of our system, it ain't going to happen anytime soon.

Using a term like "envelope sender address" won't twist this
SHOULD into a MUST, and avoiding this term won't twist it into
a MAY.

Look Franky.

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.

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. Return Address or Sender Address is probably the BEST choice since it at the very least matches the real world snail mail concept.

But Bounce Address has always work and continue to work in the context of whom you are communicating with.

Furthermore and more importantly which seems to have been forgotten here, it is 100% independent of any other PROTOCOL, including any phantom ones that are spoken as if they are standards and embedded in our lives - they are not.

Finally, BOUNCE traditionally has a very special meaning. It means the entire message was literally BOUNCED back to the sender. The STYLE in which it is done has changed (i.e, DSN) but it is still a BOUNCE.

There is a BIG technical difference between BOUNCE and the idea of a "Non-Delivery NOTIFICATION" in which the latter does not necessarily have to include the original content.

So I could careless what you guys which want to do with semantics. I prefer the improvements in the automations of the systems. I prefer technical documents, not just for me, but the future that spells on the possibilities, and in the case of a message rejection, the idea of echoing back the original message vs sending just a notification should be want is discussed.

I hope the above hogwash taste better. :)


Hector Santos, CTO