Spec Url: http://haleph.com/download/rpms/msmtp.spec
SRPM Name or Url: http://haleph.com/download/rpms/msmtp-1.4.3-1.src.rpm
Description: In the default mode, msmtp 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.
Why not use gnu sasl? It brings more features. Is it because gnu sasl doesn't
work on Fedora? I cannot find it in fedora, if it isn't submitted somebody would
have to, however...
Until GNU SASL is published in Fedora, this package work and can be included IMHO.
* Name is OK
* Source msmtp-1.4.3.tar.bz2 is the same as upstream
* The BuildRoot is the preferred one
* Spec looks OK
* rpmlint looks OK
* File list looks OK
* Seems to work fine
One thing though : please change http://prdownloads.sourceforge.net into
http://dl.sourceforge.net so that the tarball can be downloaded automatically.
If GNU SASL is published, please remember to update your package. Does it work
with Cyrus SASL ?
Thanks for the comments. "prdownloads" has been changed to "dl" in the new spec
and SRPM at
I have been unable to find information on interoperability with Cyrus SASL and
am inclined to believe that it is not possible. I'll be working on a GNUSASL
spec file in the mean time, though it is not my forte.
(assigned to myself for clarity, package already approved)
The only diff between release 2 and release 1 is the fixed source URL, so it's
still approved. If you're still interested in this package, please go ahead and
I'm not an Extras Contributor and thus cannot commit it, but anybody who has
commit access is welcome to import it.
(In reply to comment #6)
> I'm not an Extras Contributor and thus cannot commit it, but anybody who has
> commit access is welcome to import it.
You can become a contributor by going through the process outlined in
http://fedoraproject.org/wiki/Extras. Since you submitted the package for
review, this would be a good starting point.
What does msmtp bring in terms of functionality that is not already supplied by
esmtp (which uses libesmtp, and is available in extras)? Is it worth duplicating
Also, it may be worth using the alternatives system to set this as the system
mailer - see the esmtp spec for an example.
But then again, given that neither msmtp and esmtp do local delivery, I wonder
if this breaks things.
(In reply to comment #8)
> What does msmtp bring in terms of functionality that is not already supplied by
> esmtp (which uses libesmtp, and is available in extras)? Is it worth duplicating
Duplicated functionality doesn't matter in Extras, only in Core.
(In reply to comment #9)
> Also, it may be worth using the alternatives system to set this as the system
> mailer - see the esmtp spec for an example.
> But then again, given that neither msmtp and esmtp do local delivery, I wonder
> if this breaks things.
I do agree that using the alternative system may be a bad thing as there is no
fallback (although I am the esmtp maintainer, so I did it for esmtp ;-), so I
think that the choice to use or not to use the alternative system should be left
to the packager.
Any particular reason why this package is not yet imported and built ?
This package is already approved and has not been imported for a long time. I am
going to close this in a week if this is not imported within that time frame.
And eight months later this package still isn't in. I'm removing FE-ACCEPT and
closing this ticket.
*** This bug has been marked as a duplicate of 243631 ***
Package Change Request
Package Name: msmtp
New Branches: EL-5
Sorry about this wrong bug number.