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 |
