Re: [Proposal/Patch] SMTP logging

[Jack <ostroffjh users sourceforge net>]

On 2019.08.01 06:45, Albrecht Dreß wrote:
> Am 31.07.19 22:24 schrieb(en) Jack via balsa-list:
[snip...]
> > Mostly, but a few more details.  First, would it be correct to say  
> > "... sylogd (or equivalent)..."?
> Yes – syslog, syslog-ng, samhain/yule, etc. all serve this purpose…   
> Citing form IEEE 1003.1 [1]:
> 	The syslog() function shall send a message to an  
> implementation-defined logging facility, which may log it in an  
> implementation-defined system log, write it to the system console,  
> forward it to a list of users, or forward it to the logging facility  
> on another host over the network.
>
> > 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?
> Exactly.  Depending upon the settings, balsa's status messages are  
> displayed either in balsa itself (dialogue, status bar, etc., i.e.  
> they are just lost shortly) or using the session's notification  
> mechanism, or go to stdout/stderr (also depending upon the value of  
> the G_MESSAGES_DEBUG environment variable), where they end up either  
> in ~/.xsession-errors if balsa is launched by the window manager, or  
> are again lost if it is run manually from a terminal unless the  
> output is redirected to a file.
Might it make sense (as a wishlist item) for Balsa (optionally?) to  
create a log file (perhaps in the .balsa directory) with configuration  
to allow how many versions to keep?  A possible configuration item  
could be loglevel (or simply whether to log what normally goes to  
stdout or only what goes to stderr).
> The syslog mechanism guarantees that these messages will *always* be  
> stored in a standard place where they can be used for the (rather  
> unlikely) debugging purpose I outlined in my previous message.
As I said, I have no objection to this - I'm just trying to play with  
how this might end up more integrated with the overall Balsa logging  
mechanism.
> > 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?
> I think both scenarios are possible, depending upon the user's skill  
> level.
>
> > 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?
> Well, as I outlined above, /most/ of balsa's status output is just  
> lost when balsa is closed.  The best case would actually be logging  
> to stdout or stderr, which is then added to ~/.xsession-errors.   
> However, this file is usually rotated only once, i.e. you will find  
> ~/.xsession-errors for the current session, and  
> ~/.xsession-errors.old for the previous one.  If you want to trace a  
> message you sent during the, say, next-to-last session, the  
> corresponding .xsession-errors has already been erased.
So this might be addressed with the above suggestion of Balsa just  
saving it's log to a file (either by default or configuration or  
command line switch).  Yes, such a log would be under the user's home  
dir (which makes sense to keep separate user's logs separate) but in  
case of the problems which started this thread, the user is going to  
have to forward that information to someone else anyway, so the only  
real importance is for the user to easily know where that information  
is.
> In contrast, the syslog facilities are typically configured to keep a  
> longer period and/or amount of messages (on Debian, look at  
> /var/log/mail.log*) which makes it a lot more likely to find the  
> requested information even after a longer period of time.
>
> I would like to stress that this debugging purpose is a rather  
> exceptional case for Balsa's logging – I think *all* other messages  
> actually should be displayed to the user, who has to act on them  
> accordingly.
>
> Best,
> Albrecht.
>
> [1]  
> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/syslog.html>

I'm trying to think of the range of approaches by other apps I use.   
Some drop logs under the user's home, some use syslog, some have  
separate logs or log dirs under /var/log, some have areas under /etc or  
/var, I assume there are others.  However, I can't think of any reason  
any one of them should set a precedent for Balsa.  I suppose your  
syslog patch is easy enough to put in place now, and separately  
continue the discussion of what to do with the rest of Balsa's logging,  
and coalesce later.

Jack