On 3 June 2016 at 08:12, Andrew C Aitchison <andrew@???> wrote:
> Agreed.
> In fifteen years as postmaster on an exim domain I've always found the
> (internal) message id immediately after the date on each log line
> sufficient.
>
OK, here are two (recent) scenarios where Exim's internal message id alone
is not sufficient, *unless* I happen to know the internal intricacies of
(1) being able to recognise from the logs that my Exim has had to generate
a RFC5322.Message-Id and (2) its process for generating/assigning that
value…
*Scenario 1*
Someone here complains that an external recipient hasn't received one of
their emails. To let the downstream postmaster definitively identify the
message in their logs I'd normally supply them with the RFC5322.Message-Id
from our logs.
To the best of my knowledge my Exim's internal message is logged only in my
server's logfiles and within the Received headers of the message that
(might or might not) have arrived at the downstream server.
*Scenario 2*
(This is the situation that sparked my discovery.)
A message is generated here on-site and sent out to an external mailbox. We
have reason to believe that mailbox is forwarding its incoming messages
back to a mailbox here but the user has claimed some specific ones haven't
come back. Is this the case, or has the user somehow managed to
filter/delete them?
Within Google's admin console I can only search the mail logs by
- sender email address and/or IP (which returns too many matches in this
case)
- recipient email address and/or IP (which returns too many matches in
this case)
- RFC5322.Message-Id value
If I know the RFC5322.Message-Id of the original message that we sent out I
can quickly and easily use Google's search facility to easily check and
confirm whether the message did indeed come back in to us, then trace it if
it did.
If I don't know the RFC5322.Message-Id I instead have to rely on managing
to contact someone at this (foreign, large-scale) email provider and try to
get them to look into the problem with, hopefully, an eventual reply.
Yes, I now know that I can 'easily' calculate what RFC5322.Message-Id Exim
would have assigned and that has now helped me solve me problem. My point
is that sysadmins shouldn't need to know or have that level of
understanding of the innards of an MTA software package: one possibly
installed as a packaged binary. They should be able to get the information
they need from its logs.
I do appreciate some people feel that adding the RFC5322.Message-Id to the
"<=" log line would mean losing the indication that an incoming message
lacked a Message-Id header triggered Exim to generate that Message-Id.
(Just as others say they've never encountered the issues I've had to deal
with, I've never found needing to identify that an incoming message lacked
an RFC5322.Message-Id to be important.) So OK, perhaps it should be logged
on the outbound line… or on a separate line… But I honestly feel it should
be logged *somewhere*.
Thankfully I now have that after realising I could do so with a *warn* in
the acl_smtp_data ACL so am happy. But it would be lovely to think that
others in the future don't have to waste their time re-tracing this
tortuous discovery.
Anyway, I think I've laboured my own views long enough that they should be
clear. I opened the bug report, so it's up to the Exim developers now to
assess and decide on. In the meantime I've got my *warn* in place to give
me the additional logging I feel I need. :-)
Cheers,
Mike B-)
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
