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
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
Post by Constantine A. MureninPost by Stuart D GathmanPost by Constantine A. MureninI'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.
* 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