Mike wrote:
> Would it be better to do HELO checks in acl_smtp_helo, sender checks in
> acl_smtp_mail, setting a variable in each check indicating pass/fail for
> rejection later in the acl_smtp_rcpt check per-recipient (thus only doing
> the check once), or with various caching, is it just as well to put all
> HELO/MAIL checks in the rcpt acl?
'Depends on the situation'.
If you are for-sure going to reject on, for example rDNS fail, (draconian, but
damned effective) then do so in CONNECT and save time and resources.
Likewise any other 'hard' fail, such as HELO-as-our-server (but not, necessarily
HELO by IP, lest you block chron-job reports, etc.).
To the extent individual users or virtual-host whole-domain clients want
different settings, you need to defer action until at least the preferences are
available, i.e acl_smtp_rcpt.
We then action the DNS/RFC stuff in PREDATA, MIME & AV in the first part of DATA
where we have at least a chance of rejecting while the connection is still
'live', resource-greedy SA only in the last part of DATA, where there is a
chance that a peer MTA will motor off on its own errands if/as/when SA gets its
knickers in a knot.
If/as/when that happens we blackhole any bad news - NOT send bounces.
'Real MTA', absent a '250 OK' should come back later and try again.
A few things, such as archiving/not and selective delivery to custom
folders/not, are branched within the router/transport sets.
We are now using all but a few of the new acl_c/m(0-19), have only a handful
'spare', but with care as to overloading, were able to do the same with the
original ten variables.
Active manua and automatic 'whitelisting' and 'VIP' listing, plus willingness to
deeply research 'false positives' are *imperative* if you run tight rulesets.
But far nicer work to track down the odd 'false' postive and help get it
corrected, than to deal with mindless spam aimed at the IQ of the average US or
UK voter...
;-)
PLAN AND DOCUMENT your use of varables right in your own 'configure' file,
likewise what you *believe* an acl clause is to accomplish, ELSE your soft
tissues get caught in the machinery as little as ten keystrokes later...
HTH,
Bill
==
#### NOTES ####
# Exim 4.63 configure for hk3 15 OCT 2006 WB Hacker
# Per-user settings for DNS, RFC, MIME, as well as Spam
# wbh@??? bill@???
#
## Document our use of per-connection variables.
## *FORCE* all those used for BOOLE, and NUMBERS to "0" at start of CONNECT
## null /= 0 in Exim, so comparisons may fail otherwise.
#
# acl_c0 NUM CRITICAL! AUTH/preferred client weight when non-zero value
# acl_c1 NUM CRITICAL! 'free pass' VIP & whitelist weight when non-zero value
# acl_c2 reserved
# acl_c3 STR concatenated client ID info to build log & message strings
# acl_c4 NUM used in acl_m4 for pg_quarantine t/f BOOLEAN flag
# acl_c5 NUM RUDEBUGGER cumulative mime/format/attachment demerits.
# acl_c6 NUM reserved for 'm' use - user rfc strictness pref from SQL DB call.
...
etc..
and the coding in the DB:
.
.
# acl_m17 NUM HELO match test result flag
# acl_m18 reserved
# acl_m19 re-usable trigger for SQL call & return
# pg_rfc codes:
#
# 5 = also require safe attachments
# 4 = also require proper headers
# 3 = also require proper format
# 1 = must satisfy rDNS check
# 0 = allow fail all RFC tests except basic handshake completion
#
# pg_bl codes:
#
# 5 = must also have HELO match
# 4 = must also pass Other RBL tests
# 3 = must also pass DYN RBL tests
# 2 = must also pass local blacklist tests
# 1 = must pass local brownlist tests
# 0 = allow fail all tests
#
# pg_rudelimit. Integer. Put into acl_m6
...
===
PS - we do a number of SQL reads (SELECT..) and writes (INSERT/UPDATE) as well.
OTOH, we have yet to need a 'system filter' or manualroute router, and the only
custom (ONE line added!) pipe transport needed to date is for driving
virtual-hosting mailing lists (Ecartis).
