Re: MTS transparency and anonymity

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".