https://bugs.exim.org/show_bug.cgi?id=423
--- Comment #14 from Simon Arlott <bugzilla.exim.simon@???> ---
(In reply to Jeremy Harris from comment #13)
> > it logs on any warn verb that defers. There is no message or log_message on it.
>
> So I'm confused. I had the impression that you had a warn verb, which would
> not result in a defer, and you went on with other verbs doing other things.
> Note that "warn" and "defer" are different verbs.
> Can you show your code section, pointing out where something gets logged?
exim_check_acl:
warn
set acl_m_verify = bypass
condition = ${if eq{$acl_m_allow_any}{0}{yes}{no}}
acl = exim_verify_sender
condition = 0
# Exim removes user_message at the end of every warn verb.
defer
condition = ${if eq{$acl_m_verify}{defer}}
logwrite = :main:...
log_message = $acl_m_debug verify/sender/defer
deny
condition = ${if eq{$acl_m_verify}{deny}}
logwrite = :main:...
log_message = $acl_m_debug verify/sender/deny
exim_verify_sender:
accept
set acl_m_verify = defer
verify = sender/callout=90s
set acl_m_verify = accept
deny
set acl_m_verify = deny
> > Yes, the user message is impossible to reconstruct.
>
> What did it say, and why can't you put that in a log_message or logwrite
> modifier?
Because I don't have it. It is generated by Exim:
if (rc != FAIL || LOGGING(sender_verify_fail))
log_write(0, LOG_MAIN|LOG_REJECT, "%s sender verify %s for <%s>%s",
host_and_ident(TRUE),
((sender_verified_failed->special_action & 255) == DEFER)?
"defer":"fail",
sender_verified_failed->address,
(sender_verified_failed->message == NULL)? US"" :
string_sprintf(": %s; %s", sender_verified_failed->message,
sender_verified_failed->user_message));
I have no way to access sender_verified_failed->user_message from an ACL.
> > What it fails to point out is that the verify message that used to get sent
> > over SMTP is now no longer sent and you get a default generic message instead.
>
> Now you're talking about the SMTP response, not the logging.
Why is this relevant?
I want to send the original SMTP response message with the information that
explains why the verify failed.
I want to log some headers when there's a defer/deny.
I can't do both of these things at the same time because there's a lot of
special cases in the Exim code around generation of messages for verify
failures.
This bug is for putting the message in a variable, which would make it possible
to send it in the response even after the user_message is reset.
--
You are receiving this mail because:
You are the QA Contact for the bug.
