Stuart D. Gathman <mailto:stuart(_at_)bmsi(_dot_)com> wrote on Monday, January
29,
2007 2:16 PM -0600:
On Mon, 29 Jan 2007, Seth Goodman wrote:
Stuart D. Gathman wrote on Monday, January 29, 2007 12:04 PM -0600:
No, I found that the *domain* was legitimate and not forged.
That is all I'm claiming. The domain in your example was not
forged, and can safely be credited with spam demerits and blocked
shortly thereafter.
That misses the point, which is to reject mail from hosts that are
not legitimate. You can properly say that SPF is about domain
forgery and nothing more, and I will point out that if it results
in accepting more spam, recipients wont use it. If mail comes from
an IP that isn't
I repeat, as others have done ad infinitum:
SPF IS NOT ABOUT SPAM. SPF IS ABOUT DOMAIN FORGERY.
I'm sure your spam control techniques are all very nice, and all that,
but here on the SPF list, we are working on DOMAIN FORGERY, which
really has nothing directly to do with spam.
<...>
The whole point of SPF is to be able to whitelist domains NOT IPs.
I think we'd both agree that curtailing domain forgery was the impetus
for SPF, and it soon expanded into facilitating the use of domain
reputation. Your Python SPF implementation is an example where the
largest benefits appear to come from accumulating and applying
reputation to whole domains. This works great for whitelisting, though
it's a bit slow to blacklist zombies. I'm suggesting there are multiple
reasons to augment reputation downward. Spamming is an obvious one
along domain forgery and apparent network abuse. They often occur
together, so any of them are good indicator for the others. Even when
the domain is not forged, you can use SPF to make it easier to identify
mail you'd rather reject than filter.
To make use of PTR information in a combined domain and IP reputation
system, you could lower the domain reputation on SPF pass when the
domain reputation is neutral, and lower the IP reputation when that is
neutral, when PTR does not match the SPF domain. On SPF fail, you only
lower the IP reputation when that is neutral. You ignore lack of PTR
match when domain or IP is whitelisted or blacklisted. It would be
sensible if the amount you lower the reputation for bad PTR does not
result in a rejection on the first attempt. If your content filter
subsequently classifies the message as spam, that lowers their
reputation further. A good message would increase reputation more than
a bad PTR decreases it, so legitimate domains with bad PTR records can
usually get whitelisted without intervention. Domains that send spam
from IP's with bad PTR records get blacklisted faster and domains that
are whitelisted are no longer penalized for bad PTR, so an occasional
spam that trips your content filter won't do them in. Does that pass
the sniff test?
Getting back to the idea that started this argument, I hope this helps
show that PTR provides useful information, even on SPF pass. It's
useful when the reputation is neutral, and I agree with you that it
becomes moot once a domain (or IP) is whitelisted or blacklisted.
--
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