[Mageia-dev] [RFC] msec (nail) can't send reports to local users accounts - require an MTA?

Wed Oct 12 12:47:37 CEST 2011

Am 11.10.2011 11:21, schrieb andre999:
+> Florian Hubold a écrit :
+>> Am 28.09.2011 14:40, schrieb Florian Hubold:
+>>> Am 22.09.2011 21:37, schrieb Florian Hubold:
+>>>> Am 22.09.2011 00:09, schrieb Luc Menut:
+>>>> My own opinion is we should do both 1 and 3 in your list of options
+>>>> 1/ Change the defaults in /etc/security/msec/level.*  and
+>>>> 3/ make dma a suggest for msec
+>>>>
+>>>> If these two changes were introduced as updates to Mageia 1 then the
+>>>> consequences would I believe be.
+>>>> a/ Users with default configuration :-
+>>>>
+>>>> Changing the defaults in /etc/security/msec/level.* will not affect an
+>>>> existing installation unless they change their security level.
+>>>>
+>>>> Mail would go into /var/spool/mail/root instead of /root/dead.letter  They
+>>>> probably would still not see the mail because they are unlikely to know
+>>>> how to configure another user to receive roots mail. The only change they
+>>>> would notice is when logging in at a root console they would see a message
+>>>> saying "You have new mail".
+>>>>
+>>>> b/ Users who have configured a real mail address in msec
+>>>> Installing dma as a require will cause these mails to actually start being
+>>>> delivered. Since the user has put the real mail address in the msec
+>>>> configuration we have to assume they actually want the mails to be
+>>>> delivered so that is a "good thing".  If their ISP will only accept mail
+>>>>    from a real MTA as mentioned by Frank Griffin then the message will not be
+>>>> delivered unless a relay host is defined in dma. Since they are already
+>>>> not being delivered nothing will have changed.
+>>>>
+>>>> c/ New users of Mageia 2
+>>>> Changing the defaults in /etc/security/msec/level.* will suppress emails
+>>>> other than to those users who have specifically requested them.
+>>>>
+>>>>
+>>>> Hope that helps
+>>>>
+>>>> Derek
+>>>>
+>>>>
+>>> So if nobody objects or sees other problem with this, i'll modify
+>>> the defaults in /etc/security/msec/level.* to not send email by default
+>>> and making dma a suggest for msec.
+>>>
+>> This poses another problem:
+>>
+>> On a default configuration, we would enable sending reports by installing 
+>> dma with
+>> the msec update, but also disable sending of all reports by changing the 
+>> default settings,
+>> which will apply for everybody who has not run msec-gui or configured msec 
+>> manually.
+>> So this change would be quite antipodal.
+>>
+>> I'm for not changing the default to send mail to root, as this would enable 
+>> sending of
+>> reports on default configurations, and change nothing for configurations 
+>> where people
+>> want those reports sent by mail.
+>>
+>> Opinions, please?
+>
+> Option 1 disables sending reports by default.
+> Option 3 ensures that if the user decides to enable sending reports, 
+> everything needed to send reports locally is already installed.
+> Considering that dma is only adds 64 k, and yields gracefully if another MTA 
+> is installed, that is not a big overhead.
+>
+> However note that ignored messages quickly accumulate and will end up 
+> occupying a lot of disk space, which would be problematic after a while for 
+> users with limited space on their / partition.
+> Because of this, I would suggest another change :
+> (maybe call it option 1+ ?)
+> 1) No default destination.  (It is now MAIL_USER=root for all security levels.)
+> and
+> 2) To make this effective, msec will have to be changed so that if there is 
+> no email adresse (or userid) is entered, then no email is sent, even if 
+> sending is inadvertantly enabled.
+>
+> I've tested msec, and if
+> 1) sending a security alert is enabled, and
+> 2) there is no default defined (stored as MAIL_USER= in 
+> /etc/security/msec/level.*), and
+> 3) there is an empty send-to field (stored as MAIL_USER= in 
+> /etc/security/msec/security.conf),
+> an email is now sent to root.
+>
+> It may be that msec is sending the email without an addressee, and it is 
+> automatically routed it to root by my MTA (sendmail).
+>
+> This change should be relatively simple to implement (once we find the place 
+> in the code), as instead of sending an alert email to a default destination 
+> (root) if the user hasn't entered one, the alert is simply not sent.
+>
+> my 2 cents :-)
+>
+This sounds like a rather big change for a purely bugfix update, because it 
+would also need changes in msec code.
+Any other opinions on this?
+