Bug 243631 - Review Request: msmtp - an SMTP client
Review Request: msmtp - an SMTP client
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Patrice Dumas
Fedora Package Reviews List
:
: 165932 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-10 18:58 EDT by Nikolay Vladimirov
Modified: 2013-09-02 14:55 EDT (History)
3 users (show)

See Also:
Fixed In Version: 1.4.12-7.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-23 11:50:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pertusus: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Nikolay Vladimirov 2007-06-10 18:58:36 EDT
Spec URL: http://ns.bgtld.net/build/msmtp.spec
SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.11-1.fc7.src.rpm
Description: 
In the default mode, it transmits a mail to an SMTP server (for example at a free mail provider) which does the delivery.
To use this program with your mail user agent (MUA), create a configuration file with your mail account(s) and tell your MUA to call msmtp instead of /usr/sbin/sendmail.

Features include:

    * Sendmail compatible interface (command line options and exit codes).
    * Authentication methods PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, GSSAPI, and NTLM.
    * TLS/SSL both in SMTP-over-SSL mode and in STARTTLS mode. Full certificate trust checks can be performed. A client certificate can be sent.
    * Fast SMTP implementation using command pipelining.
    * Support for Internationalized Domain Names (IDN).
    * DSN (Delivery Status Notification) support.
    * RMQS (Remote Message Queue Starting) support (ETRN keyword).
    * IPv6 support.
    * Support for multiple accounts.


This is my first package and I need a sponsor.
Comment 1 Nigel Jones 2007-06-10 19:23:29 EDT
(In reply to comment #0)
> Spec URL: http://ns.bgtld.net/build/msmtp.spec
> SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.11-1.fc7.src.rpm
...
> This is my first package and I need a sponsor.

Wow!  Nice work! (Honest)

Sadly I can't sponsor, I've set the bug to block FE-NEEDSPONSOR though, so
hopefully the right people will see it.

A couple of notes (I can't test build sorry):
- Download link should be altered, the standard at the moment for SF.net URLs is:
Source0:        http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
- Summary could do with a touchup
- Description should/could have a bit more about the program
- URL:            http://msmtp.sourceforge.net/index.html could be changed to
URL:            http://msmtp.sourceforge.net/ (Just in case they decide to use
index.php or something in the future, it's not important, but something to consider)

Overall it seems fairly good standards wise.
Comment 2 Nikolay Vladimirov 2007-06-11 04:11:58 EDT
Changelog
* Mon Jun 11 2007 Nikolay Vladimirov <nikolay@vladimiroff.com> - 1.4.11-2
- fixed URL, Summary and description

Spec URL: http://ns.bgtld.net/build/msmtp.spec
SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.11-2.fc7.src.rpm

Description: 
The package is without support for the GSSAPI, DIGEST-MD5, and NTLM
authentication methods. This requires GNU SASL. 
Comment 3 Nikolay Vladimirov 2007-06-14 17:43:47 EDT
I just found this program has already been packaged and reviewed( bug 165932 ). 
I know msmtp duplicates the functionality of esmtp but i prefer msmtp. If this
package is approved i can make one for libgnusasl and update this. I'm not sure
what's the policy for duplicate functionality now that core and extras are merged  .
Comment 4 Patrice Dumas 2007-06-16 13:53:17 EDT
No problem with duplicate functionalities.
Comment 5 Nikolay Vladimirov 2007-06-19 07:29:37 EDT
* Tue Jun 19 2007 Nikolay Vladimirov <nikolay@vladimiroff.com> - 1.4.12-1
- new version 
- changed Summary and description

Spec URL: http://ns.bgtld.net/build/msmtp.spec
SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.12-1.fc7.src.rpm
Comment 6 manuel wolfshant 2007-06-19 10:20:16 EDT
Please use http://downloads.sf.net in the URL for Source0. It it much more
reliable and scripting friendly then http://dl.sf.net
According to the source, you do not need to BR both gnutls-devel and
openssl-devel, either one would suffice. On the other hand, in order to build
translations, please add a BuildRequires for gettext. It would also be wise to
buildrequire cyrus-sasl-devel, in order to include gnu-sasl support. Otherwise
the configure script will say:
   checking for libgsasl... no
   configure: WARNING: Cannot find GNU SASL, disabling
In order to use the package as a drop-in replacement for sendmail, I suggest
adding the following Provides: /usr/bin/sendmail and MTA. In this case you
should also add a couple of scriptlets to handle the install/remove of this
package via the alternatives system. It's up to you to decide if you want to
replace sendmail or just coexist with it.
Otherwise the package is in excellent shape and I will do a full review shortly.
Note that I cannot sponsor you, so this will not be enough to have the package
included. Which is also the reason I will not assign the review to myself.
Comment 7 manuel wolfshant 2007-06-19 10:23:57 EDT
Please also consider including the content of the doc subdirectory, I think that
the examples would be useful for users.
Comment 8 Nikolay Vladimirov 2007-06-19 11:19:40 EDT
* Tue Jun 19 2007 Nikolay Vladimirov <nikolay@vladimiroff.com> - 1.4.12-2
- fixed source0
- removed openssl-devel from BuildRequires
- added BuildRequires for gettext
- added more doc files

Spec URL: http://ns.bgtld.net/build/msmtp.spec
SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.12-2.fc7.src.rpm

msmtp requires libgsasl it doesn't recognize libsasl provided by cyrus-sasl-devel. 
I read the discussion for the previous package( bug 165932 ). sendmail is one of
the core packages in the system and a lot of programs use it to do local
deliveries and there is a big chance of just breaking things without a point.
msmtp is mainly used with mutt and other MUAs and I think that just pointing the
MUA to msmtp is better than messing with the whole system. 
I left gnutls-devel in BuildRequires because that's the default choice of the
configure script. 
I added the manual in HTML and the examples from the doc subdirectory.
Comment 9 Nikolay Vladimirov 2007-06-19 14:49:00 EDT
I've looked into GNU SASL. libgsasl requires a few more libraries that aren't in
the repos so for additional authentication methods at least five more packages
have to be created which is just needless burdening of the system. I've posted a
message in the msmtp mailing list about cyrus sasl support.  

I guess i should remove "DIGEST-MD5,GSSAPI, and NTLM" from the description. 
Comment 10 Patrice Dumas 2007-06-19 15:35:13 EDT
(In reply to comment #9)
> I've looked into GNU SASL. libgsasl requires a few more libraries that aren't in
> the repos so for additional authentication methods at least five more packages
> have to be created which is just needless burdening of the system.

There is no such notion as 'burdening the system'. What is important
is 
* having functioning software
* well integrated
* avoiding burdening the other fedora contributors, I mean avoiding
  brining in packages if they are not enough useful such as another
  maintainer will step up if you resign.
Comment 11 Patrice Dumas 2007-06-19 16:11:32 EDT
As a side note LibIDN, libgcrypt, and a gss api are in fedora.
libntlm doesn't seems to be in fedora, though.
Comment 12 Nikolay Vladimirov 2007-06-19 16:38:48 EDT
I'm sorry, I was wrong. I thought some packages are required but they were just
alternatives. So I'll make libgsasl package without ntlm support since according
to the msmtp mailing list it's not needed. 

http://sourceforge.net/mailarchive/forum.php?thread_name=20070619184025.GA7766%40localhost.localdomain&forum_name=msmtp-users
Comment 13 manuel wolfshant 2007-06-19 16:44:49 EDT
If msmtp provides the functionality of sendmail in terms of sending mail
(attention, I emphasize: _sending_) it can very well replace the sendmail
package on machines which do NOT need a running SMTP daemon. There are already a
couple of other packages (esmtp - maintained by Patrice, ssmtp maintained by me)
who are perfectly suited for this type of tasks. Both of them handle gracefully
coexistence with the sendmail package as well as replacing it, when the admin
wishes to do that

OTOH I cannot convince msmtp to use fedora's GNU SASL.
cyrus-sasl-{md50,ntlm,devel,gssapi) are happily ignored. It looks like the
configure script looks for a gsasl.h/gsasl_check_version which I haven't located
yet.
Comment 14 manuel wolfshant 2007-06-19 16:51:52 EDT
OK, Cyrus SASL != GNU SASL. Should have figured that myself. If only I would
have read comment #12 before writing #13. Mid-air collision...
Comment 15 Patrice Dumas 2007-06-19 17:15:20 EDT
Three comments (not blockers)

I personally disagree with Manuel about providing MTA, since
I think that it is double with providing /usr/sbin/sendmail  
Not a big deal.

I think that it would be better to have ntlm support. It is
not an obligation, if you don't want to, don't do it, but
then you should rebuild gsasl if somebody else submit it
(and gsasl is accepted, of course :)

Regarding using the alternative mechanism like ssmtp and esmtp
do, I think it really should be left to your judgment. Although
I do it in esmtp I don't think it is particularly right. 
The main reason why I do it is because it is a requires for mutt.
But maybe it should be mutt that should be changed...
Comment 16 manuel wolfshant 2007-06-19 17:32:50 EDT
FWIW, I 100% agree with Patrice in all respects. Neither of this replacement
packages should provide MTA. But until all packages which requires MTA instead
of requiring /usr/sbin/sendmail are fixed, this is a functional workaround.
Anyway, just like Patrice has said it's up to you to decide.

With respect to sasl: the problem is somehow solved: package builds happily when
using Michael Flamings libgsasl
(http://www.enlartenment.com/packages/fedora/7/x86_64/repodata/repoview/libgsasl-0-0.2.16-1.fc7.mf.html)
I guess it's high time we kindly ask Michael to submit this package to Fedora
:). Unless someone else decides to do it, of course

Comment 17 Nikolay Vladimirov 2007-06-20 07:45:04 EDT
Ok. I'll do what the packagers for ssmtp and esmtp did. It's good to have
consistency with similar packages. 
About libgsasl. As it turns out it only needs libntlm. I don't like ntlm but
it's good to have full functionality. 
I think I will make libgsasl package and probably a libntlm one. If they are
approved I'll rebuild msmtp with libgsasl. 
I took a look at Michael Flamings's spec and there are some things I don't like
about it, so I'll make a new one. 


Comment 18 manuel wolfshant 2007-06-20 08:08:40 EDT
Theoretically speaking, you could include a first version of msmtp built with
gsasl disabled and rebuild it after libgsasl / libntlm is also included in
fedora. ON the other hand, since anyway you are not sponsored yet, you could
submit libgsasl, build it in fedora and afterwards build msmtp with full
functionality.
Comment 19 Nikolay Vladimirov 2007-06-20 09:48:41 EDT
Spec URL: http://ns.bgtld.net/build/msmtp.spec
SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.12-3.fc7.src.rpm

* Wed Jun 20 2007 Nikolay Vladimirov <nikolay@vladimiroff.com> - 1.4.12-3
- now using alternatives 
- added provides for sendmail 
- edited description 

I added alternative just for mta-sendmail because msmtp only transports mail. It
doesn't handle a queue or aliases. 
Comment 20 Patrice Dumas 2007-06-20 12:21:50 EDT
(In reply to comment #17)
> Ok. I'll do what the packagers for ssmtp and esmtp did. It's good to have
> consistency with similar packages. 

I don't think so. It is good when there is a clear best practice, 
but otherwise it is unnecessary or even bad, since there is no
way of comparing the different choices.

Comment 21 Nikolay Vladimirov 2007-06-20 13:30:59 EDT
 I did some further research - read the documentation, talked to a sys admin.
msmtp doesn't provide sendmail functionality. It's more of a relay agent than a
full feature MTA. So it's not an alternative to sendmail. Maybe the other
programs are and in their case the use of alternatives is good. 
So I think that msmtp shouldn't use alternatives. For now i'll leave the
provides for sendmail. I'll think it over again. And post the package tomorow. 

The problem with libgsasl is that it also requires GNU Sishi for KERBEROS_V5.
It's not needed for msmtp but libgsasl will not be fully functional. The last
sishi release was from last year so maybe it's no longer developed and I'll have
no trouble maintaining it. 
Comment 22 manuel wolfshant 2007-06-20 14:36:42 EDT
Neither esmtp nor ssmtp are full blown MTAs. Both (all three, taking msmtp into
account) are intended and can be used as drop-in replacements for sendmail for
those particular cases where one needs to send mail by explicitly calling
/usr/sbin/sendmail and not for the cases when one needs SMTP. mailx is one such
utility. mdadm also is perfectly happy with that...
Comment 23 Nikolay Vladimirov 2007-06-22 19:30:46 EDT
* Fri Jun 22 2007 Nikolay Vladimirov <nikolay@vladimiroff.com> - 1.4.12-4
- not using alternatives

Spec URL: http://ns.bgtld.net/build/msmtp.spec
SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.12-4.fc7.src.rpm

also source file in the srpm is with the correct timestamp.


The main problem with msmtp is that if it replaces sendmail it brakes all local
mail deliveries(that's not good). That includes syslog. Msmtp just takes the
mail from a MUA and relays it to a smtp server it doesn't really transports it;
the only destination is an smtp server. So there must be a configuration file
with account for every user(that uses mail) and an smtp server to send mail to.
Else sending mail just doesn't work. So if there is entry for msmtp in
alternatives and it's selected as system mta. All mail delivery will be broken
unless there is a valid configuration file(must be written by the sys admin).  
So as I said before the risk of breaking things if msmtp is system mta is big. 
I'll leave the provides for sendmail because of mutt and remove the use of
alternatives it's just not useful. 

Comment 24 Patrice Dumas 2007-06-22 19:47:49 EDT
(In reply to comment #23)

> 
> The main problem with msmtp is that if it replaces sendmail it brakes all local
> mail deliveries(that's not good). That includes syslog. Msmtp just takes the
> mail from a MUA and relays it to a smtp server it doesn't really transports it;
> the only destination is an smtp server. So there must be a configuration file
> with account for every user(that uses mail) and an smtp server to send mail to.
> Else sending mail just doesn't work. So if there is entry for msmtp in
> alternatives and it's selected as system mta. All mail delivery will be broken
> unless there is a valid configuration file(must be written by the sys admin).  
> So as I said before the risk of breaking things if msmtp is system mta is big. 

I mostly agree with you.

> I'll leave the provides for sendmail because of mutt and remove the use of
> alternatives it's just not useful. 

That seems wrong to me: it is not right to provide a file which
is not part of the package. A package Requiring %{_sbindir}/sendmail
will fail with msmtp installed.


Maybe the right solution would be to have mutt require something
else than %{_sbindir}/sendmail, for example MTA, drop the alternative
use in esmtp and ssmtp too and have those packages Provides MTA
(and have all the real mta also provide MTA). 

That way we would have the following meaning for the Provides:
smtpdaemon: a smtp daemon listens on the smtp port
%{_sbindir}/sendmail: the file is part of the package (using alternative)
  and can be used to send mail
MTA: the package provides a command that can be used to send mail

mutt would require MTA, most packages would requires %{_sbindir}/sendmail
and packages that send to localhost:smtp will require smtpdaemon (like
mlmmj bugzilla amavisd fetchmail)


Manuel, do you have an opinion?

Comment 25 Patrice Dumas 2007-06-23 05:43:11 EDT
Looking at mutt, it seems logical to requires /usr/sbin/sendmail
since it is what is used in the default case. So using alternatives
seems to me the only way to fill the provides for mutt. So here is
what I propose (for esmtp, msmtp and ssmtp):

* use alternatives, but only for what is truely provided. So
  no mailq, no newaliases in the alternatives system, only 
  /usr/sbin/sendmail
* use a lower value for priority than real mta. Real mta are
  at 30, so maybe use 20.
* don't provide mta or MTA: nothing use it in fedora, and it is
  ambiguous (what is a MTA? Something that sends mail, or also receive
  and deliver locally)?
* don't provide smtpdaemon, this means that a smtp daemon is listening 
  on 127.0.0.1, and neither of these packages provide that.

For information:

$ repoquery --whatrequires MTA mta
(nothing)
$ repoquery --whatprovides mta
(nothing)
$ repoquery --whatprovides MTA
postfix-2:2.4.3-3.fc8.i386
sendmail-0:8.14.1-2.i386
exim-0:4.66-3.fc7.i386
ssmtp-0:2.61-11.1.fc7.i386

$ repoquery --whatprovides smtpdaemon
postfix-2:2.4.3-3.fc8.i386
sendmail-0:8.14.1-2.i386
exim-0:4.66-3.fc7.i386
ssmtp-0:2.61-11.1.fc7.i386
$ repoquery --whatrequires smtpdaemon
mlmmj-0:1.2.14-2.fc7.i386
bugzilla-0:3.0-3.fc7.noarch
amavisd-new-0:2.4.5-1.fc7.noarch
fetchmail-0:6.3.7-1.fc7.i386
Comment 26 Nikolay Vladimirov 2007-06-27 19:36:50 EDT
Yes, leaving the provides for sendmail was wrong. 
I'm still concerned with the use of alternatives. 20 is low enough not to be
auto chosen by alternatives.

repoquery --whatrequires /usr/sbin/sendmail

mutt-5:1.5.14-4.fc7.x86_64
arpwatch-14:2.1a15-3.fc7.x86_64
pgp-tools-0:0.4.9-1.fc7.noarch
redhat-lsb-0:3.1-14.fc7.x86_64
mdadm-0:2.6.1-4.fc7.x86_64
bcfg2-server-0:0.9.3-2.fc7.noarch
quilt-0:0.46-1.fc6.x86_64
otrs-0:2.1.5-2.fc7.noarch
squirrelmail-0:1.4.10a-1.fc7.noarch
dbmail-0:2.2.5-2.fc7.x86_64
websec-0:1.9.0-4.noarch
fvwm-0:2.5.21-4.fc7.x86_64
uudeview-0:0.5.20-12.x86_64
fcron-0:3.0.2-2.fc7.x86_64

So it's not just mutt. And there is a chance that one of these doesn't work with
msmtp. Maybe because of the lack of local delivery or the account(or user)
oriented configuration or something else. 
And mutt requires sendmail interface so it must require sendmail binary.

So it seems it's better just not to tell mutt that it can use msmtp.



The packages for libntlm and libgsasl were successfully built in koji. So I can
add BuildRequires for libgsasl.  


Comment 27 Patrice Dumas 2007-06-28 04:29:27 EDT
mutt will certainly not require sendmail anymore, since it
now has a built-in smtp client. Review request for mutt is
Bug 226167.

So just removing sendmail Provides and the alternative system 
altogether seems right to me. I am still hesitant about what to
do for esmtp.
Comment 28 Nikolay Vladimirov 2007-06-28 05:15:56 EDT
* Thu Jun 28 2007 Nikolay Vladimirov <nikolay@vladimiroff.com> - 1.4.12-5
- removed provides for sendmail
- added BuildRequires for libgsasl

Spec URL: http://ns.bgtld.net/build/msmtp.spec
SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.12-4.fc7.src.rpm



Comment 29 Nikolay Vladimirov 2007-06-28 05:18:09 EDT
Wrong SRPM URL. It's

SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.12-5.fc7.src.rpm

Comment 30 Nikolay Vladimirov 2007-06-29 12:07:46 EDT
Now, when the whole alternatives thing is sorted out, can someone do the
official review of the package? 
Comment 31 Patrice Dumas 2007-06-29 17:54:36 EDT
I dislike the reference to mutt in the summary, I think
it should be more neutral. Maybe along:
SMTP client

I think that you should ship THANKS as %doc.

2 suggestions:
* add a blank line between %changelog entries

* use wildcards for man and info files, along

%{_infodir}/msmtp.info*
%{_mandir}/man1/msmtp.1*



Otherwise everything seems fine.
Comment 32 Patrice Dumas 2007-06-29 17:58:18 EDT
*** Bug 165932 has been marked as a duplicate of this bug. ***
Comment 33 Nikolay Vladimirov 2007-06-29 18:08:57 EDT
* Sat Jun 30 2007 Nikolay Vladimirov <nikolay@vladimiroff.com> - 1.4.12-6
- minor spec fixes

Spec URL: http://ns.bgtld.net/build/msmtp.spec
SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.12-6.fc7.src.rpm
Comment 34 Patrice Dumas 2007-06-30 04:37:47 EDT
* rpmlint is silent
* GPL, license included
* follow naming and packaging guidelines
* source match upstream
ba5b61d5f7667d288f1cfadccfff8ac5  msmtp-1.4.12.tar.bz2
* sane provides
* %files section right

APPROVED

2 remarks:
- info and man pages timestamps are not kept. The following
  should do the trick:
make install DESTDIR=$RPM_BUILD_ROOT INSTALL='install -p'

- linking is done by adding the library names to the command
  line instead of using -l. That's because 
  gnulib/m4/lib-link.m4 is used instead of standard autoconf
  macros. I have read a bit the code, seems like upstream wants
  to use $libdir/libsomething.so and set rpath whatever the 
  default path is. I don't really understand the implication
  of this choice. I guess that the result is right on Fedora
  in any case.

The link command is:

gcc -std=gnu99  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables   -o msmtp conf.o list.o msmtp.o net.o netrc.o
smtp.o stream.o tools.o tls.o ../gnulib/libgnu.a  /usr/lib/libgnutls.so
/usr/lib/libgsasl.so /usr/lib/libidn.so
Comment 35 Nikolay Vladimirov 2007-06-30 06:39:09 EDT
* Sat Jun 30 2007 Nikolay Vladimirov <nikolay@vladimiroff.com> - 1.4.12-7
- timestamps fix

Spec URL: http://ns.bgtld.net/build/msmtp.spec
SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.12-7.fc7.src.rpm

Comment 36 Nikolay Vladimirov 2007-06-30 17:40:24 EDT
Ah, I forgot about that: 

New Package CVS Request
=======================
Package Name: msmtp
Short Description: SMTP client
Owners: nikolay@vladimiroff.com
Branches: FC-6 F-7
InitialCC: 
Comment 37 manuel wolfshant 2007-06-30 18:09:24 EDT
Sorry for the delay in replying, I was in a short vacation. 

With respect to comment #24 and #25: I think that all packages which require
smtpdaemon, MTA and usr/sbin/sendmail should be hunt down, tested, the real
resource that they need should be identified and the package fixed according to
the proposal in comment #25. However I think that the provides which are
supported by the application (such as mailq for ssmtp - despite the fact that it
does nothing) should be kept.
For what is worth:
- syslog (and syslog-ng) and mdadm work very happy directly with the
/usr/sbin/sendmail file. I use them for almost an year on lots of live servers
with ssmtp relaying the messages to the core logging server. So I bet that if
msmtp would install a correctly configured alternative for /usr/sbin/sendmail
these packages would not break.
- squirrelmail can be configured to use either the sendmail binary directly or a
 SMTP server running on port 25. OTOH I am almost sure that no one installing a
webmail server would want to use esmtp/msmtp/ssmtp as backend.
Comment 38 Patrice Dumas 2007-06-30 19:52:21 EDT
(In reply to comment #37)
 
> With respect to comment #24 and #25: I think that all packages which require
> smtpdaemon, MTA and usr/sbin/sendmail should be hunt down, tested, the real
> resource that they need should be identified and the package fixed according to
> the proposal in comment #25. 

It seems to me that basically all the Requires for smtpdaemon 
and /usr/sbin/sendmail are right, especially now that mutt 
won't have the /usr/sbin/sendmail requires anymore.

> However I think that the provides which are
> supported by the application (such as mailq for ssmtp - despite the fact that it
> does nothing) should be kept.

Why should they be kept if they do nothing? It tricks the application
or the user than wants to use it, that's no good. However the 
package that use alternatives for mailq but in fact doesn't really 
implement it (ssmtp and esmtp) don't Provides it, so it is right
in my opinion.

> For what is worth:
> - syslog (and syslog-ng) and mdadm work very happy directly with the
> /usr/sbin/sendmail file. I use them for almost an year on lots of live servers
> with ssmtp relaying the messages to the core logging server. So I bet that if
> msmtp would install a correctly configured alternative for /usr/sbin/sendmail
> these packages would not break.

It depends whether a /usr/sbin/sendmail without local delivery is
right or not. I think that what I will do with esmtp is still provides
sendmail, but with lower priority. And I will leave only /usr/sbin/sendmail
in alternatives.


In any case I really think that Provides MTA should be removed.



> - squirrelmail can be configured to use either the sendmail binary directly or a
>  SMTP server running on port 25. OTOH I am almost sure that no one installing a
> webmail server would want to use esmtp/msmtp/ssmtp as backend.

squirrelmail requires /usr/sbin/sendmail, this is quite right.
Comment 39 Kevin Fenzi 2007-07-02 14:50:13 EDT
cvs done. 
Comment 40 Nikolay Vladimirov 2007-07-08 17:26:53 EDT
msmtp was built successfully with libgsasl support. For now I'm leaving the
package as it is and I'm closing the bug.

If there is a single user request for using alternatives I'll modify the package. 
Comment 41 Fedora Update System 2007-07-11 11:18:28 EDT
msmtp-1.4.12-7.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 42 Fedora Update System 2007-07-23 11:50:55 EDT
msmtp-1.4.12-7.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 43 Kai Bolay 2007-10-09 22:00:35 EDT
(In reply to comment #40)

 > If there is a single user request for using alternatives I'll modify the 
 > package. 

I'd like to use msmtp (or it's alternative (pun intended!) ssmtp or esmtp) on
systems where no local users should receive mail. Instead all mail should go to
a central server. So I would like the package to provide /usr/sbin/sendmail via
the alternatives system.
Comment 44 Patrice Dumas 2007-10-10 03:31:22 EDT
esmtp uses the alternatives system and since there is now a 
rudimentary queue system, and esmtp can use a mda for 
local delivery, I have left the priority to 30.

If msmttp uses the alternatives system, maybe it should 
use a lower level (unless there is local delivery at least).
Comment 45 Nikolay Vladimirov 2009-01-19 06:02:30 EST
Package Change Request
======================
Package Name: msmtp
New Branches: EL-5
Owners: turki
Comment 46 Kevin Fenzi 2009-01-19 18:23:13 EST
cvs done.
Comment 47 Peter Lemenkov 2013-09-01 05:11:20 EDT
Package Change Request
======================
Package Name: msmtp
New Branches: el5 el6
Owners: peter
Comment 48 Kevin Fenzi 2013-09-01 14:24:57 EDT
Git done (by process-git-requests).

(There was already a el5 branch)

Note You need to log in before you can comment on or make changes to this bug.