Re: [exim] Ha: Re: How many times does router run for multip…

トップ ページ
このメッセージを削除
このメッセージに返信
著者: 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.


Sorry - the last post answered only your *second* question...

per-recipient 'preferences' for message handling is easy *until* you
enter the data phase. EG: some may accept an rDNS fail, HELO mismatch,
or RBL hit, others not. You can accumulate the resuts of these tests,
pull preferences in the acl_smtp_rcpt phase, and do the work there.

One you enter the acl_smtp_data phase, as you *must* if the full headers
and content and attachments are to be scanned, (you do not even have
sight of them at any earlier phase), life gets more complex 'coz you can
no longer reject per-recipent [1].

There are some workarounds, such as:

- accumulating the preferences of each recipient as they are ID'ed in
acl_smtp_recpt. Best if these are boolean flags or integer point-score
values. Bring lots of variable buckets, and plan to do some math.

- generate a min/max of each of the preferences.

- reject ALL in acl_smtp_data IF the least-paranoid of that particular
group would reject, ELSE accept ALL if the most-paranoid would accept.
Optionally using a fake-reject for ALL when score falls in between.

CAVEAT: acl's are a bit arcane, result is not always well received, so
after a year or so in use, we've not rolled it out to other servers.

On the good side, to the extent you host domains with different
preferences, but the same preferences *within* each domain, a not
uncommon situation for SME's, the problem seldom arises in the first
place. Multi-recipient arrivals have usually been grouped per-domain at
the sending end.

While reiterating that you really, really want to do all possible to
handle rejection BEFORE entering the routers, see also the 'unseen' flag
than can allow you to chain routers to get the effect of multiple passes.

BTW - acl_m variables are preserved until the last 'copy' of a message
has been delivered, and you can read (but not alter) these from within
routers. Generally cleaner than string-mathcing on X-headers.

CAVEAT; X-headers will be in archives or on client desktops days or
years later. acl_m's go away at last delivery. Choose what is 'best' for
your needs.

HTH,

Bill

[1] Unless you have courier-mta at both ends. courier has an extra step
after the data phase that reverts to per-recipient negotiation. But only
with another courier box...