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