On Sun, 6 Mar 2005, Bruce Lilly wrote:
So bounce messages get sent to victims. No specific relationship to
null paths there.
Except that, as you say:
Bounce messages themselves are supposed to be sent with a null return
path. That's intentional, to prevent looping bounce messages.
If a spam message were to be sent with a null return path, there
would be no bounce. I know of no rule that prohibits setting a null
return path for a message other than a bounce message. If there were
such a rule, loosening it would seem to be an improvement (would
result in less collateral damage).
Could you explain what you had in mind w.r.t. "tighten up the rules
about null return paths".
I would like the rule to be that a null return path MUST only be used for
an auto-response (which includes DSNs and other kinds of bounce) and MUST
only be used with a recipient address which is the return path of the
message that triggered the auto-response.
With a system like BATV, messages with a null return path that are not
sent to a valid return path are rejected as forgeries, because BATV
enables a site to distinguish valid and invalid return paths.
If you encourage people to use null return paths for normal messages and
spam, then you eliminate the possibility of using something like BATV to
detect collateral spam. You directly encourage people to treat email as an
unreliable transport, and by removing any means of dealing with collateral
spam you indirectly encourage people to just ignore and disable email's
error reporting mechanisms, which turns the perception of unreliability
I intend to find out (by practical experiment) how common it is for
non-bounce messages to use null return paths, in order to assess the gap
between reality and the proposed tighter null return path rule.
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
DENMARK STRAIT: SOUTHWEST 4 OR 5, OCCASIONALLY 6 IN THE EAST AT FIRST,
BECOMING VARIABLE 3 OR 4 IN THE WEST. MAINLY FAIR, BUT RAIN IN THE SOUTHWEST.
MODERATE OR GOOD, BUT POOR IN THE NORTH.