wayne wrote in mxcomp (MARID):
http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt
That's the first time I see this. It's not on the page with
the MARID drafts (see <http://purl.net/xyzzy/-ietf/marid>),
it's not on <http://spf.pobox.com/rfcs.html>, IIRC it was not
published on the SPF announce list, and if it was mentioned on
the SPF-discuss list I must have missed it:
| Comments on this draft are welcome. In the interests of
| openness, before contacting the authors directly, please
| post to the spf-discuss mailing list.
The date says July 12 2004. The algorithm is incompatible with
SPF classic, therefore it cannot be used with existing v=spf1
sender policies.
| There are no changes in semantics to existing protocols
That's not true.
IP okay for xyzzy: SPF classic SPF/FROM-HDR
MAIL FROM:<valid(_at_)xyzzy> PASS PASS only if whitelisted
2822 From:<some(_at_)example> don't care (FAIL => test MAIL FROM)
IP not okay for xyzzy: SPF classic SPF/FROM-HDR
MAIL FROM:<user(_at_)MSA(_dot_)test> UNKNOWN (UNKNOWN in step 3)
2822 From:<valid(_at_)xyzzy> don't care FAIL (step 5)
IP okay for spam(_at_)test: SPF classic SPF/FROM-HDR
MAIL FROM:<forged(_at_)xyzzy> FAIL don't care
2622 From:<spam(_at_)test> don't care PASS (step 1)
I'm not really interested in the 1st example, because I don't
use arbitrary 2822 From headers with a SPF-protected MAIL FROM.
But the 2nd example is real and almost the same problem as with
Sender-Id. In fact it's even worse because Sender-Id at least
allowed to use a matching Sender:<user(_at_)MSA(_dot_)test> to bypass its
2822 From:-test.
And the 3rd example is evil, SPF/FROM-HDR results in a PASS,
but the bounce for this spam is later sent to a 3rd party (?)
What's the purpose of step 2 spf_test(To:,IP) ? Bye, Frank