r6805 - in trunk/BOOK: . basicnet/mailnews introduction/welcome

Dan Nicholson dbn.lists at gmail.com
Wed Jun 13 06:44:41 PDT 2007

On 6/13/07, Ag. D. Hatzimanikas <a.hatzim at gmail.com> wrote:
> On Wed, Jun 13, at 10:28 Alexander E. Patrakov wrote:
> > dnicholson at linuxfromscratch.org wrote:
> >
> > >  <screen><userinput>./configure --prefix=/usr --sysconfdir=/etc \
> > > +    --with-docdir=/usr/share/doc/mutt-&mutt-version; \
> > > +    --enable-pop --enable-imap --enable-smtp &&
> >
> > Sorry Dan, but I disagree with your comment in Trac: "I also left out the
> > --with-sasl since none of the other --with-* args are explained. Hopefully
> > you know that if you need SMTP auth, you need sasl."
> >
> > For me, this bit of knowledge looks non-obvious. I used msmtp on the CD
> > before --enable-smtp got added, and it didn't need SASL for SMTP
> > authentication. I think that many Mutt users follow the thame line of
> > thought. Moreover, from Trac comments, it looks like it took Ag two rebuilds
> > to figure this out.
> Personally, I don't build mutt with smtp support, just because of
> reasons like this.
> It adds complexity to built instructions (many dependencies),
> and... unnecessary code, which may lead to bugs, *unrelated* to the core
> mutt (which I am interested).

To be fair, the SMTP code has no additional dependencies. The SMTP
auth code requires one additional dependency, cyrus-sasl. And that's
no different than if you want to use POP or IMAP with authentication.
So, for me, it added no dependencies.

Keep in mind that the --enable-pop and --enable-imap options have been
in the book for months and it didn't bother anyone that sasl wasn't
explained, even though it's the exact same issue as SMTP auth.

> Another thing is that, if you enable smtp support, you have to supply
> the password every time you need to send a message (nightmare if you also
> use mutt in scripts), or this returns to ugly (to say at least) situations,
> like:
> set smtp_url="smtp://username:mypassword@smtp.gmail.com:587
> in your muttrc
> Un-desirable, dangerous and stupid; you have to give your muttrc special
> permissions.
> Or,
> set smtp_url="smtp://username:`awk '/^password/{print $2}' ~/.somefile_with_special_\
>                 permissions`@smtp.gmail.com:587
> Hack!

This is also SMTP auth. You could relay to another SMTP server on your
LAN, for instance, without authentication. Then you could just have a
single MTA on one PC.

That sounds like a flaw if it doesn't cache the password while it's
running. Another thing to think about is that if you're scripting
mail, then you probably want a local MTA. Enabling SMTP relay in mutt
doesn't change that.

Let's keep in mind that the default operation of mutt is still to use
a local mailspool with the local MTA. Nothing has changed there.
--enable-smtp doesn't seem to be any different than --enable-pop or

Just want to be fair here.

> While I initially was happy with smtp support, I turn out to be the opposite, as
> times goes on.
> A MTA and especially a sendmail compatible MTA, is absolutely necessary to a
> _production_ system and we have to recommend it with any chance.
> This also conforms with the Unix tradition (one tool for one job).
> For these reasons, we have to warn users about the possible flaws in the
> built-in smtp support and to mention also to build it --with-sasl and perhaps
> --with-ssl, if we want to be complete.

I think they both deserve explanation, but I took a shortcut because I
didn't feel like explaining the other --with-* options. But, ssl and
sasl are on by default if they're found. Adding it to the command
explanations implies that it's not on unless you add the switch.

The three things that I think deserve explanation are: --with-ssl,
--with-sasl and --with-slang. The last one just to warn people that
they don't need it since ncurses is fine.

> Personally as I said above, I prefer to have a MTA to do smtp-relay and let mutt to
> do what it was supposed to do, but for the book; quite honestly I am undecided.
> The guy in balance in me says, to disable smtp support, and to explicitly mention
> (the --enable-smtp switch) in the Command Explanations, with a note to link it
> against Cyrus SASL, because some common smtp servers like googlemail, use it for
> smtp authentication.

I don't mind leaving the SMTP relay support off by default and just
leaving it in the command explanations. To me, though, it's win-win to
have --enable-smtp just like --enable-imap. Now I have the flexibility
to use local or remote mailspool and local or remote MTA.

> A patch that make use of above thoughts attached.
> It also fixes a forgotten applied patch.
> Feel free to apply a better wording or a different approach.

Oh, the patch! That's what you were referring to. I don't know how I
missed that. Fixing that now.


More information about the blfs-book mailing list