[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Provides: MTA and smtpdaemon?



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]