>Is there any interest in adding an improved version of this to the code >base?
So ... maybe? But, some thoughts. - We don't, in general, want to have any more #ifdefs in the code unless they are completely unavoidable (e.g., operating system differences or optional third-party libraries like OpenSSL). So this would require some run-time configuration. - It is not clear to me that you can state with certainly that the 250 response code will contain the queue identifier (that is, in fact, not a concept that appears anywhere that I can find in the SMTP RFCs). As a practical matter I've never had to give anyone the queue identifier of a message (because it's not normally logged on the client; really, most people are happy with recipients and a time, and they are really happy if you have a message-id). But ... fine. I can imagine cases where it would be helpful. 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. I tested out two email providers that I use and their formats differ, specifically: 250 2.0.0 Ok: queued as QUEUE-ID 250 2.0.0 QUEUE-ID Message accepted for delivery It looks like your ISP's format is "250 id=QUEUE-ID". So that's 3 servers and 3 different formats. I think this should be a lot more generic. So ... an alternate proposal. Right now we have the hooks interface (see doc/nmh/README-HOOKS). It should be relatively straightforward to create a "post hook" that could be invoked when email is submitted to a mail server. One of the arguments to the post hook could be the response message from the SMTP server. Another one of the arguments to the post hook could be the message draft so you could interrogate it with scan(1) to extract out anything useful you might want like the message-id. You could then use your favorite shell tools to process the SMTP server response and then send it to syslog with logger(1). I realize that would be a lot more work than the code you submitted, and we'd have to think about the arguments to the post hook, but I don't see any huge blockers other than WRITING the code. I am neutral about this being made to work with sendmail/pipe; it would actually be a lot of work to do that. We could just accept that it is one more thing that doesn't work with sendmail/pipe. --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
