<<< Date Index >>>     <<< Thread Index >>>

Re: Mutt Next Generation



On Thu, Jan 27, 2005 at 08:15:50AM -0600, Charles Cazabon wrote:
> John Franklin <franklin@xxxxxxxxx> wrote:
> > On Wed, 2005-01-26 at 20:23 -0500, Jean-Pierre Radley wrote:
> > > My preference is that mutt should remain the superb MUA that it is, and
> > > not attempt to also be an MTA at all, at all, at all.
> > 
> > I heard this argument from the time I first started using mutt about six
> > years ago.  Back then I accepted it as good, but since then I've been
> > coming around to the other point of view.
> 
> I haven't.  I still strongly believe that SMTP does not belong in the MUA.  I
> don't even think POP belongs in it (I'm the author of getmail), but I'm not
> beating that particular horse at the moment.
> 
> > I think mutt can include basic SMTP support without crossing the line
> > into MTA territory.
> [...]
> > Not full queuing and load management and MX record searching
> > SMTP support.  It only needs to do three things:
> >     1. Send to a single mailserver.  All messages -> one server.
> >     2. Handle SMTP AUTH & TLS
> >     3. Be as simple to setup as IMAP or POP.
> 
> Since you can already accomplish this with an external agent like ssmtp, and
> integrating it into mutt wouldn't buy you anything, what's the point of
> integrating it at all?

See below.

On Thu, Jan 27, 2005 at 04:08:29PM +0100, Werner Koch wrote:
> On Wed, 26 Jan 2005 23:37:03 -0500, John Franklin said:
> 
> > Grab an existing libsmtp.  Don't support the code yourself, anymore than
> 
> So what you actually want is a simple sendmail like tool speaking SMTP
> in way that it may perfectly be used with Mutt.  If the existing ones
> don't do that; a new one has to be written.

I want one fewer program to configure to do a basic task: e-mail.  I want
common things to be trivial.  I want mutt to manage the passwords.
 
> No reason to put SMTP code into Mutt.  Write a specialized MTA which
> might also be useful for other tools.  This is the Unix way and the
> working approach on code reuse.

Why?  Why should I have to install yet-another-program, deal with the
password management issues mentioned elsewhere in this thread, 
yet-another-config file, and no easy way to change the target server or
user name or SSL options from inside mutt?  Mutt can reuse code just as 
well by linking in an SMTP library.  No SMTP code would be in mutt per 
se, it would be in the SMTP library.

Claims of UNIXy are nice, but will that be a consolation when mutt get 
forked?  There is a crying need for this feature (see the others on this 
list who hav asked for it), a patch already exists[1], and yet no one is 
willing to integrate it in to the tree?

The patch is UNIXy in its own way.  Mutt is good at managing e-mail.  
libESMTP is good at delivering e-mail to a server.  They're 
both simple tools that do their thing well.  Rather than fork off a 
process, use a library call.  The library has function parameters as 
its API.  The process has command line options.  What's the difference?

[1] http://www.deez.info/sengelha/projects/mutt/libesmtp/
jf
-- 
John Franklin
franklin@xxxxxxxxx
ICBM: N37 12'54", W80 27'14" Z+2100'

Attachment: pgpxAtDETXMr4.pgp
Description: PGP signature