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