SPF
pros: Easy and simple
look footprint
Doesn't require payload
cons: Multiple routes, transition points
o Hard Fail
pros: It works! Addresses legacy spam
cons: It works too WELL! It scares people!
o Soft Fail:
Pros: None
Cons: Requires batteries (i.e. Bayesian, weight system)
Wasteful overhead on receivers
SENDERID
pros: Marketing (Its Microsoft!)
Helps transition point issues
cons: requires PAYLOAD
requires 4405 support to address this payload issue
not everyone supports 4405 :-(
--
Sincerely
Hector Santos
http://www.santronics.com
MH Michael Hammer (5304) wrote:
-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of SM
Sent: Wednesday, February 25, 2009 7:06 PM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: Concluding the SPF and Sender ID experiments
Hello,
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
concurrently.
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
Responsible Address.
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
it.
Mike