Robert P. Thille writes:
Looking at what is still getting thru, I was thinking that a plugin that
did some generic RFC compliance checks of the HELO/EHLO domain/IP, and
perhaps optional DNS/Reverse DNS lookups to confirm they weren't lying
would be useful (though could prevent some poorly configured mailers from
getting thru I suppose).
Does anyone know of such a plugin, or should I start coding?
Well, there's require_resolvable_fromhost ...
BTW, does anyone know why AOL.com is publishing SPF records with NEUTRAL
for the internet at large? Seems stupid, and I'm tempted to hack it (the
plugin/perl module) up to treat that as a soft-fail, but so far I haven't
had that many spams come in pretending to be mail-from aol.com.
There's nothing stupid about it at all (IMNSHO), although I know that a lot
of people don't agree with me on this issue.
SPF is viewed by many as to be used like this:
1. Blacklist all servers but [these servers].
But it can also be used to basically say this:
2. Whitelist [these servers].
And then there's of course the third option:
3. "Treat everything as neutral, which I've put in the DNS just so that
people will shut up about me not using SPF". =)
#1 is the easiest to use by most people, and it's also the way they expect
SPF to be used; but #2 is a valid friendly way of saying that although
you've basically got a neutral position you are willing to give out some
information that might/will help at least some people.
Interpreting #2 data as as #1 data could result in problems, as the people
considering their SPF-record as a sort of whitelisting could have an array
of backup systems which at anytime could start sending e-mails.
One person doing exactly what you are proposing to do (but he did it to all
SPF-records) ended up bouncing my reply to his e-mail simply because his
SPF-parser was broken/out of date; so it didn't see that my e-mail came from
a "whitelisted" server, and then it ignored the neutral-part of my
SPF-record...!
If you're looking for a way to view the goodness of the
whitelisting-approach to SPF-usage then picture a qpsmtpd-plugin which keeps
track of the number of outgoing e-mails to different domains, and if there's
been x outgoing e-mails to domain y during the past z days and the
SPF-record of an incoming e-mail from doing y says the sending server is a
good one, then you let the e-mail bypass all other spamfilters (to lighten
the load of the server, not to mention avoid something like SA eating up a
lot of resources to then erroneously send a viagra-joke to manually sorted
quarantine-folder).
/Tony