Using %D in the logfile directive in a filter?

[Adam Funk-4]

A while ago [1] I asked about getting a datestamp in the filename of
the log generated by an Exim filter.  (Note that I'm talking about a
"~/.forward"-type filter on a user account, not Exim's main
configuration and logfiles.)

I was told that %D would expand to 20090602 as it does in Exim's own
logfiles, but it isn't working; the directive

  logfile  $home/mail_logs/test_%D.log

puts the file in "~/mail_logs/test_%D.log".

Am I doing something so silly I can't see it, or is this a bug, or was
I misinformed?  (The server is running "Exim version 4.69 #1 built
30-Sep-2008 18:26:44", if that matters.)


Thanks,
Adam


[1]
http://thread.gmane.org/gmane.mail.exim.user/82624/


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Phil Pennock-9]

On 2009-07-02 at 15:25 +0100, Adam Funk wrote:

> A while ago [1] I asked about getting a datestamp in the filename of
> the log generated by an Exim filter.  (Note that I'm talking about a
> "~/.forward"-type filter on a user account, not Exim's main
> configuration and logfiles.)
>
> I was told that %D would expand to 20090602 as it does in Exim's own
> logfiles, but it isn't working; the directive
>
>   logfile  $home/mail_logs/test_%D.log
>
> puts the file in "~/mail_logs/test_%D.log".
>
> Am I doing something so silly I can't see it, or is this a bug, or was
> I misinformed?  (The server is running "Exim version 4.69 #1 built
> 30-Sep-2008 18:26:44", if that matters.)

You were misinformed.

The string expansion of %X, for various X, is not done for the logfile
directive of filters.  It's only for the normal Exim logs.

You do have access to all of Exim's string expansion variables (except
for those explicitly prohibited in config); you should just be able to
use $tod_logfile instead of %D.

Regards,
-Phil

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Adam Funk-4]

On 2009-07-02, Phil Pennock wrote:

> On 2009-07-02 at 15:25 +0100, Adam Funk wrote:

>> I was told that %D would expand to 20090602 as it does in Exim's own
>> logfiles, but it isn't working; the directive
>>
>>   logfile  $home/mail_logs/test_%D.log
>>
>> puts the file in "~/mail_logs/test_%D.log".

> The string expansion of %X, for various X, is not done for the logfile
> directive of filters.  It's only for the normal Exim logs.
>
> You do have access to all of Exim's string expansion variables (except
> for those explicitly prohibited in config); you should just be able to
> use $tod_logfile instead of %D.

Perfect, thanks very much!  I guess if I want to switch to monthly
logs, I could also use "${substr_0_4:$tod_logfile}".

BTW, I have one other concern.  Is it possible for a badly written
logfile or logwrite instruction in a filter to cause mail to be lost?


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Phil Pennock-9]

On 2009-07-02 at 21:06 +0100, Adam Funk wrote:
> BTW, I have one other concern.  Is it possible for a badly written
> logfile or logwrite instruction in a filter to cause mail to be lost?

I would expect that either the mail would be delivered and the logging
would fail, or the mail would remain in Exim's queue, undelivered, and
you'd see it.  I haven't checked the code this time to be sure.

-Phil

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[W B Hacker]

Adam Funk wrote:

*snip*

>
> BTW, I have one other concern.  Is it possible for a badly written
> logfile or logwrite instruction in a filter to cause mail to be lost?
>
>

Ordinarily not.

Further, Exim will 'usually' place a line in the log describing (as best it can)
what failed to work.

If, for example, a variable cannot be expanded, a conditional is not structured
in a workable manner, or a dirtree/file cannot be found or written to, that can
cause an acl clause 'set' to be bailed out of. That could leave a message on the
queue OR cause a rejection with the far-end seeing, for example 'temporary local
problem' - but either way there is a trail.

NB: all of these would ordinarily be default log entries unless you have
provided customized failure messages. It may pay to do that = putting some
unique ID as to where the call came from into each message to speed troubleshooting.

CAVEATS:

1)  If 'log_selector = ' has been set to very low verbosity, some or all of the
entries might be absent.

If so, you might wish to try it for a time with 'log_selector = +all', then
ratchet that back down afterwards so you don't eat too much disk space.

2) I am assuming similar behaviour for filters - especially in that they may
call router/transport sets - as for in-session acl's.

I've never personally needed an Exim filter, so I may be wrong about that.

HTH,

Bill

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Adam Funk-4]

On 2009-07-03, Phil Pennock wrote:

> On 2009-07-02 at 21:06 +0100, Adam Funk wrote:
>> BTW, I have one other concern.  Is it possible for a badly written
>> logfile or logwrite instruction in a filter to cause mail to be lost?
>
> I would expect that either the mail would be delivered and the logging
> would fail, or the mail would remain in Exim's queue, undelivered, and
> you'd see it.  I haven't checked the code this time to be sure.

Thanks.


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Adam Funk-4]

On 2009-07-03, W B Hacker wrote:

> Adam Funk wrote:

>> BTW, I have one other concern.  Is it possible for a badly written
>> logfile or logwrite instruction in a filter to cause mail to be lost?

> Ordinarily not.
>
> Further, Exim will 'usually' place a line in the log describing (as best it can)
> what failed to work.
>
> If, for example, a variable cannot be expanded, a conditional is not structured
> in a workable manner, or a dirtree/file cannot be found or written to, that can
> cause an acl clause 'set' to be bailed out of. That could leave a message on the
> queue OR cause a rejection with the far-end seeing, for example 'temporary local
> problem' - but either way there is a trail.
>
> NB: all of these would ordinarily be default log entries unless you have
> provided customized failure messages. It may pay to do that = putting some
> unique ID as to where the call came from into each message to speed troubleshooting.
>
> CAVEATS:
>
> 1)  If 'log_selector = ' has been set to very low verbosity, some or all of the
> entries might be absent.
>
> If so, you might wish to try it for a time with 'log_selector = +all', then
> ratchet that back down afterwards so you don't eat too much disk space.
>
> 2) I am assuming similar behaviour for filters - especially in that they may
> call router/transport sets - as for in-session acl's.
>
> I've never personally needed an Exim filter, so I may be wrong about that.

Thanks.  I'll be careful.


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/