On Behalf Of SM
Sent: Wednesday, February 25, 2009 7:06 PM
Subject: Concluding the SPF and Sender ID experiments
There is currently an I-D with a proposal to conclude the Sender ID
and SPF experiments. If anyone is interested in these Experimental
RFCs, I suggest that they work on an update and post it as an
I-D. That could help to put a stop to the Sender ID and SPF
discussions that point to problems when running both experiments
If you have any comments about why these Experimental RFCs should not
be moved to historic, I would like to hear them.
I have no problem with RFC4406 and RFC4407 being moved to historic. I've
been asserting that Sender-ID/PRA is broken for quite some time because
of the following in RFC4407 which allows attacks that guarantee a
neutral (through use of the sender field) for malicious messages:
5. A previous step has selected a single header from the message. If
that header is malformed (e.g., it appears to contain multiple
mailboxes, or the single mailbox is hopelessly malformed, or the
single mailbox does not contain a domain name), continue with step
6. Otherwise, return that single mailbox as the Purported
On the other hand, RFC4408 (SPF1) is fairly widely used by both senders
(published) and receivers (checked). I'm not prepared to throw a lot of
data points to the list at the moment but I am aware of receivers that
have used SPF1 checking as a strong indicator (high correlation) of ham
(pass) vs phishing (fail).
I'm fully aware that there are those who argue the forwarding issue
(breakage) but where domains are heavily abused by phishing attacks this
may be a reasonable tradeoff. For the domains I'm responsible for and
that have been publishing records ending in "-all" (in excess of 750
million messages sent since the start of our publishing these "-all"
records), an extremely high proportion of phishing attacks/messages
abusing our brands could have been dropped (or flagged) by receivers
simply by checking SPF records for those domains.
I am not arguing that SPF is a magic bullet or that it stops SPAM. I am
asserting that it can be highly effective in certain contexts and it
would not be appropriate to move RFC4408 to historic.
BTW, I checked datatracker for the I-D you reference but couldn't find