"Seth Goodman" <sethg(_at_)GoodmanAssociates(_dot_)com> writes:
Hope this helps (and I hope Meng will correct me if it's wrong).
Sure, that's a fine explanation, but I believe everything I said still
remains true. In particular,
An SPF result of PASS means go on to DATA, go through the headers,
extract PRA and make sure PRA == (address used for SPF check). If it
doesn't, reject the message at the end of DATA. If it does, accept
the message.
making sure that PRA == (address used for SPF check) is not enough
because that there may be more than one sender address displayed by MUAs
or MUAs might only display one sender address and it could be one that
was not SPF verified, etc.
Also, DAVE is only a minor optimization that lets you make the SPF query
a few lines earlier and delay the header groveling a moment, but
(especially after flag day) most bad people aren't going to happily
comply and let people reject via SPF in the SMTP envelope. That's just
wishful thinking. DAVE seems to be mostly be there for warm and
fuzzies. I can see why people give Microsoft a hard time about putting
XML into DNS, but they totally got it right about RFC 2822 being the
thing that matters.
If I'm a smart phisher, I'm definitely going to make sure every
implementation dots every i and crosses every t. With the current "new
SPF" proposal, you can't even cross a t let alone dot an i.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/