www.devco.net by r.i.pienaar

1. 

   Sven Guckes
   December 18th, 2003 - 06:06

   there are many MTAs which can be used with mutt:
   Courier, esmtp, exim, masqmail, postfix,
   qmail, sendmail, smail, and zmailer -
   and there are also some small one,
   like nullmailer, smtppush, and ssmtp.
   so – msmtp is not the only one out there.
   besides, if everyone included smtp in the mailer
   then you deliberately put the problems of it into
   the hands of the *user* – and all of the careful
   work of the admin is suddenly useless because the user screwed up. the bigger the site the less mailers with built-in smtp i would allow as admin.
   i can only suggest to use the default setup for
   “sendmail” within mutt – and let the rest be the problem of the admin. if he knows what he is doing then you will not have a problem at all.
   ymmv.
   –Sven Guckes [a happy mutt user since 1996]
   see also:
   http://www.guckes.net/mta/
   http://www.guckes.net/mutt/
2. 

   R.I.Pienaar
   December 31st, 2003 - 16:02

   I am hosting a shell server with many many domains and many unique From addresses for the users on the box. It would be almost impossible to configure a MTA “correctly” to allow for the default mutt configuration.
   Instead my users SMTP to the local mail servers which are all configured correctly to allow relaying through and it allows the users to choose a From address rather than the admin. My users all have a clue when it comes to unix administration and in my setup mutt+smtp works 100% better than mutt-smtp.
   It’s very naive for a development team to think they can imagine all possible scenarios in which people will want to use their software.
3. 

   R.I.Pienaar
   March 2nd, 2004 - 07:58

   As of today I have had 126 referers from Google – 21 a month on average – on people searching for SMTP capabilities in Mutt.
   It seems that the Mutt development team really is missing a much required feature and maybe they should start paying closer attention to user needs instead of making suggestions such as sticking to default when for countless permutations of setups it just isn’t a good default.
4. 

   Jeff McClure
   May 20th, 2004 - 19:19

   I’m one of those people who found this page while Googling for SMTP capabilities in Mutt.
   I can understand the position of not wanting to put SMTP support in Mutt. There is a certain elegance in being able to say, “My software is a widget, and that’s all it does.” In addition, the argument that Sven Guckes made above (that adding this support allows users to circumvent the admin’s policy) makes some sense. The added support could certainly make it a little easier to work around local mail restrictions. However, I would argue that if using a local SMTP client to send mail to the local MTA messes up site policy, it’s not the user’s fault, it’s the admin’s fault for not tying down the MTA to meet the policy (that “careful work” wasn’t quite careful enough). It’s not like adding SMTP to Mutt would be the only way around that particular hurdle.
   Up to that point, though, I can at least sympathize with the attitude. However, the next part is where I have to leave the train. In the next paragraph, Sven says, “i can only suggest to use the default setup…” In effect, Sven is saying, “Don’t use the software the way you want to, use it the way I say, because that’s the way it’s supposed to work.” Sven doesn’t ask anything about the mail setup or even admit that “the default setup” might not work very well. It’s just assumed that that if you’re not using the “default”, then you’re doing something wrong.
   I’ve seen this attitude before, and it really pisses me off. Oddly enough, it seems to be pretty common among people involved with email software. I’m all for the goal of standards compliance and for making an effort to use a system the way it was intended (it usually works better that way). Let’s get serious, though. We are using email today in ways that people didn’t even dream of back when the original RFCs were written, yet the basic mechanisms used in email haven’t changed much at all in the last 20 years or so. It’s silly to believe that the “standard” setup is always going to work for everyone.
   It just so happens that some of us have to do a couple of not-so-typical steps to make our email work the way it should work. If the Mutt maintainers doen’t want to write their software to help with that, then that’s okay…but telling people not to use something that works (without even asking about the user’s setup) is pretty silly.
   Thanks for the link to MSMTP. It turned out (in my case) to be exactly what I needed.
5. 

   Anonymous
   August 9th, 2004 - 21:31

   bruno te amo
6. 

   Mark Nipper
   February 3rd, 2005 - 14:49

   Here’s hoping Mutt never includes SMTP functionality. I am another person who randomly stumbled across this page looking for SMTP AUTH support in Mutt from Google and once I saw some of the suggested command line tools, things made perfect sense.
   Turning Mutt into something like Emacs (think big, bloated and slow (oh but it’s so feature rich!!)) is an extremely bad idea in my opinion. It is a(n) MUA and as such should not deal with SMTP directly. If it was something like Thunderbird, then I might see a need for such things. But seeing as how most of the people using Mutt grok the command line more than your average computer user, calling an external program is just the way it ought to be. That’s Unix. And it allows for the most flexibility.
   But that’s just my opinion of course…
7. 

   Robert Thompson
   August 17th, 2006 - 04:33

   There is an important difference in “general purpose” and “highly specializable”. Thunderbird is very much general purpose. Mutt is extremely specializable. With a little work, you can make mutt do almost anything. Thunderbird probably already does it (and with less effort to you), but you pay in terms of resource usage. Thunderbird is a very good tool, but there are many situations that it cannot be reasonably adapted to.
   I tend to favor minimal-resource solutions, so I prefer the Mutt approach. I also tend to solve problems in some of the more out-of-the-way corners of the envelope, and the Mutt approach does this well too…
   One (unrelated) thing that always bugged me. The “IMAP is not a MTA” mindset appeared to be a wise decision at a time open port-25 unauthenticated submission was acceptable. These days, we separate MTA and submission roles, so as to be able to authenticate and verify submission. If the debate were to happen today, having OUTBOX functionality in IMAP (and of course an equivalent POP function) would eliminate one of the prime causes of mailserver complexity and misconfiguration. After all, the IMAP server already has a complete and functional auth layer, so why add parallel and redundant functionality into the MTA? It may just be me, but I’ve tripped across far more edge conditions and fuzzy areas while configuring smtp auth in various environments than I ever have while setting up even the most oddball IMAP server, even on the same machine…. Oh well, too late now; the consensus has already happened.
8. 

   anatoly pugachev
   April 24th, 2008 - 10:17

   mutt got smtp support, http://www.mutt.org/doc/devel/ChangeLog
   see comment of Brendan Cully on date 2007-02-24 06:37:32
9. 

   Poor Yorick
   February 21st, 2010 - 01:43

   Here’s another drop-in sendmail replacement which works with mutt and tries to use a secure channel first:

   http://www.ynform.org/w/Pub/SendmailPy

Leave a comment