nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [nmh-workers] logging outgoing messages


From: Robert Elz
Subject: Re: [nmh-workers] logging outgoing messages
Date: Wed, 10 Jul 2019 07:50:56 +0700

    Date:        Tue, 09 Jul 2019 19:39:08 -0400
    From:        Ken Hornstein <address@hidden>
    Message-ID:  <address@hidden>

  | - We don't, in general, want to have any more #ifdefs in the code unless
  |   they are completely unavoidable

I agree with that, and even when ifdef's are added, they should be
positive, not double negative, so
        #ifndef NOSYSLOG
is just perferse, where
        #ifdef  USE_SYSLOG
would work just as well (it does mean the name needs to be explicitly
defined to get the new code, but that's the way it should be, rather
than requiring a new name to be defined to retain the previous behaviour).

  | - It is not clear to me that you can state with certainly that the
  |   250 response code will contain the queue identifier

No, you can't, but these days it almost always does.

  |   As a practical matter I've never had to give anyone the queue
  |   identifier of a message

Then you have been lucky, are are relatively new to e-mail tracking.
The need is less common today, than it once was, since more and more
e-mail is direct from sender's MTA to recipient's - but back when
more mail relaying was done (when there was more than just "the internet")
the queue-id along with the transfer timestamp was the info that you
could send to a relay postmaster and actually expect them to look and
see what happened to the message (because that generally makes it trivial
for them to do ... send the message-id instead, or worse, just addresses,
and it was typically a lot more work, which resulted in requests for
tracking sometimes simply being ignored).

  | (because it's not normally logged on the client;

Any rational (MTA) client does.   MUA's typically don't, but those should
not really ever be talking to anything but their local MTA.   What is
different now than what used to be true, is what people regard as their
local MTA, which in the past would normally have been either on the same
host, or at absolute worst, in the same organisation as the sender (and
usually same department of the organisation when it is big enough to have
such things).   (Organisation can mean household for personal e-mail).
Way too many people today are relying upon "free" giant e-mail providers
to do everything for them.

  | really, most people are happy with recipients and a time, and
  | they are really happy if you have a message-id).

time yes, recipients, no, that's close to useless (though it can work if
the recipient receives very little e-mail and the site postmaster is in a
helpful mood at the time a request is made).   The message-id is better, but
the queue-id (along with time) is perfect.   (With a message-id (with or
without the time) the first thing that normally needs doing to track a message
is to convert that into the relevant local queue-id - avoiding the need for
that step makes it just that much more likely that a message can, and will,
be traced.)

  |   But there's no way we could
  |   accept this patch as-is, because it depends on the specific format of
  |   your ISP's response message.

Yes, that's no good - the only rational solution is to log all of the
250 response (after the 250 itself).   It is not only the queue-id in
it which can be helpful, sometimes the wording of the response can give
more info to the site which issued it (when you ask them to see what
happened) - it can differ for mail which was queued there, immediately
forwarded before being ack'd, or which was delivered locally.

  |   It looks like your ISP's format is "250 id=QUEUE-ID".  So that's 3
  |   servers and 3 different formats.

I used to have my mailer say something like
        250 OK Receipt: queue-id
to make it clear that that was the info that I wanted sent to me if
you wanted me to track your e-mail.

Not sure if I still do that or not, it has been a while since munnari
did any significant e-mail relaying (it used to connect 5 or 6 different
e-mail environments).

  | I think this should be a lot more generic.  So ... an alternate proposal.

Personally, I'd just suggest keeping the local MTA, having post deliver
to that, and let it do the logging - it will also do queueing in case
your local ISP link is down (like you want to send e-mail while in an
airplane...).  That is, I wouldn't bother with this at all - there is
an alternative (and better) solution already available.

kre




reply via email to

[Prev in Thread] Current Thread [Next in Thread]