Re: [Proposal/Patch] SMTP logging

[Jack <ostroffjh users sourceforge net>]

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