On Nov 19, 2007, at 4:36 PM, Dave Crocker wrote:
Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
There
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.
-Doug