This is not for everyone to just go and drop into place.
Far from it... but seems worth continued trials:
Situation:
Requiring that forward/reverse DNS lookup find (at least) a valid 'A' record
can block a very high percentage of zombies immediately on 'connect'.
Adding an RBL check for dynamic IP can improve further on that.
Downside:
Too many well-meaning, but non-compliant servers, including some of the
'outbound only' unregistered hosts of major ISP's one *must* converse with.
Too many entire-netblock/errored dynamic IP entries in RBL's
What we *were* doing:
- using a 'warn' verb to add weighted 'demerit' points for rDNS fail or RBL
hits, other RFC, format, MIME, attachment, header violations. (still are...)
- Checking the cumulative score against per-recipient thresholds (not available
until at least 'Recpt-to' phase), then rejecting. (still are)
What we have started doing recently *first*:
Serendipitous, and possibly unique to our setup, is the presence of an archive
for 1 to 6 years of outbound traffic that is arranged, not by sender, but by
*destination* addressee ~/domain.tld/ It was easier to do that for
troubleshooting. A flat-file, cdb, or SQL table would also serve.
Functionally, this is equivalent to having (most of) *every* user's MUA address
book available, and allows 'exempting' those on such a list from strict
scrutiny. As one would with MUA 'junk' filters.
Methodology:
in sequence, and within acl_smtp_connect:
- first flag authenticating clients, relay_hosts, etc. THEN skip further acl's
with 'endpass' and/or set a flag in an acl_c variable to permit doing so
selectively w/o further uncached lookups.
- next check bespoke whitelists (by string-match on IP for those with no
hostname, others by hostname - both). Likewise use 'endpass' or set a flag.
- next grant a 'get out of jail free' chit to any domain.tld to whom any of the
users have sent a message in the past by testing the archive dirtree, and use of
'endpass' or setting a flag in an acl_c variable.
ELSE - inline the test for the acl, as below:
## The above are critical 'pre test' steps, as an rDNS fail is a 'BFBI' style
hammer! ##
Example (the 'scoring' system is operative when 'STRICT' is not set):
.ifdef STRICT
# CONNECT_3: Delay acting on rDNS lookup to allow whitelist test first
#
deny
log_message = C3 rDNS fail $sender_host_address $sender_address
message = \n Sender $sender_host_address has defective DNS record(s). \
\n Reasons at: http://conducive.net/rejection.html
!verify = reverse_host_lookup
.endif
(then test for local black (longterm) brown (short term), dynamic IP RBL)
IF you have enough 'history', as we do in the archives, AND are willing to do
significant manual whitelisting as well, a very high percentage of rude arrivals
can be rejected early, with low resource load, and without the usual very high
false-positives [1] that could result from 'require verify...' or denying before
checking for permitted exceptions.
No panacea, not for everyone, may be impossible for a broad-market ISP.
But presently working very well on a 'corporate' dedicated server with some very
old, heavily-targeted domains.
SA is now called to scan only 6% of offered traffic.
Criticism most welcome.
YMMV!
Bill Hacker
[1] RFC's aside, whether rejecting a mail server that doesn't even have an 'A'
record published and/or is on a dynamic IP is really a 'false positive' or
simple survival depends on how hard your server is being hammered, and how much
customer heat can be avoided with decent whitelisting.
