Re: [nmh-workers] logging outgoing messages

[Ken Hornstein]

>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