[Exim] 4.10 RCPT ACL warn log_message treated as message

Firstly, thanks to Philip for including fixes in 4.11 for my reported
problems in 4.10 - I regret I had not said so before in at least one case.

Secondly, apologies for reporting a problem in 4.10 now that 4.11 has just
appeared. I've looked through the 4.11 changelog and can find nothing
relevant. And the archive isn't searchable at this precise moment(?)

Being a very timid bunch, we currently don't 'require' sender
verification, but only use 'warn'. Our RCPT ACL starts with:-

check_recipient:
  accept  hosts = :
  warn    log_message = Sender verification failed
          !verify = sender
  accept  [etc etc]

and I find in the rejectlog entries like

2002-12-11 07:47:02 H=(clstats1.thecomedylab.com) [216.52.122.248]
Warning: Sender verification failed: Sender verify failed

So far, so good (though my choice of log_message doesn't get many points
for originality). The problem is that I also get a header added to the
message, as in (from a run with -d)

using ACL "check_recipient"
processing "warn"
check !verify = sender
[...]
warn: condition test succeeded
LOG: MAIN REJECT
U=root Warning: Sender verification failed: Sender verify failed
processing "accept"
[...]
>>Headers added by RCPT ACL:
Sender verify failed

[...]

Because this isn't the correct syntax for a header (ie no Tag: part),
somewhere along the line it gets treated as the first line of the body.
Worse, any further added headers, legitimate or otherwise, also appear in
the body.

I can circumvent the problem by changing the ACL to add a message, eg

check_recipient:
  accept  hosts = :
  warn    log_message = Sender verification failed
          message     = X-Sender-Verify: failed
          !verify = sender
  accept  [etc etc]

The problem appears to be in acl.c (surprise!):-

acl_verify() always sets both *log_msgptr and *user_msgptr :-
  *log_msgptr = *user_msgptr =
  [...]
    US"Sender verify failed";

acl_check_condition() overwrites *user_msgptr _only_ if user_message (the
'message' value from the ACL) is non-NULL. In my case it isn't, so I end
up with "Sender verify failed".

I suspect the solution is to reset *user_msgptr to NULL if user_message is
NULL, but only in the ACL_WARN case. I'm not going to attempt a patch, on
the grounds that
a) Philip will understand the ramifications far better than I;
b) I have a circumvention;
c) I don't have the time :-(

Hope this makes sense.

Regards,
Richard Hall