> If verification involves some kind of callback then the sending site
> (webmail.com) can track the number of copies of a given message that have
> been received. It can then revoke its signature if a threshold is passed,
> or rate-limit verifications if the spam decision isn't clear.
Part of my hand-wringing included this thought and I quickly
shuddered at the thought of the scaling implications, not to
mention DDOS opportunities.
But there are technical ways to stop replays that don't involve callbacks.
Those of you within ASTA may recall the DK "audit" draft we circulated about a
year ago. As always though, there are trade-offs.
First it adds considerable complexity which adds yet another barrier to entry
of a new specification. Second, the solution can be retrofitted so it makes
sense to avoid solving a theoretical problem until we're sure it's a practical
problem. Third, there are semantic and performance trade-offs that may cost
more than the benefit. Fourth, this type of replay is relatively uninteresting
as evidenced by the need of most email abusers to include word-salad in their
payload. Finally, mitigation can be relatively effective due to the inability
of a replay to modify any of the signed headers.
A slightly different problem is the cut-n-paste attack on canonicalization that
may defeat some of the anti-replay strategies - this is one reason why I tend
to shy away from compromises in this area.
Mark.