nmh-workers
[Top] [All Lists]

Re: [nmh-workers] logging outgoing messages

2019-07-10 01:22:16
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
smw@smwonline.ca               |  process without necessarily going
http://smwonline.ca            |  through the intelligence-using process
                               |  first."              - Terry Pratchett

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>