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.
(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.
Changelog * Mon Jun 11 2007 Nikolay Vladimirov <nikolay> - 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.
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 .
No problem with duplicate functionalities.
* Tue Jun 19 2007 Nikolay Vladimirov <nikolay> - 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
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.
Please also consider including the content of the doc subdirectory, I think that the examples would be useful for users.
* Tue Jun 19 2007 Nikolay Vladimirov <nikolay> - 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.
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.
(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.
As a side note LibIDN, libgcrypt, and a gss api are in fedora. libntlm doesn't seems to be in fedora, though.
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
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.
OK, Cyrus SASL != GNU SASL. Should have figured that myself. If only I would have read comment #12 before writing #13. Mid-air collision...
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...
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
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.
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.
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> - 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.
(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.
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.
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...
* Fri Jun 22 2007 Nikolay Vladimirov <nikolay> - 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.
(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?
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
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.
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.
* Thu Jun 28 2007 Nikolay Vladimirov <nikolay> - 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
Wrong SRPM URL. It's SRPM URL: http://ns.bgtld.net/build/msmtp-1.4.12-5.fc7.src.rpm
Now, when the whole alternatives thing is sorted out, can someone do the official review of the package?
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.
*** Bug 165932 has been marked as a duplicate of this bug. ***
* Sat Jun 30 2007 Nikolay Vladimirov <nikolay> - 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
* 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
* Sat Jun 30 2007 Nikolay Vladimirov <nikolay> - 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
Ah, I forgot about that: New Package CVS Request ======================= Package Name: msmtp Short Description: SMTP client Owners: nikolay Branches: FC-6 F-7 InitialCC:
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.
(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.
cvs done.
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.
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.
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.
(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.
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).
Package Change Request ====================== Package Name: msmtp New Branches: EL-5 Owners: turki
Package Change Request ====================== Package Name: msmtp New Branches: el5 el6 Owners: peter
Git done (by process-git-requests). (There was already a el5 branch)