ietf-smtp
[Top] [All Lists]

Re: Concluding the SPF and Sender ID experiments

2009-02-26 09:46:15

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