On Tue, 2006-03-28 at 18:26 +0000, Julian Mehnle wrote:
As far as I could see from reviewing your webpage, your solution suffers
from the replay problem (apart from a weak datestamp verification). Did I
Yes. You missed the fact that it doesn't matter. It's not designed for
authentication -- it's designed to protect me from the flood of bounce
spam, and it's done that perfectly effectively. It allows me to identify
some mail as being _definitely_ fake, and thus allows me to reject that
As an added side-effect, it gives third parties a way to reject faked
mail too -- but that's just a coincidence. People who bother to do
sender verification callouts just get that benefit automatically.
SPF offers 'yes' and 'maybe' answers to the question of whether a sender
address is genuine. For reasons which have been discussed at length
already, it can't offer a 'no' answer with 100% reliability.
In contrast, BATV &c offer 'no' and 'maybe' answers, and it's the 'yes'
answer which it can't give with 100% reliability -- as you've observed,
there's a slight possibility of a replay attack.
SES attempted to make the whole thing more complex to deal with that,
and in my opinion that added complexity was pointless. It just doesn't
matter -- the crap which SES added to turn the final remaining 'maybe'
answers into 'yes' answers was just not worth it. IMO.
The point is that I want to be able to _reject_ unwanted incoming mail.
And for that, the 'yes' and 'maybe' answers aren't helpful. It's only
the 'no' answer which is useful to me.
This is because because a reliable 'no, this is crap' answer means I can
certainly reject it safely, while the 100% 'yes, this is authentic' is
only really useful in conjunction with a reputation database.
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
please go to