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