On 2012-07-30 12:42:32 -0500, Derek Martin wrote:
> On Sat, Jul 28, 2012 at 11:19:25AM +0200, Rado Q wrote:
> > > On Wed, Jul 25, 2012 at 10:51:54AM +0200, Fredrik Gustafsson wrote:
> > > > Just of curiosity, why are mutt moving away from a mua to a full email
> > > > program with mail fetching and mail sending.
> > >
> > > {...} and because the internet landscape has made it hard for
> > > users to run their own services (thank you, spammers).
> >
> > Using built-in SMTP-client or a standalone SMTP-client doesn't make a
> > difference for the ISP, it can't tell what software executes the SMTP.
>
> No, but it makes a difference to the USER. Mutt is already hard to
> configure. If you have to configure sendmail to talk SMTP on the MSP
> port, enable STARTTLS, pop-before-smtp, etc. you need to learn a lot
> about sendmail. No one should need to do that just to be able to send
> an e-mail.
No-one is forced to use sendmail. Is there any advantage of using
a built-in SMTP-client instead of a standalone SMTP-client? By
that, I mean: is there any advantage of having a single process
rather than two different processes?
I would rather see a standalone SMTP-client (possibly designed for
Mutt users) than a built-in SMTP-client: if there's a bug in the
SMTP-client (yielding a crash or memory corruption), it won't affect
the main process. And this is true for any feature that could be
implementated as a separate process *without much drawback*.
[...]
> Many of us don't agree. Mutt solves a whole class of mail-related
> problems that other clients don't solve, or solve poorly; but at the
> same time, there are a lot of things that people who use e-mail do
> that mutt doesn't handle well. The biggest one IMO is HTML mail...
> It's very popular, as it allows people formatting options that are
> very useful for written communications. Mutt handles this rather
> poorly. Reading HTML mail is clunky, and AFAIK there really are no
> good options for generating it with Mutt's tool chain.
Not sure what you mean by that. Is this related to the text-terminal
based UI? There's also the problem of replying to HTML mail, keeping
formatting options. An editor would be needed too. :)
> Now you can argue that people shouldn't use HTML e-mail, but that
> argument is at best outdated... Based on my daily use I would guess
> that people who use HTML e-mail are now in the majority, and Mutt's
> inability to handle it well is a big weakness.
Even though HTML wasn't designed for e-mail (formatting is nice,
but there should have been standard specification for quoting,
attribution and things like that), I think that a partial support
could be useful, mainly because there is nothing else. But you
have to be very careful and disable some features for security
reasons (Javascript?, links like <a href="some_url">other_url</a>).
> You can say HTML can be handled by a web browser, and you'd be right
> -- but that solution is clunky at best, and if you need to retain
> formatting for others later in the thread, you really need another
> e-mail client.
And this could be bad for security. For instance, external images
shouldn't be loaded by default.
> Also I've brought this up before, and there was a very negative
> response from a lot of people, so I expect the same from you... but I
> think it bears saying in context of this discussion. This ties into
> the comment above, but there are other reasons. Mutt could benefit
> greatly from having an *optional* GUI.
I agree, as long as it remains optional. In particular, I miss mouse
support (e.g. fast scrolling with a mouse). If a GUI is implemented,
there should be a way to switch to the text interface (and back to
the GUI) without quitting the Mutt session.
But even before having a GUI, I think it would be useful to be able
to use Mutt without quitting the editor opened to compose a message
(starting a second instance has drawbacks if one wants to modify
the mailbox).
> Mutt's area of operation is e-mail... are you saying that submission
> of e-mail via SMTP is not related to e-mail? =8^) If you take this
> philosophy to its extreme, there is no need for Mutt at all; you can
> simply tie together all the other pieces together with some shell
> scripts! So let's do that... let's disband mutt and instead write
> some documentation on how to write shell scripts that tie together
> your editor, fetchmail, and an SMTP agent of some sort, all the MIME
> handling software, etc.; and let the users all do everything
> themselves. That's the ultimate ideal of the Unix philosophy...
> This would certainly be the most customizable option!
There would be no problems with that if all is done transparently so
that the end user won't notice how this is implemented internally
(except if he wants to look at it).
I think that Mutt shouldn't go the Firefox way, where a small problem
somewhere can make the whole application unstable.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
