Provides: MTA and smtpdaemon?

[Patrice Dumas]

On Mon, Apr 09, 2007 at 03:53:15AM +0300, Manuel Wolfshant wrote:
> 
> "/usr/sbin/sendmail -t". By default, hdparm needs to be able to run the 
> "mail" command (it does have the ability to call a custom script, but I 
> am talking about the defaults) which in turn will call sendmail too.

In my opinion things should be fixed where they are broken, so mdadm
and hdparm, smartd... should have the right Requires.

> - postfix will queue but NOT deliver the messages as long the daemons 
> are not started,

Ok, but we can assume that somebody wanting to use postfix send-only 
will configure it properly and start it. ssmtp, esmtp won't do anything
if not configured either...

>    So, for this particular case what I (mind that I did not say we) 
> really need is just a sendmail-like command line program which is able 
> to relay the mails without running a daemon on the machines where the 
> program runs. And that is more or less all that is needed (give or take 

A daemon isn't too problematic from a security point of view. What is
problematic is a daemon running with high privileges and accepting
packets as a network server. It is still more problematic that ssmtp or 
esmtp beacause it doesn't run as the user, but it fallbacks better when
unable to deliver mail instantaneously.

>    As far as I can see, the clean solution would be to have mdadm (and 
> smartd) require /usr/sbin/sendmail (paranthesis: smartd comes from 
> kernel-utils, which does not require any mailing features and just fails 
> happily if there is none installed; and mail -- which is used by smartd 
> -- comes from mailx which uses sendmail but does not require it) and 
> drop Provides: smtpdaemon from ssmtp. But until mdadm is fixed, dropping 
> smtpdaemon as Provides would lead to the above mentioned problem. I 
> could of course maintain my own local repo with a customized version, 
> but it would not be available to all the admins I have persuaded to go 
> "my way", not to mention that I do not feel comfortable overriding the 
> official package unless a very very special need exists which can not be 
> accommodated by upstream. And this ends my talk about smtpdaemon. [*]

Once again what you propose here is the only way to go. No workaround, 
things should be fixed where they are broken, not worked around.

>    As of MTA... In the summary and in the description esmtp and ssmtp 
> both define themselves as MTA, despite none of them being able to 
> process queues or receive mails. Patrice decided that esmtp should not 
> provide either MTA or smtpdaemon, just /usr/sbin/sendmail. To say the 
> truth, I would not have started using (and later on, packaging) ssmtp in 
> the first place if I would have been able to use esmtp directly as a 
> sendmail drop-in replacement.

What I am saying is if MTA means 'any program that provides 
/usr/sbin/sendmail and is able to send mail' then it is a duplicate with
the /usr/sbin/sendmail provides and it should be taken out completely.

> think at mdadm as having a wrong Requires, I thought that was the normal 
> way (core packagers know best, don't they ?) and that this was the 
> feature that ssmtp should provide, too.

Core packages are not packaging bug free, instead they have a lot.
Extras packagers, please help with the Merge reviews ;-).

--
Pat