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 :-)

--
André

Reply via email to