Re: Changing the default for `send-mail-function'

[Tim Cross <theophilusx@gmail.com>]

On Mon, Jul 4, 2011 at 9:39 PM, Richard Stallman <rms@gnu.org> wrote:
>    Perhaps we can make progress if you permit me to ask you a question.
>    What's wrong with a two-protocol system?
>
> I don't know whether something is wrong with that, because the
> question is not entirely clear.
>
> I have nothing against making Emacs able to use multiple
> protocols for sending mail.  Having those capabilities
> can't hurt anyone.  The question is how Emacs decides which
> method to use.
>
> I want to avoid asking users to configure SMTP on systems where
> sendmail works.  Some of them won't know that sendmail works, or what
> sendmail is, they just send mail and it works.  If Emacs tells them,
> "Please configure SMTP to send mail," they won't know this is not
> really necessary.  They may waste a lot of time looking for a way to
> do that.  If Emacs asks them whether configuring SMTP is necessary,
> they won't know the answer.
>
>      I don't have time for
>    general discussion of failure modes of the mail protocol, with a view
>    to repairing sendmail.  It's too difficult.[1]
>
> You don't have to discuss it, but that doesn't convince me that
> making sendmail reliably fail when the MTA is not really set up
> is too difficult.
>
> Also, your footnote [1] suggests we are not talking about the same
> question.  What I have in mind does not match what you say there.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>  Use free telephony http://directory.fsf.org/category/tel/
>
>

Wow, amazing how something so simple can get so complex so quickly!

I think Stefan's suggestion is a good one for handling the situation
of being able to reliably submit a bug report for emacs users who do
not use emacs for mail and therefore may or may not have mail
configured (and may or may not know if it is).  However, it should
also be noted that in some situations, mail is a more reliable
submission method than http. The weakness of http is that the http
server must be up and running at the point where I submit the bug
report. With mail, I can actually send a message which most mail
servers will repeatedly attempt to deliver for up to (frequently)_ 5
days. So, if the gnu.org mail system is unavailable for a few hours or
possibly a couple of days, my message will still get through.

I think Richard's points are also very valid, but address a slightly
more general issue of email and emacs. It is probably more in line
with the original suggestion of changing the default behaviour for the
send-mail-function. This is a more complex issue. It would seem

     - Not all platforms are equal. For example, Eli pointed out that
win32 should probably use the existing/default    mail client as the
default. This seems reasonable and in-line with user expectations on
that platform.

     - Someone mentioned that there may be information defined by xdg
that could be useful in determining the appropriate default for
systems that support it. Probably worth further investigation

     - Lars has written an interactive 'assistant' function. This
seems like a good idea on many levels. It may need
enhancing/expansion, but seems to be flexible and has the potential to
meet the widest range of individual requirements/expectations.
However, it does not address Richard's point of users who may not be
aware of how the underlying mail mechanism works, that they already
have a functioning MTA or what the right answers is and who will
become frustrated and waste time trying to solve a non-problem

Part of the problem here seems to be a lack of any real facts
concerning the current situation. It has been argued that MTAs are
often misconfigured and that the 'modern' approach is to configure a
specific server (often with authentication information) so that mail
will work form multiple networks etc. Taken at face value, this seems
reasonable for users running emacs on a laptop. However, is this just
users running emacs on a GNU/Linux laptop or does it hold for all
platforms, including OSX and Win32? Does this represent a significant
number of users or is this only a minority group and are the majority
doing fine with the existing defaults? Do we see lots of bug reports
concerning failed bug submission as a result of MTA issues or do we
just not see bugs from this group because they fail to submit? Is
there any real evidence that a majority of GNU/Linux systems that have
an MTA installed are misconfigured or is this just speculation? Should
we be considering different defaults for GNU/Linux laptops compared to
desktops? Can we assume an MTA on a GNU/Linux desktop is more likely
to be in a working state than one on a laptop that may be connected to
a foreign network? What is the breakdown of emacs user platforms? Are
the majority of users on wind32, OSX, GNU/Linux or something else?

Whatever the answer is, I do tend to agree with Stefan and others that
having emacs try to determine if an MTA is available AND correctly
configured is something that would take a lot of work and is unlikely
to ever be that reliable. Of course, a lot depends on your
interpretation of 'correctly configured', but at the base level, it
would have to at least mean that it could dispatch a message to
another mail server which could directly or indirectly deliver the
message or at least bounce it back to the originating server (possibly
not to the originating sender). Given that a mail message can sit with
a server for up to 5 days before it is returned, testing for bounces
may not be feasible. It certainly isn't something that could be done
reliably in 'real-time'. However, it may be possible to extend Lars'
'assistant' idea with some heuristics that could be used to try and
make life easier for the  user. Perhaps what we should focus on is in
making it easier for the user to get things setup and less on
automation?

Tim