Brent Jones wrote:
> Hello Exim users,
> We have some Exim servers that uses the system filter to save certain
> messages to an NFS backing store. While this works a majority of the
> time, we would like a graceful way to handle when the NFS server may
> be down for maintenance.
> The OS handles it find using soft mounts, if the server is unavailable
> it will notify Exim for example that a timeout occured.
> Exim will properly defer the message at that point and keep it
> spooled/retry queue. However, when the message is tried next, it will
> not go through the system filter as I would like it to, it will
> instead use the first router than can handle the message.
> The behavior as I understand it written on:
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch43.html
> "The system filter is run at the start of a delivery attempt, before
> any routing is done. If a message fails to be completely delivered at
> the first attempt, the system filter is run again at the start of
> every retry."
>
> That to me means for retry deliveries, it should re-process the system
> filter, instead of jumping to the routers immediately. However, my
> system filter does take into account sender host address, and sender
> address domain. Do retry attempts not include this information with it
> comes up for delivery again? If not, how would I re-process these
> messages and categorize them correctly?
>
> An example system filter rule:
>
> if ${mask:$sender_host_address/24} is 10.0.0.0 and (
> $sender_address_domain is spammer.com )
> then
> save /some/nfs/share/
> endif
>
> Any thoughts would be greatly appreciated
>
CAVEAT: Bit of a cop-out. I've never used - nor needed - a system filter.
IMHO, simplest should be use acl and router/transport logic AND NOT a system
filter at all.
An acl can set an indicator in an acl_m which is persistent until final delivery
of the last copy leaves the queue. Or use a specialized X-Header, which persists
into mailstore on onward to Luser's MUA and its mailstore.
Downside with a header is that end-users or destination hosts can see it as well
as your own MTA UNLESS stripped by the active router/transport set.
The flag being 'persistent', any router(s) triggering on either acl_m or
X-header should do so in a repeatable manner.
Likewise - even if it were to be passed through the acl's in an smtp-session it
is *still* fully predictable/repeatable.
Solution might not be what you want, but different results of retry are not a
factor.
The example router/transport set below was once used to accumulated sample
traffic for test and analysis of acl effectiveness. The X-Rude header was added
in acl's within DATA phase when cumulative 'demerit' scores exceeded a
threshold. A header was used instead of an acl_m in this case so that MUA
filters could also act on it.
Note the 'unseen', and that several lines that may be superfluous and/or
redundant ar there as documentation/eminders to an old fart:
=========
#
rude_bugger:
driver = accept
transport = rude_bugger_delivery
condition = "${if def:header_X-Rude:{1}{0}}"
unseen
---------
#
rude_bugger_delivery:
driver = appendfile
user = <to suit your need>
group = <to suit your need>
delivery_date_add
envelope_to_add
return_path_add
maildir_format = true
mode = <to suit your need>
directory = <to suit your need>
create_directory = true
directory_mode = <to suit your need>
no_mode_fail_narrower
==========
CAVEAT 2: No longer in use. It served its purpose.
HTH,
Bill
