Provides: MTA and smtpdaemon?

[Manuel Wolfshant]

On 04/08/2007 11:08 PM, Ville Skyttä wrote:
> Hello,
>
> Are the meanings of Provides: MTA and Provides: smtpdaemon documented 
> somewhere, or can someone tell with confidence what they mean/imply?
>
> I thought that a Provides: smtpdaemon would mean a service that runs a local 
> SMTP service daemon and Provides: MTA something sendmail command line 
> compatible that can send mail; filed some bugs, but it appears that there are 
> some disagreement over their purposes.
>
> https://bugzilla.redhat.com/235594
> https://bugzilla.redhat.com/235596
> https://bugzilla.redhat.com/188400
>
> Unless they already are, these things should be documented somewhere.  I 
> started http://fedoraproject.org/wiki/VilleSkytt%C3%A4/VirtualProvides to 
> collect info - feel free to comment and add info and whatever is missing.
>
>   
    Note to readers: this mail should be seen as a continuation for 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235596#c5 . However 
I feel it is more appropiate to bring it to the list since it touches 
the problem of ssmtp (which I maintain).

    Just for the practical problem, let me explain what my needs were 
and the reason for which ssmtp provides smtpdaemon. For a start, one 
needs to know that (especially since the era when sendmail exhibited the 
nice remote root exploits) I hate keeping daemons running unless they do 
something useful and I will definitely do my best to not run a mail 
daemon on several dozens/hundreds machines just to be able to receive 
alerts from them. And no, relaying from time to time an alert like "hard 
disk X is defective",  "/dev/md1 failed" or a daily log does not qualify 
as something useful for usage of a full blown MTA. Please also think of 
small devices (like in embedded routers without a hard disk, but 
everything on a  compact flash or a USB stick) which just need to relay 
their status and/or alerts.

    The start of the story were mdadm (and hdparm which is just slightly 
different). The mdadm package requires smtpdaemon. According to my tests 
(via strings /sbin/mdadm), what mdadm really needs is to be able to use 
"/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.
    Now, let's see in turn each one of the packages which provide 
smtpdaemon:
- sendmail (as provided by the sendmail package): not sure about the 
newer version 'cause I haven't used for more then 3 years, but "back in 
the old days", the daemon did not really need to be started in order to 
send mail from the command line,
- postfix will queue but NOT deliver the messages as long the daemons 
are not started,
- ssmtp does not include a daemon at all, but will happily deliver the 
message the instant it is called,
- AFAIK, esmtp will perform the job just like ssmtp does, but does not 
provide smtpdaemon,
- cannot speak for exim, as I have used it only for 3 days and that was 
6 years ago during my sendmail era.

    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 
authentication and ssl). Sendmail fits the bill, but is very large (once 
again: think of a total storage of 256/512 MB MB); postfix does NOT fit 
the bill because it must have a running daemon (and is large, too...); 
ssmtp and esmtp do fit the bill, but they would not be picked at install 
time (not even via a kickstart file) unless they provide smtpdaemon. In 
other words, ssmtp is the perfect tool for my need, but I could not 
install it cleanly INSTEAD of sendmail/exim/postfix because mdadm 
requires smtpdaemon. So
- sendmail and postfix provide MTA, /usr/sbin/sendmail and smtpdaemon, 
but in my case none of them fits the bill (I do not want a running 
daemon, both are very large);
- esmtp only provides /usr/sbin/sendmail, so it is not seen by mdadm as 
a suitable Provides
- ssmtp provides everything that sendmail provides, and this on purpose 
(to allow it to be used instead of sendmail);  being a send-only 
application, probably ssmtp should NOT provide smtpdaemon, but otherwise 
it could not be used as a drop-in replacement for postfix/sendmail.

    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. [*]


    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.


[*] I assume that from the very beginning the correct solution would 
have been to file a bug against mdadm, not making ssmtp provide 
smtpdaemon. In my defense I can only say that at the time I did not even 
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.