Re: [exim] acl_mX variables

Tom Bombadil wrote:

*snip*
>
> The doc says: "values are not passed on from one message to the next, as
> $acl_c... values are. The $acl_m... variables are also reset by MAIL,
> RSET, EHLO, HELO, and after starting a TLS session"
>
> So, I'm not sure these variables are saved on a message basis, or
> per-recipient basis.
>
>
> Any hints?
>
> Thanks :)
>

Basic design flaw in smtp.

Once an MTA finishes checking recipients, during which individual accept/deny is
possible, it then takes on-board the actual message (headers, body,
attachments), in the 'DATA' phase.

Prior to that agreement, the two players are 'negotiating the possibility' of
transferring the message - they have not yet actually done so.

Once the message is actually 'on-board' the current state of the smtp protocol
allows no further 'per recipient' differentiation during the rest of the life of
the current connection.

DSN's can be sent *later* in a NEW connection FROM Exim BACK TO the (apparent)
source. As this 'apparent' may be forged, we try to do as much rejection as
possible during the original connection, as that harms no one else, even if forged.

Per-recipient rejection on content scan is not one of the things we can do -
unless there was only one recipient in the first place OR an entire domain.tld
has the same rules and thresholds (both quite common, actually).

On completing the DATA phase, any and all values of the acl_m(n) set will pass
into the queue for storage with the ONE copy of the message. You can see these
if you 'lynx' the queue (best to stop the runners first, else it is soon gone).

The message will later be copied and distributed by queue runners to each of
many recipients. The acl_m(n) values are accessable to routers and transports
during this phase - but 'read only' so may no longer be altered by them. Copies
may be altered, but Exim has very few variable 'buckets' during that phase in
which to hold such copies.

Can be done with SQL, but is a RPITA, and - in any case, 'too late' to tell the
sending MTA in real time that they are to be rejected. It has usually left the
building already.

When the last copy of the message has been distributed to the last recipient,
all of the acl_m(x) will be deleted along with the MTA's 'Xerox Master' of the
message.

Each OTHER 'child' process handling a message stores its own set of acl_m(n)
variables with its message, and n'er the many shall collide.

There have been at least two efforts to add experimental extensions to smtp so
as to return to 'negotiations' that support selective rejection *after* having
full sight of it in DATA - and probably scanning at least the headers if not the
content - but while the original 'session' is still intact.

This could greatly reduce backscatter bounces, and Courier-mta has actually been
shipping with such a feature (EXDATA) for many years.

HOWEVER - it can only 'work' when both correspondents are courier-mta, AND are
optioned to offer and utilize the feature. Courier has enough installations to
prove that it can work, but not enough to inspire other MTA to do the same.

At least one MTA beside Courier needs to support that before enough folks will
even take an interest in testing it, let alone pushing it into a 3rd and 4th MTA
for widespread use 'in anger'.

This is being looked at again by networking folks who write rfc's, where 'NIH'
guarantees it will not be the same as what Sam coded. OTOH, he did contribute to
pushing esmtp and STARTTLS along, and we now take those for granted, so all hope
is not lost.

HTH,

Bill