[Top] [All Lists]

Re: 2821bis and address rewriting

2007-11-20 11:44:58

On Nov 19, 2007, at 4:36 PM, Dave Crocker wrote:

Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
are reasons for not messing with null return paths, including their being an important clue for various automated programs, that has nothing to do with mail loops (at least directly).
Amen to that. Over the years, I've had to explain to a *lot* of people that "No, that piece of mail with MAIL FROM:<> isn't a bounce message. Yes, it's correct". Seems people have problems wrapping their tiny little brains around the idea that <> is useful for other things

Or rather, it is useful for exactly its primary purpose, which is to signal that error messages are not to be returned.

The problem is that we have overloaded that construct with more semantics, such as "this is a bounce message" and then done it inconsistently.

Almost makes one wish that real bounce messages were distinguished by something other than the 2821.mailfrom address...

Indeed. Despite possible loss of diagnostic information regarding use of RFC3464 where original message content is omitted (including subject line), a spartan DSN would be a means to restore order. Any exception to the omission of content could be exploited.

Currently tens of million of different servers each day are exploited to send messages where the 2821.mailfrom has been spoofed. Adhering to RFC3464 and omitting original content is a safe means to mitigate this abuse, where adherence can be enforced through reputation lists filtering null 2821.mailfrom messages. Such a practice would likely drive a need for MUAs able to recognize valid DSNs, while also lessening payloads associated with bad actors attempting this exploit.