Re: MTS transparency and anonymity

> > 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.
> 
> We've found that SMTP call-back return path verification is quite
> effective, though it has very nasty behaviour for the victims of joe jobs.

I have somewhat different experience - I've found that SMTP call-back 
verification often produces unnecessary failures, as it's not unusual for
the sender's SMTP server to fail to respond promptly even though the 
message is legitimate.
 
> Detecting backscatter by inserting a cookie in the return path does have
> the right incentives: it can be implemented unilaterally by a site and
> should be effective without co-operation from the rest of the Internet
> (though we need to study its interoperability in more detail).

Yes, there are lots of dragons here.  

> If you couple this with a means for recipients to find out whether to
> expect a cookie, and to verify one if it is present, then you have a
> general return path authentication system. However this idea has a number
> of security holes in the area of replay attacks and message modification
> attacks, so it is not a panacea. It's also skating very close to the
> territory of DomainKeys and IIM so working on it might be a pointless
> duplication of effort.

It's very close to IIM.   Though IMHO all of these systems are
"not ready for prime time" and it's way too early to try to avoid 
duplicating effort. 

Keith