ietf-smtp
[Top] [All Lists]

Re: Concluding the SPF and Sender ID experiments

2009-02-26 08:43:19

SM wrote:

At 19:49 25-02-2009, MH Michael Hammer (5304) wrote:
I have no problem with RFC4406 and RFC4407 being moved to historic. I've

The change affects RFC 4405, RFC 4406, RFC 4407, and RFC 4408.

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).

There is a note in RFC 4408 about the advice given in section 3.4 of RFC 4406 to publish both v=spf1 and spf2.0 records to avoid the conflict. A rough sample of domains using these specifications shows that they only publish v=spf1 records. Depending on the content of the record and on the context, that can lead to loss of mail. Using SPF1 fail as a strong indicator of phishing means that the receiver is using heuristics.

I don't see the logic connection.

A SPF hard fail result is a strong indicator that the DOMAIN wants a rejection - no guessing, no 2nd thoughts.

For us, the whole point of SPF1 is not to use heuristics at the SMTP Level.

For systems that are using SpamAssasin, they may be passing result, like soft fail, to it and then using some weights. But thats because the mail is accepted, the payload where there is process time available to handle the load.

But hard fail at SMTP transport level? ---> REJECT!

System that ignore the hard fail policy of a domain are just creating problems for domains that desire it by watering down the effect.

I'm fully aware that there are those who argue the forwarding issue

I am not bring up the forwarding issue as it would be more appropriate in a discussion about SPF internals.

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.

RFC 4408 has been published as Experimental with a shelve life. What do you propose to do about that? The statu quo won't resolve the conflict between Sender ID and SPF.

Regards,
-sm

The real world is not going to stop using SPF1 because of the silly IETF procedures, thats for sure, Millions of domains are using it for SMTP level.

The top level problem with SenderID has always been that it requires the payload (2822) headers. SPF does not require the payload to be accepted. The proposed solution to this transaction (optimization) issue is the SUBMITTAL SMTP MAIL FROM extension, which we support.

--
Sincerely

Hector Santos
http://www.santronics.com