> 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 > -- ## 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/
