------- 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 <tlyons@???> 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 <nigel@???> 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
