Re: [nmh-workers] logging outgoing messages

[Steven Winikoff]

>>Is there any interest in adding an improved version of this to the code
>>base?
>
>So ... maybe?  But, some thoughts.

Thank you (and everyone else!) for taking the time to reply to this.

Before I say anything else, I never meant to ask for my patch to be
incorporated as-is -- I know there are many ways in which it would
need to be improved for production use.

I sent it mostly as a proof of concept (it's currently just barely
good enough to do what I personally need :-/), and partly in hopes
it might help anyone else if something like it isn't added to nmh
itself.


>- 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.

Understood, of course.  I used those mostly as an easy way to mark the
code I added -- and for those wondering why I chose to write them in
the negative, that was purely out of laziness (so that I didn't have to
add -DSYSLOG to the configure process).

Again, this was never intended for production use, and I apologize if I
didn't make that clear originally.


>- 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).

That's unfortunate.  I've mostly worked with sendmail, and I've never
seen a case where the QID wasn't sent back to the originating MTA, so
I wasn't aware that the RFCs don't require that behaviour.


>  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).

That doesn't match my experience.


>I think this should be a lot more generic.  So ... an alternate proposal.
>
> [ details snipped for brevity, but the summary is be to create a
>   "post hook" and use that instead ]

I'd have no problem with that as long as the post hook provides the same
information gathered in my patch (i.e., sender and recipient addresses,
message ID, relay server and port, and resulting status and QID).

     - Steven
-- 
___________________________________________________________________________
Steven Winikoff                | "...and every single one of them wanted
Montreal, QC, Canada           |  to be involved in the decision-making
address@hidden               |  process without necessarily going
http://smwonline.ca            |  through the intelligence-using process
                               |  first."              - Terry Pratchett