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.
A more lightweight and scalable alternative is needed for Internet-wide
deployment.
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).
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.
I've written more on this topic elsewhere:
http://www.cus.cam.ac.uk/~fanf2/hermes/doc/talks/2005-02-ukuug/
http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/cam.txt
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
HUMBER: SOUTHWEST 5 OR 6 BECOMING VARIABLE 3 OR 4. RAIN OR SLEET. MODERATE OR
GOOD.