Rant - Emacs mail is not user friendly

["Stephen J. Turnbull" <stephen@xemacs.org>]

Kelly Dean writes:

 > > In particular, mail
 > > queuing is about as complex as things get.  MUAs normally delegate
 > > queuing to the MTA (that's how I handle disconnected operation on my
 > > laptop, for example, and that's the *only* reason I run Postfix on my
 > > laptop), and in that sense feedmail.el is a hack.

 > It doesn't seem very complex, at least on the user side of
 > things.

Of course the user doesn't perceive the complexity!  It's hidden in
the abstractions of "MUA" and "MTA".  You're breaking the abstraction
by taking on the queuing function of the MTA outside of an MTA.

 > You might want to consider msmtp instead of Postfix on your laptop.

Anything is possible.  But why in the world would I want to do that?
On the one hand, Postfix was near zero effort to install and
configure, and on the other, no problems since.  Furthermore, I use it
on several other machines, besides needing to be able to support it
when Mailman site admins ask questions about Mailman/Postfix
configurations.  My laptop certainly can spare the cycles.

 > > I'm sure you have good reason for doing that,

 > Yes. Emacs on my machine doesn't have Internet access.

I don't care about your reason, that's what I said.  I only care about
what you did, which I have reason to believe was asking for exactly
the kind of trouble you experienced.

 > > but that is a very unusual use case.

 > I certainly hope not! The usual case is that a person's instance of
 > Emacs has access to his data (otherwise, Emacs wouldn't be very
 > useful); if my use case is unusual, that means the usual case is
 > that his Emacs has access not only to his data, but also to the
 > Internet.

Indeed, it does.  That is the usual case, no matter what you hope.
You don't have to like it, but it nevertheless informs the design of
programs like feedmail.

 > With a program like Emacs serving as a bridge, that means
 > his data isn't his data, but instead belongs to some Russian or
 > Chinese hacker, whoever crosses the bridge first, and the original
 > owner is permitted to retain a copy of the data just due to the
 > hacker's mercifulness, or maybe just as bait so the hacker can get
 > even more data later. The years when normal people weren't targets
 > are long gone.

You have evidence for Emacs being used in that way by crackers?  (I
agree with you that Emacs that has an attack surface that amounts to
the whole world, and practically, that securing it is too hard to
think about succeeding, but that's not a popular view on this list.
And it's just theory.)

 > > Bottom line: I think the task you were trying to accomplish is far
 > > more complex that you are admitting, and has little to do with "user
 > > friendliness" of Emacs MUAs.

 > My previous, manual workflow was:

Indeed.  *Your* *manual* workflow, *mediated by two very complex
programs*, the webmail program and the MTA behind it, which have a
traditional and well-defined, but fundamentally arbitrary division of
labor -- which you are not respecting in your redesigned workflow.
Similarly with message-mode and the send-mail module in Emacs.

 > That was inconvenient, so I decided a better workflow would be:
 > 0. Compose a message in Emacs in standard format, with Subject and To headers separated from the body by a blank line.
 > 1. Add the From, Date, and Message-ID headers.
 > 2. Save the message to a file foo in an outbox directory.
 > 3. Run ⌜msmtp -t < outbox/foo⌝
 > 4. If #3 succeeds, then run ⌜mv outbox/foo sent/foo⌝

An excellent analysis, indeed.  So why did you choose an excessively
complex program apparently designed for a different workflow, aka
feedmail.el, to do step 2?  Just save the message using write-file,
with a little extra Lisp to construct an appropriate queuefile name
and to remove MUA artifacts like the header delimiter line.  Add a
tiny shell function to do 3 and 4.  This amount of Lisp would probably
cost less keystrokes and thinking overall, although a bit more design,
than configuring feedmail.