Re: [exim] acl_mX variables

> 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).

Thanks Bill. My intention was not really content scanning on acl time,
but to avoid the same DB query on acl and delivery time.

Basically, if acl_m(n) could be used on a per-recipient basis - or if an
acl_r(n) for recipient was available - we could just talk to the DB once
to get all the data needed for recipient checking + routing/delivery. I
think technically this is still possible, no?

One problem would be the amount of memory used when there is a large
number of recipients per message, but RAM these days is cheap :)

So, I'm not sure if this is the right place for a feature request, but
this would be very useful to have available :)

Cheers

W B Hacker wrote:
> 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
>