Re: [Proposal/Patch] SMTP logging



Hi Albrecht,

On 2019.07.31 16:03, Albrecht Dreß wrote:
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?
Mostly, but a few more details. First, would it be correct to say "... sylogd (or equivalent)..."? I happen to have syslog-ng installed, not syslogd, but as far as I can tell, it is simply a different provider of the syslog call. (This is both for my understanding, and for any potential documentation of the new feature.)
Second, am I correct, then, the all/most of the current Balsa logging  
is for the benefit of the user, but this new stuff really targets the  
sysop, so some useful info is more likely to be found when a user  
complains?  (I have no idea of the balance of machines on which Balsa  
runs - between single user/home machines and machines where there  
really is likely to be a separate sysop.  Or - is this to provide info  
to the (local) user who then provides it to the (remote) sysop (of the  
mail server) when there is a problem?  If this is the case, then  
what/how/why does syslog provide compared to logging the same string  
with Balsa's currently used logging mechanism?
Thanks for the additional info.

Jack


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]