------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1031 --- Comment #14 from Todd Lyons <[email protected]> 2012-06-06 15:11:19 --- (In reply to comment #12) > See additional exim-dev discussion > https://lists.exim.org/lurker/message/20120605.160403.7124fe4e.en.html > https://lists.exim.org/lurker/message/20120605.171055.966806d1.en.html I don't want to derail Axel's work, but I want to explore Nigel's different approach a bit. On Tue, Jun 5, 2012 at 10:10 AM, Nigel Metheringham <[email protected]> wrote: > On top of Todd's comments... > > This feels a bit like making a specific special case function where > there could be something more generic... would we do better running > something ACL like at the end of a delivery attempt which could do > logging or maybe something else... I like the idea of a post-router ACL, but I agree (with your "something ACL like") that the typical application of an ACL doesn't really apply because the verbs accept, defer, deny, discard, and drop really have no meaning after the router has run. Just silently skip the function of the verb and still process the conditions. The warn verb would serve the most useful purpose. The require verb has potential, but I can't think of any way of using it that would be useful post transport, unless you can use it to signal to a subsequent transport call (i.e. prior lookup failed because database is unreachable, etc) but *that* approach seems laden with opportunities for failure. Off the cuff, I think only processing warn statements and conditions only for the rest would be the preferred approach. > And I can see why you might have a purpose for just *remote* deliveries, Hmmm, I didn't catch that it was remote deliveries only. In my personal situtation, I would need to log everything. I also log spam rules matched, SPF results, etc, which is not going to be available at this juncture unless I stuff it into a connection or message variable. And I need to log it when it rejects an email, which does not get to a transport, which means I personally would need to add the logging there too. > but its another specialisation which might be better generalised out - > maybe its just a transport attribute, with a condition (or is the > condition on the transport overall). I kind of like the concept of a "secondary_logger" attribute generic transport option. It's sole purpose would be to expand whatever is configured for it. Such as the ${lookup DBTYPE{...}} , but it could just as easily call some external script (doesn't scale well, but may be useful for someone). But as above, will require manual work to log defer or reject verb matches in ACL's prior to the routers being run. > We will obviously need some spec file documentation. If it's accepted as an Experimental Feature, we should omit it from the spec and from the optionslist (right?). If it gets accepted or adjusted to be a mainline feature, then we'll slam out that additional documentation. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
