Re: [exim] Adding a per-recipient message header

John Robinson wrote:
> On 14/10/2006 10:17, SeattleServer.com wrote:
>
>> Somebody mentioned using a router to add per-recipient headers, but I don't
>> see how this would work as acl_m4 is set at rcpt acl time.
>
>
> I'm guessing your acl_c6 and acl_m6 are the same for multiple recipients of a
> single message, but your acl_m4 is per-recipient. Can you (re)generate
> whatever you set acl_m4 to at router or transport time?
>
> Cheers,
>
> John.
>

NB: Sample was from servers in production 12+ months, some of the comments below
are more appropriate for the replacement configure, presently still in test.

===

acl_[c|m]4 will be moved - is presently a 'VIP-pass'

acl_[c|m] 2 thru 3 and 5 hold test results - some used as simple boolean flags,
others are cumulative or weighted integer 'scores' for finer-grained 'eval:'
comparisons.

EX: One can ascertain right up-front if a connecting host fails rDNS. But one
must await acl_smtp_rcpt to see if the recipient *allows* that or not.

acl_[c|m] 6 thru 9 (plus another set now in test) hold per-user thresholds
against which these test results are compared.

Other per-user flags in the DB determine whether 'quarantine' delivery is made
to an IMAP folder (created if it does not already exist), or the dodgy traffic
is simply left commingled with standard inbox fodder ('Subject: header may have a
prefix munged into it - user pref setting also).

Some of these are used for branching within acl's, mostly predata and data,
others are used to add headers to (also) control branching in router/transport sets.

Router/transport sets are extensive. Incoming from the sesame.exim.org list
server, for example, has a dedicated router/transport set of its own to sanitize
header bloat.

Most of *our* headers are stripped at final delivery to reduce header-bloat and
end-user confusion. Few added headers have any post-delivery value, even fewer
are ever noticed by end-users, and *zero* are needed for tracking or analysis if
you have logs.

===

Overall goal is that an end-user, department head, or corporate CIO can set
thresholds, not only for spam handling/sorting/discard, but also as to whether
an entire firm, or just chosen accounts, will accept forward/reverse lookup
failure, HELO mismatch, dynamic IP, broken headers, potentially dangerous
attachments, etc.

Spam aside, many of these *other* items are not ordinarily made adjustable on a
'per-user' basis.

Pragmatism says that a 'public facing' contact address may need to be more
lenient, at least w/r initial contact acceptance, than largely-internal staff
accounts - folks for whom most traffic is intra-company/suppliers/customers, not
the unexpected new arrivals or world at large.

This way, a few folks, or a team of 'role' members sharing the workload
(sales@', 'info@' can be designated to dig through the pile of suspicious
arrivals in search of the odd acorn w/o the need to fill the folders of *all*
staff with garbage OR chance losing a sale.

NB: - 'Global' high-but-not-ganymedian thresholds remain, plus the obvious
rejection of HELO as *us*, verify = recipient failure, as one cannot justify
either as 'false positives'. We cover the obvious with aliases for common
local_part typo/spelling errors, but NOT so lenient as to accept dictionary attacks!

Placing these settings in 'user community' hands, and making them apply
exclusively to the user or team/company/domain saves the sysadmin hassle.

QED

NOT (yet) determined' - what all the lookups and matches do to the server load,
but so far, even running from PostgreSQL, it seems decent.

Bill