Re: Mutt Next Generation
* 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.
> support, where external programs need a password. If mutt could be set
> to prompt for a password, and pass it securely to the $sendmail
> program, would that not afford the needed flexibility, without putting
> stuff in mutt that does not belong?
This would be a fair solution, IMO. Unfortunately there are not very
many good SMTP submission agents available, and I'm not sure there's
anything to graft such a feature onto right now. I've been looking at
a lot of SMTP submission programs lately for other reasons, and they
pretty much all are awful for one reason or another. We'll need a new
one, or extensive changes to an old one, but I think this is the way to
go for now.
The old "store it in a file and protect the file" solution is just not
good security for large sites. My SMTP AUTH server requires a password
that's used for everything on my campus, from e-mail to web access to
electronic resources to buying airline tickets through the campus travel
office. I'm not about to put that on my filesystem for any reason, or
under any measure of pseudo-protection -- especially not on a public
login server.
Mutt needs to address large installations as well as the desktop.
--
-D. dgc@xxxxxxxxxxxx NSIT::ENSS