Re: [OT] Harvest netblocks of good MTAs from SPF for whitelisting from greylisting

first i would say yes if doing the sort of greylisting you are talking about pre-whitelisting ips from spf records is not a bad way to cut down on initial delays

secondly i would say if the ip(s) is not available via an spf record do not assume 'a mx' as 'a' largely NEVER is a legit mta its usually a website, b MX has usually at most 1 ip that sends most others are receive only, and often all are receive only

thirdly yes this will save your greylisting work/initial DB build, but also greylisting equally will not reduce the spam much as most modern spambots will also retry later so will also pass greylisting (why they do this and TLS nowdays)

fourthly you should still use spf/dkim/spamassasin-at-data/etc on your mta for connections that have come past greylisting because still a lot of spam comes via greylist-passing bots and legit mailservers with compromised users

either way this use of SPF is not relevant to this list really?

as greylisting done properly is not a concern for legit senders as it just delays their first email via each server for each new greylisting user. so less than any % of use


At 00:19 13/02/2013  Wednesday, Constantine A. Murenin wrote:
>On 12 February 2013 14:55, Stuart D Gathman <[email protected]> wrote:
>> On Feb 12, Constantine A. Murenin transmitted in part:
>>
>>
>>> I'd guesstimate that a setup with pf(4) whitelisting of common MTAs
>>> through the SPF harvesting approach described, together with
>>> greylisting at the firewall level, for my domains would be much more
>>> effective in combating spam than any kind of SPF or DKIM
>>> implementations at my MTA level, and without the false positives.
>>
>>
>> But you are doing the same thing as SPF - except guessing the valid MTAs
>> instead of using the official list conveniently provided in SPF records.
>> If you are worried about efficiency, SPF records that don't involve
>> localpart or PTR macros can be resolved to a set of IPs (more general
>> than a netblock) with a TTL, and cached.  I believe libspf2 has this
>> feature already.  Take the union of the IP sets of all your "good"
>> domains if you are going to treat them all the same.
>
>No.  I cannot have my firewall do SPF evaluations, and I'm not
>attempting to do the same thing as SPF.  I am also not guessing valid
>MTAs, I'm getting their list deterministically based on static SPF
>information that is published by relevant entities whose mail I might
>care to never delay.
>
>Let's do a quick reality check here:  SPF cannot block spam.  It can
>only block forgeries, and if you configure it as such, it is also very
>much so likely to have many false positives, too.
>
>My approach, as described above, involves the following:
>
>* collect SPF information statically (every week or so) and compile a
>list of netblocks
>* pass connections from such whitelist directly to sendmail/qmail/mta of choice
>* pass other connections to spamd, to do greylisting
>* if a host passes greylisting, spamd updates the firewall, and the
>next connection attempt will go to sendmail/qmail/etc
>
>The novelty of my approach is collecting a whitelist through an
>SPF-based record harvesting.
>
>SPF-wise, this approach has limitations of, for example, obviously not
>supporting SPF's "ptr" and "exists" declarations, and also not being
>real-time; however, even for such domains that rely on such features,
>they'd still be able to deliver mail after passing greylisting, and
>with no false positives.
>
>Non-SPF-wise, this approach might make SPF actually useful for those
>who think that it is not, and would complement any greylisting policy
>with very little overhead and a 0,000% false positive rate.
>
>Yes, I'm not trying to use SPF as it was designed, but who cares?
>It's not like we use IPv4 for what it was originally designed either,
>is it?
>
>Right now I'm trying to see if someone has already done this before,
>as it seems simple enough.  Else, some ideas on a possible
>implementation, or perhaps just stirring some interest amongst people
>who are thinking of better ways to use the SPF records that remain
>largely unused.
>
>Best regards,
>Constantine.
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/735/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130212192229:6C9697B6-7573-11E2-B11D-86D6A19F48A7
>Powered by Listbox: http://www.listbox.com