Hi Jack! Am 31.07.19 20:16 schrieb(en) Jack via balsa-list:
On 2019.07.31 08:17, Albrecht Dreß wrote:when Balsa sends a message to a local or remote SMTP server, a feedback is given only on failure. However, sometimes it is necessary to trace sent messages on the SMTP server. As to simplify this, I propose to add syslog logging for SMTP operations. The attached patch will basically send a message to the facility LOG_MAIL with priority LOG_INFO for messages accepted by the SMTP server, and LOG_NOTICE for rejected ones, respectively. The message includes the user name, the PID, the server, the message ID and the final server reply, e.g.: Jul 30 13:59:20 deneb balsa: [4116:albrecht] SMTP=localhost:25 Message-ID=TXYM6J7S.O4T6EXDP.EJQOUC54@TJOAIDH7.JSKKDXYR.UQTYV7L3 Result='2.0.0 Ok: queued as 682BD1FF079' Note that syslog() is a standard API defined by IEEE 1003.1, and should thus work on every compliant system. Of course, it is up the system admin to configure the syslog backend properly.Your description makes it sound like this is a new use of syslog() for Balsa. If so, why use a new logging mechanism, or is this intended as a possible start to migrating all logging to this approach? (Just curious - no objections.)
Yes, you are right, it *is* the first time Balsa would use syslog, and mixing different mechanisms is somewhat questionable… The idea behind it: Any MTA (Postfix, Exim, …) will log to syslogd, which in turn writes files, forwards to a centralised log server, etc. If anything unexpected happens, e.g. a message has been transmitted by Balsa, but allegedly never arrived, the user will typically ask the sysop for help, who will usually look into the syslogd output. Depending on the user's skill level [s]he will only know the time, and maybe the message-id of the message in question. This is already just fine if Balsa uses a local MTA (as in my example above, which therefore is actually bad), as of course the MTA will log all further operations, which can be identified by the message-id. However, using the internal queue id (the “682BD1FF079” in the example) greatly simplifies life for the sysop. However, when Balsa sends a message to a remote server, we currently have *no* information but the message stored in the sentbox, in particular no queue id. Thus, the idea is to log Balsa's SMTP operations as a MTA would. So, as summary, this log output is intended *only* as an aid for the sysop if something needs to be tracked. (While writing it, I get the idea that it might actually be helpful to additionally log the RFC 5321 “RCPT TO” recipients…). Actually, I added this feature because at work I send my messages to a security appliance, which sometimes simply holds them for no apparent reason. And the sysop of that device wants to know the queue id… An alternative might be adding a header with the final SMTP server response to the message before it is stored in the sentbox (would that be possible?). I do *not* intend to switch *any* other logging mechanisms to syslog! Does this answer your question? Best, Albrecht.
Attachment:
pgpXX3Gze6hEk.pgp
Description: PGP signature