Samuel Verschelde a écrit :
Le mercredi 28 septembre 2011 15:02:32, Balcaen John a écrit :
Le Mercredi 28 Septembre 2011 14:42:56 Samuel Verschelde a écrit :
Le mercredi 28 septembre 2011 14:40:46, Florian Hubold a écrit :
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.
As I said in the other thread, I think sendmail-command is a better
suggest than forcing the use of dma.
Well it's just a suggests not a requires.
Also suggesting sendmail-command would requires the user to first choose
one of the possible alternative ( ssmtp,postfix, sendmail,mstmp or dma
actually but we can still expect to have more mta for the end user)
which is by default currently postfix.
Even if i personally find quite easy to configure postfix we can still
expect than the end user can probably mis configured the mta,& configure
it (wrongly) as an open relay.
Suggesting something like dma or mstmp or ssmtp is for msec is (from my
point of view) far better than providing a « real » mta.
In fact, we could have dma by default while letting other people choose
another mail server and thus not install dma.
During a system installation, no question is asked, the first choice is always
taken. This first choice could be made to be dma. This is something we can
change in the meta-task package (/etc/urpmi/prefer.vendor.list).
Of course, this would mean than any package requiring sendmail-command would
see dma first in the list. I don't know if it would be a good think or not. I
tend to think yes, because for standard users dma will be preferred whereas
experience admins will choose the MTA they want.
So if we had not an update to issue, this would be my choice. Suggest
sendmail-command and make sure that dma is preferred when there's an automatic
selection.
If what I say here makes sense, maybe in Mageia 1 msec could suggest dma and
in Cauldron sendmail-command, + we would alter meta-task ? If not, then let's
go for dma and forget my comments.
Best regards
Samuel
I have a slightly different take on this
Note that
1) If we send emails to root and they aren't noticed and removed, they
will accumulate and eventually occupy a lot of disk space. As well, it
is evident that most users won't know what to make of much of msec's
messages. If a user sets an email address, local or remote, they are
presumably more likely to know what these messages mean.
Setting a no-email default for all levels is simpler than doing it
selectively by "level"
2) dma is very small, only 64k, and if another MTA is installed, dma
lets the other handle the function. So users can install another MTA,
and dma will be ignored. If dma is always installed, then it will
always be available if another MTA has been installed and subsequently
uninstalled.
3) In the longer term, it seems to me a good idea to have a local-only
MTA integrated in msec, as suggested by Frank.
So I go for the proposed solution of
1) Changing the msec default to not send email by default
but
2) making a requires for dma (instead of suggest), so that it is always
installed.
and
3) If/when a local-only MTA is integrated in msec, we remove the
requires for dma.
my 2 cents :)
--
André
