Re: Mutt Next Generation
On Wednesday, 26 January 2005 at 16:52, Will Yardley wrote:
> On Wed, Jan 26, 2005 at 05:50:19PM -0600, David Champion wrote:
> > * On 2005.01.26, in <20050126233821.GA9470@xxxxxxxxxxxxxxxxxxxxx>,
> > * "Mads Laursen" <dossen+mutt@xxxxxxxxxxx> wrote:
> > > >
> > > > In short, an SMTP client is one of the things that, in my view,
> > > > *clearly* don't belong into mutt.
> >
> > I fear that something is inevitable, as the SMTP world changes. SMTP
> > AUTH is on the rise, like it or not -- and it's not just about spam
> > prevention, so you can't even make a moral high ground argument about
> > strategy.
>
> Well it's certainly possible to configure most MTAs to authenticate to
> a smarthost using SMTP auth, though it's definitely a pain in the ass,
> so I don't think SMTP AUTH alone is a reason this functionality needs to
> be built in to mutt.
>
> I don't think I'd personally use the feature, but I do think this
> would be a good feature to have in mutt if it could be implemented,
> all "purism" aside. I'm not a programmer, but I guess I don't understand
> quite how this could bloat mutt that much more than any of the other
> features that have been added, even if some people don't like it on
> ideological grounds. Heck... make it a compile-time option or something.
FWIW I'm weakly in favor of a simple SMTP submission agent in mutt. I
don't think the complexity is any worse than the pop code (probably
much less), and it can easily share the existing network/TLS/SASL
code. Per-user authentication is much more convenient from within mutt
(although the gpg passfd approach is also viable, of course, assuming
someone eventually writes a decent command-line submission agent).
I also think queue management is a bit of a straw man. If you can't
get confirmation that a server accepted your mail, you can just save
it as a draft. Or do the same thing you do when the $sendmail command
fails.