Don Lee wrote on Saturday, January 27, 2007 11:05 AM -0600:
SPF on the sender side provides some data about IP addresses and
their linkage to domain names. Much of our conversation is about
precisely when and how this can be used. Much of the controversy
is about how to "stretch" this information to separate
"legitimate" mail from "spam".
This is somewhat misguided. SPF was meant to deter forgery of
domain names in the return-path.
I submit that SPF is inadequate for this purpose. It does not
provide enough information to make a definitive judgement about
whether email is "legit" - and it never will.
That's correct, SPF detects return-path domain forgery, not spam.
In the long run, making it difficult to pass off trivial domain
forgeries makes life harder for spammers.
HELO checking is a good example. I think there is consensus that
this is safe and effective, and can be deployed immediately
everywhere without pain.
That's not exactly true. There are still a large number of MTA's with
improperly configured HELO names. What is safe is to reject for the
HELO name being _your_ domain. If the HELO name is not yours, you are
asking for trouble if you reject on that alone. In combination with
other tests, checking HELO may help you to generate SPF pass where you
otherwise wouldn't, and that's probably where it's most useful at
present.
Chasing corner cases and forwarding issues detracts from this goal.
Unfortunately with anything as complicated as email, one person's corner
case is another's bread and butter. I wish we could ignore forwarding,
but everybody recognized it was a serious problem for SPF from the
get-go and not much has changed since.
--
Seth Goodman
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735