Re: [exim] Contents of $acl_verify_message

Hi Michael,

On Thu, 18 Mar 2010, Michael Naef wrote:

> 11:24:44 21633   SMTP<< 554 <wwwwwwwwwwwww@???>: Recipient
> address rejected: Access denied
> 11:24:44 21633   SMTP>> QUIT
> 11:24:44 21633 ----------- end verify ------------
> 11:24:44 21633 expanding: X-Sender-verification-failed-for:
> $sender_address
> 11:24:44 21633    result: X-Sender-verification-failed-for:
> wwwwwwwwwwwww@???
> 11:24:44 21633 check add_header = X-Sender-verification-failed-for:
> $sender_address
> 11:24:44 21633                  = X-Sender-verification-failed-for:
> wwwwwwwwwwwww@???
> 11:24:44 21633 expanding: sender verify failed: HHH:
> $acl_verify_message
> 11:24:44 21633    result: sender verify failed: HHH: Sender verify
> failed

I guess you were expecting to see "Recipient address rejected: Access
denied" in $acl_verify_message, instead of just "Sender verify failed".

I'm assuming you see the more detailed message in the log_message, but not
in the add_header.

I think this was reported previously in 2004
[http://www.exim.org/lurker/message/20041209.030414.44e7767d.ca.html]

In your config you have this:

warn    !verify  = \
sender/defer_ok/callout=10s,defer_ok,connect=2s,maxwait=20s,no_cache
         log_message = sender verify failed: HHH: $acl_verify_message
         add_header = X-Sender-verification-failed-for: $sender_address

and Philip addressed another query in 2005 saying thus:

"I have now looked at this. If you look in TFM, you will find this:

$acl_verify_message: During the expansion of the "message" and
"log_message" modifiers in an ACL statement after an address verification
has failed, this variable contains the original failure message that will
be overridden by the expanded string.

Notice the condition that is imposed:

During the expansion of the "message" and "log_message"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For historical/internal reasons, the code implements this precisely. So
this isn't a bug. But I have noted it as an infelicity that perhaps
should be fixed."

[http://www.exim.org/lurker/message/20050322.162345.e913fa7d.ca.html]

Perhaps it was never fixed?

Cheers, Chris.

P.S. I found this in five minutes using Google and I have no expert 
knowledge of the code.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |