Re: [exim] Queuing only deliverable messages for mailscanner

Robert Brown wrote:

> I am using mailscanner/spamassasin to scan all my incoming mail. All mail
> is queued via the "queue_only" option, scanned by mailscanner then delivered
> via another exim4 process. What I would like to do is somehow verify the
> local recipient address before putting it in the queue for scanning. In
> other words I'd like the following logic:
>
> If the message is from a host allowed to relay then queue it for scanning
> (This handles messages from my clients to outside addresses)
> If the message is to a valid local address queue it for scanning (This
> handles messages to valid_users@???)
> If the message is to an invalid local address, bounces it immediately (This
> handles messages to invalid_users@???)
>
> The whole purpose being to not waste CPU time scanning messages that I KNOW
> will be bounced anyway.
>
> Does this make sense and is it possible?
>

Not only 'possible' but can be improved upon, and is *very* effective:

- in order (philosophy, not acl's code:

in the 'connect' acl's:

- accept, then 'endpass' for your own users connecting and authenticated,
skipping further connect-phase checks for authenticated users. You don't care
what his IP is while traveling, so long as his password & such was accepted.

- accept, then 'endpass' on a local whitelist of VIP or 'dispensation granted'
IP's (string match, not callout) that you will work with even if they are on
broken DNS, good folk in a poorly-run network, private IP on internal/campus LAN
etc.

- deny arrivals whose IP does not resolve to a hostname. Callouts here, but
already made and cached.

- deny on a local blacklist of known-bad-actor IP's. Also string-search, not
callout.

- deny on a hit of users of dynamic IP (note that these will be only those who
have a dynamic IP *and* at least a published 'A' record. You've already rejected
those with NO DNS entry). dul.dnsbl.sorbs.net works here.

- accept the survivors (as few as 25%)


in the HELO acl's

- accept, then endpass your authenticated users.

- accept, then 'endpass' of $sender_helo_name against a local VIP whitelist
(string match, NOT DNS callout).

- deny an arrival HELO'ing as your own box or one of your virtual domains.

- deny on HELO string match against a local blacklist.

- now that you have IP and HELO info, check other RBL's and deny or warn

- accept the survivors. (as few as 10-15%)

in the MAILFROM acl's:

- accept, then endpass your authenticated users.

- accept, then 'endpass' of $sender_helo_name against a local VIP whitelist
(string match, NOT DNS callout).

- Armed with more information, look at some of the many acl examples that try to
ID HELO / IP / sender mismatch for forgeries. Be aware that many senders are a
bit 'casual' about using HELO's that have anything at all to do with hostnames
in DNS records, and many folks are attached to one ISP's mail server but want
their repiles to soem other address, and send accordingly.

OTOH, some of the high-traffic folks ARE usually consistent (gmail, AOL, even
MSN), and are often forgery targets. YMMV (greatly) here.

- accept the survivors.

In the Recpt-to acl's

- no 'free pass' for VIP's needed. Anyone can mis-type an address.

- require verify = recipients Kills dictionary attacks.

(If the email address of the Chairman is often mis-spelled, add aliases to
redirect those to his proper address).

- You now have everything in-hand but the message body and attachments.
*Many* useful tests can be done here, message-header completeness, syntax, etc.
Lots of examples abound. 'last chance' to reject before taking-on the bigger
chunk of bytes - the body and attachment(s).

- accept the survivors. You may be down to 10% of attempted arrivals by now.

The pre-data and data phase is where you set up for AV and Spam scanning.

All I'll say about that is ... look how much garbage you have shed before
needing to bother with running scanners *at all*.

You may no longer even need to run 'queue only' unless you have a very large
'legitimate' traffic load. Exims acl tests are *way* more efficient than SA and
such.

Needless to say, some of these rejections will be challenged as overly harsh by
many. Soem folks would rather push spam around on the HDD than shed it.

So.. start off with a 'warn' instead of a deny, write to the logs, analyse them,
then tighten up and check again.

When 'top' shows the MTA loafing instead of running with its tongue hanging out,
AND users haven't missed anything important, you have your balance point.

HTH,

Bill