Section 6 seems particularly interesting. However, its title says
"Preventing the replay attack." I do not believe this is
accurate as
the approach is really about limiting the damage of a replay attack
once detected. That being said, this seems like a simple
idea with low
overhead.
Thank you for posting these drafts. I considered that by
being able to significantly limit durations of a replay
attack, this would act as a preventative or deterrent. But
you are right, it is not absolute and "preventing" overstates
what this does. I should have said "abating" the replay attack. : )
It is almost certainly sufficient to address the problem.
If you monitor lookups to the DNS server you can see the number of queries
being made and thus spot anomalies. If you have a bazillion lookups to a
particular email and you are an open webmail provider you are probably
looking at a spam issue.
I would expect the lookup to be done twice per message, once at receipt by
the incomming edge service and again when it is being read by the end user.
There is likely to be an average of an hour delay so it is not too difficult
to trap a LOT of spam that way.
The replay issue is not a significant concern wrt phishing attacks. Domains
subject to phishing do not as a general rule offer open access.
To see the stakes take a look at:
https://www.bankbii.com/information.asp