Re: MTS transparency and anonymity

> > the best way I know to deal with that problem is to recognize bounces
> > (not just by return-path but by message format) and to correlate them with
> > a Sent IMAP mailbox.
> 
> This is just another variant of including a cookie in outgoing email which
> you check for in the bounces that come back.
> 
> Putting the cookie in the message data doesn't work in general because
> many bounces are unparseable, or they don't include enough of the original
> message. The extreme example of this is vacation messages which usually
> include nothing of the original; also some bounces have extremely
> abbreviated copies of the original header.

putting the cookie in return-path might work better.   putting it elsewhere
in the envelope would be cleaner, but would require all MTAs in the path 
to be upgraded before it became useful.
 
> > more ideally, return-paths would be authenticated (in the sense that the
> > sender needs to be able to demonstrate he has the right to use that
> > return-path), and MTAs wouldn't bounce messages that failed authentication.
> 
> This is the fallacy of universal deployment: you can't assume that
> everyone will upgrade their systems to conform to best current practice,
> so you can't rely on BCP to eliminate backscatter.

the usual trick is to try to arrange things so that those who do upgrade
their systems will see an immediate benefit - i.e. to put the incentives
in the right place.  I think this would be true for RP authentication -
MTAs today see a substantial load from boucing forged mail.

Keith