著者: W B Hacker 日付: To: exim users 題目: Re: [exim] Ha: Re: How many times does router run for
multiplerecipients?
vitas1@??? wrote: > Hi.
>
> I'm using some ACL DATA checks to make a decision - what recipients should
> be whitelisted for THIS specific message. So I'm trying to set up
> user-specific content filter.
>
> So is there any way to drop recipients at ACL DATA stage? I can't do it at
> ACL RCPT stage....
>
> Regards,
>
> Vitas.
Exim can drop/deny (whatever) at ANY smtp stage.
You may not *want* to drop 'much' until just BEFORE acl_smtp_data, but
it helps reduce load to avoid taking in the full set of headers, message
body, and any/all attachments if you can do so.
EX:
- at acl_smtp_connect: pass whitelisted IP's, deny blacklisted IP's,
'flag' rDNS fail for later action (a far-end IP:port is all you have).
- at acl_smtp_helo: pass white, deny black on HELO string or forgery of
same. Deny any that claim to be YOU. Flag mere mismatches for later
action. There are thousands of servers with dodgy HELO's
- at acl_smtp_recpt: deny if not a valid member of your user group
UNLESS, of course it is traffic FROM one of your users intended for the
outside. See 'authenticated' test and 'endpass' as well as Exim's
awareness of the port (eg 587) and protcol (eg TLS) of the arrival.
- before entering acl_smtp_data, test any flags you have carried forward
for deferred action, (held in acl_c and acl_m variables) ex:
- rDNS fail AND bogus HELO AND RFC format violation OR forbidden
attachment MIME-type, AND (or) found in a reliable RBL on our box says
no need to wake up ClamAV or SA for detailed scanning - just deny it.
The load remaining to be scanned in the acl_smtp_data phase should be
greatly reduced - in our case by over 85%. Likewise, if using SA, it can
be stripped of repeating any tests Exim has already made - another major
saving in system load.
While you can do all sorts of magic with routers, *nothing* should get
that far unless you fully intend to deliver it 'somewhere', even if
'somewhere' is a per-user quarantine folder of suspicious messages or a
collection of almost-certain spam for periodic manual review.
Rejection messages you generate BEFORE the routers reach only the
far-end box currently connected, so making a decision before entering
the router/transport sets can dramatically reduce the need to generate
'out of session' failure messages - thereby reducing risk of backscatter
spam abuse.