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

Wed Oct 19 00:14:40 CEST 2011

Balcaen John a écrit :
+> Le lundi 17 octobre 2011 16:39:14 nicolas vigier a écrit :
+> [...]
+>    
+>> I think that :
+>>   - changing the default configuration in an update is wrong. If it's
+>>     better that msec do not send emails by default, I think this change
+>>     should be done in cauldron only, maybe with some note about this change
+>>     in the release notes for Mageia 2.
+>>      
+> Agree.
+>    
+
+A question : wouldn't changing the default in _both_ cauldron and an 
+update to mga1 be acceptable ?
+Since I really think that sending messages silently to dead.letter, 
+gradually filling up the disk is a bug.  (When I first discovered the 
+problem on my system a few years ago, dead.letter used about 1G of disk 
+space.)
+That is what happens with the default setting, if an MTA is not installed.
+At the default settings with an MTA installed, the root mailbox 
+gradually fills up the disk, if it is not emptied.  And a less informed 
+user is unlikely to realise this.
+
+So it seems to me that as a minimum, the default should be changed to 
+_not_ send alert emails.  Since the status is visible on the main msec 
+screen, informed users should have no problem appropriately adjusting 
+the setting.
+
+To deal with the potential problem of users who use the email alert 
+feature having it deactivated by the update, we only need a warning in 
+the update, as often occurs for other packages.
+Something like "If you use the msec alert emails, please verify that the 
+alerts are still active."  Note that if the user has ever explicitly set 
+alerts, they would be still active.
+This potential problem would exist even if the next update for the user 
+is mga2.
+However, if the update is on mga2 (from changes in cauldron), wouldn't 
+the change in defaults be less visible ?
+
+>>   - adding a require or suggest on dma is wrong, especially in an update
+>> Installing dma with the update will silently replace /usr/sbin/sendmail
+>> to use dma instead of the previously installed mta, potentially breaking
+>> email for all programs using the sendmail command.
+>>      
+> Hum, if i'm not wrong dma has the lower priority  (5) in the alternatives for
+> sendmail-command so it should not replace the default mta :
+> postfix has 30 , sendmail has 10.
+>
+>    
+According to documentation, dma is only active if no other MTA is installed.
+(I don't know if the priority is what causes this.)
+So at worst dma would be a (very small) harmless extra install, at best 
+it would ensure the ability for local delivery.
+[...]
+> Regards,
+>    
+
+Regards :)
+
+-- 
+André
+
+