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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
