[prev in list] [next in list] [prev in thread] [next in thread] 

List:       exim-users
Subject:    Re: [exim] Contents of $acl_verify_message
From:       Chris Wilson <chris+exim () qwirx ! com>
Date:       2010-03-19 10:40:19
Message-ID: alpine.DEB.1.00.1003191125340.12391 () rocio
[Download RAW message or body]

Hi Michael,

Actually, I reread your message and my interpretation was wrong (I found 
it difficult to understand exactly what you were doing or how the 
results weren't what you expected).

I think you have found a bug in Exim. There is some very nasty, hairy code 
in src/acl.c with many confusing variable names (like user_message and 
user_msgptr and old_user_msgptr) which makes it very hard to follow 
statically, along with very odd indentation. I'd really need to take a 
debugger to it to analyse it properly.

However, I think that the message "Sender verify failed" comes from 
src/acl.c line 2024, and is intended to be sent out as an SMTP response, 
so it doesn't include the details of why the sender verify failed 
(deliberate, if strange). This only happens if the result of the ACL is 
not OK or DEFER.

Now, around line 3158 this happens:

   /* If the verb is "warn", messages generated by conditions (verification
   or nested ACLs) are always discarded. This also happens for acceptance
   verbs when they actually do accept. Only messages specified at this
   level are used. However, the value of an existing message is available in
   $acl_verify_message during expansions. */

   if (verb == ACL_WARN ||
       (rc == OK && (verb == ACL_ACCEPT || verb == ACL_DISCARD)))
     *log_msgptr = *user_msgptr = NULL;

   if (user_message != NULL)
     {
     acl_verify_message = old_user_msgptr;
     expmessage = expand_string(user_message);

Note the last part of the comment: "However, the value of an existing 
message is available in $acl_verify_message during expansions." This means 
that the contents of acl_verify_message, which *were* the SMTP response 
that you want, are *replaced* by the message that would currently be 
returned to the SMTP client, i.e. the generic message.

It seems to me that acl_verify_message is being used for two different 
purposes here, which results in the loss of the information that you 
want to keep. Therefore, I'd suggest one of the following code changes:

a) Don't replace the specific SMTP error result of the callout with 
"Sender verify failed" before sending it to the client, so that the client 
can see what went wrong (and it will also be available in the logs); or

b) Create a new variable to store the real result of the callout, e.g. 
$acl_callout_result, which doesn't get overridden in the same way that
$acl_verify_message does.

I can't see an obvious workaround, unfortunately.

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | 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 |

-- 
## 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/
[prev in list] [next in list] [prev in thread] [next in thread]