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

[Florian Hubold]

Am 12.10.2011 12:47, schrieb Florian Hubold:
> 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?
>
Well, if there are no other proposals or no patch for this proposal till next 
weekend,
i'll drop the change to msec default settings to not send email by default
and will issue the update as is.

Seems to me noone is interested in msec anymore.