On Mon February 28 2005 09:57, Tony Finch wrote:
On Mon, 28 Feb 2005, Keith Moore wrote:
I agree that it is wrong to reject null return paths altogether. However
your suggestion is incompatible with backscatter detection systems (such
as BATV or Signed Envelope Sender) which assume that null return paths are
only used for bounce messages.
those systems are operating on false assumptions. it's never been the case
that <> was limited to bounce messages.
Yes. It'll be interesting to discover the extent of the interop problems :-)
I think we're going to have to tighten up the rules about null return
paths and bounces, because of the backscatter problem.
could you explain the backscatter problem? I'm not sure what you're
referring
to.
If a spammer or a virus sends out forged email (a "joe job") a certain
proportion of it is likely to be rejected, e.g. because of incorrect
recipient addresses or anti-virus or anti-spam or anti-forgery checks. If
the rejection results in a bounce message the bounce will be sent to the
apparent sender of the message, who is an innocent third party and the
victim of the joe job. These bounces are backscatter from forged spam, aka
collateral spam.
So bounce messages get sent to victims. No specific relationship to
null paths there.
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".