On 6/13/07, Ag. D. Hatzimanikas <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 13, at 10:28 Alexander E. Patrakov wrote:
> > [EMAIL PROTECTED] 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:[EMAIL PROTECTED]: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_\
> [EMAIL PROTECTED]: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
--enable-imap.
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.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
