On 3 June 2016 at 08:12, Andrew C Aitchison <[email protected]> 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 -- ## List details at https://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/
