On Fri, 3 Sep 2004, John W. Baxter wrote:
> The +smtp_confirmation selector copies the content of the receiving
> server's 250 response at the end of the SMTP dialog into the log as a
> C="blah" item in the Exim log entry. Many servers include the message
> id they have assigned to the message (not all do).
This is a good point. We have various Exim servers within our site, and
finding out what happened to a particular message may involve traversing
the logs of a number of them. Knowing the Exim id of the message on each
of those servers allows me to seamlessly and accurately track a message as
it moves around, rather than just relying on matching
senders/dates/subjects/etc. Given that identifier, I suppose the progress
of a message could be be programmatically discovered assuming all the logs
are available, although I've never felt a great need to write something to
do that.
In the case where a message is passed to a remote site, having implemented
the smtp_confirmation selector, we have a record of the response a site
returned when offered a message, and thus can confirm if a message
successfully left our administrative domain and hence assert that its
further disposition is not our problem. For those remote servers that
return the message ID in their response code, it makes it easier where one
requires to talk to the administrator of a remote machine - you can tell
them directly what the message ID within their server was, which
presumably allows them to locate the message much more quickly (having
said that, I haven't needed to do this, or been asked by another remote
site to do this, for years).
As a general observation, I actually have almost all the selectors turned
on; from what I remember, the default selection is very conservative,
missing out a lot of useful information that can be used to help diagnose
issues, especially for a large site dealing with a diverse set of mail
users. Of course it makes logs larger; but disks are huge these days as
it is. (Yesterday's mainlogs from most of my servers of interest totalled
170Mb - but the compression ratio is good at 86% - I guess as a result of
a lot of similar strings and repeated patterns).
