On 26/01/05 12.47, Thomas Roessler wrote:
> On 2005-01-26 12:40:48 +0100, Mads Martin Joergensen wrote:
[snip]
> > ... but the simple smtp client to enable
> > mutt to use a relay-server is something closely tied together to
> > the client itself IMO.
>
> We're on Unix, remember? "Do one thing, and do it well."
>
> There are command line SMTP clients around that you can integrate
> with mutt by changing a simple configuration variable, and for any
> kind of a complex setup (think queuing), you're better served with a
> full-fledged MTA anyway.
>
> In short, an SMTP client is one of the things that, in my view,
> *clearly* don't belong into mutt.
Very good point indeed (and I for one agree that mutt should remain
smtp-less). If we assume that this policy stands, how could the
authentication problem be solved? How about looking at the pgp/gpg
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?
/dossen
PS: If anything I think that a future mutt could stand to have some of
the features seperated into external programs, setup as defaults
with a welldefined interface. And perhaps some way to leverage
mutts input-features (prompts, lists of selectable options, etc.)
for use as arguments for programs invoked from hooks, macros,
pipes, etc. With good defaults (either builtin or external) and
lots of interfacing options that could make mutt and even better
mua. But that is just me being tired and dreaming out loud ;-)
Attachment:
pgpRLg1wGOsdE.pgp
Description: PGP signature