Date: Tue, 09 Jul 2019 19:39:08 -0400 From: Ken Hornstein <k...@pobox.com> Message-ID: <20190709233912.db2aa73...@pb-smtp20.pobox.com>
| - 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 -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers