Re: [Exim] bug with warn?

Hey guys! Nobody with a comment? Well, I have done some more tests
and, apart from finding some inexact statements is the spec file, I
got to the following partial conclusion: log_message does not log
twice the same message when used in a constant warn statement.

A constant warn statement is something like:

warn    log_message = boo
    constant condition

in my case the "constant condition" is null.

I have run in debug mode the test I described at the start of this
thread, the warn statements are run, but there is no log output the
second time around as in the following:

MAIL
RCPT

warn processed and log output

RSET
MAIL
RCPT

warn processed but no log output (except from the warn that checks the callout)

RCPT

same as previous


The solution is to use logwrite instead.


Now, to the problems with the spec file. Please forgive me if I might
have wrongly intepreted some of the specs, I am clearly just
reporting sections that are perhaps unclear, perhaps wrong. Also this
is longinsh and perhaps badly expressed sometimes. Sorry for that.

Here they are:

      If any condition on a "warn" statement cannot be completed (that is,
      there is some sort of defer), the warning action does not take place. The
      incident is logged, but the ACL continues to be processed.

this is not completely clear, does it imply that in a statement like:

warn    log_message = boo
    set acl_m0 = 1
    verify = sender/callout
    set acl_m0 = 2

none of the actions take place when the callout gives a defer? This
is not true, as long as setting an acl variable is considered to be
an action (see next). From what I can see, immediate actions (like
setting variables) take place in order, until a defer or a false
condition stop the warn processing. Non-immediate actions (like the
result of the log_message modifier) do not take place instead.

Few lines below however it says:

   accept hosts = whatever
|
          set acl_m4 = some value
|

|
Note that the leading dollar sign is not used when naming a variable
that is   |
to be set. If you want to set a variable without taking any action,
you can    |
use a "warn" verb without any other modifiers.
|

So, setting a variable is not an action... well, then, except from
possibly logging and adding headers, a warn statement does never
perform actions (as it does not accept or deny)!

The story does not end here...:

log_message = <text>

    This modifier sets up a message that is used as part of the log message if
    the ACL denies access. For example:

this is also untrue and is contradicted few lines below, because a
warn never denies access and still, used with a log_message modifier,
sets up part of the log message with it (and this log is written even
if the ACL ends up accepting the message).

A similar statement is repeated a bit below:

logwrite = <text>
|

|
    This modifier writes a message to a log file as soon as it is
encountered   |
    when processing an ACL. (Compare "log_message", which is used only
if the   |
    ACL statement denies access.) [...]

even if this uses the term "ACL statement" instead of just ACL.


And further down another imprecision:

         Note: If neither "message" nor "log_message" is set for a "warn"
         statement, it does not add anything to the message and does not write
         a log entry.

this is false, as logwrite does indeed write a log entry.

Thanks

Giuliano

--
H U M P H
    || |||
  software

Java & C++ Server/Client/Human Interface applications on MacOS - MacOS X
http://www.humph.com/