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

[Stephen J. Turnbull]

Richard Stallman writes:

 >     However, one case described earlier (which is a common case) is that
 >     the bounce messages end up in root's mailbox (eg via the postmaster
 >     alias).  In that case, Emacs won't be able to read the mail.
 > 
 > Indeed it won't, but what is the situation where this occurs?
 > What causes it?

and

 > However, the clean solution is to establish a conventional way for
 > programs to determine whether a machine has an MTA that should be
 > used.  sendmail should fail in a specific recognizable way when there
 > is not one.

Richard, you're not the only one who is busy.  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]  OTOH, several
proposals have been made for 99.9999% reliable[2] submission mechanisms,
whose protocols already exist and the mechanisms themselves are easy
to implement in Emacs, while requiring only a very small amount of
scripting at the other end.

Perhaps we can make progress if you permit me to ask you a question.
What's wrong with a two-protocol system?  I am thinking of one that
uses the novice mechanism or similar, that presumes that most users
will have Emacs configured to send mail reliably already, and starts
the submission process by asking:

    The preferred and most convenient method to communicate with the
    Emacs issue tracker is by email.  But if you don't already use
    Emacs to send mail, I can use another mechanism (HTTP) for the
    initial submission of this report.

    Would you like me to send by mail now?  (y/n)

etc, etc

If the user elects HTTP, prompt for a mail address where they can be
reached, and store it (maybe in user-mail-address, maybe in a
report-emacs-bug-specific variable, haven't thought about that).

Then if the bug report was sent, ask if the same method should be used
in the future for initial submissions.  In the confirmation message
make it clear that HTTP is *only* for initial submissions (as is M-x
report-emacs-bug itself).

It would be easy to implement using url.el and a very simple CGI at
gnu.org that simply pipes the already-formatted mail message into a
known-good MTA (ie, at gnu.org).

Note that there is no need to worry about future correspondence; that
can be done in the usual way via mailing lists and personal mail.  It
is only the *initial* submission which would use this mechanism.  This
completely sidesteps all of the issues with unconfigured mail systems,
because followup correspondence can be conducted via the user's usual
mail system.  (Note that the initial submission doesn't need to use
HTTP, although IMO Ted Z is right, that HTTP is most reliable for
non-technical reasons, specifically, the fact that if the firewall
won't pass an outgoing HTTP POST, there's no way to guess what port
might be open.  But the Emacs project could use an MTA on a
non-standard port at a gnu.org host that Emacs could connect to
directly, etc.)

How about it?  AFAICS Ted or maybe Lars would be very happy to
implement such a thing.

Footnotes: 
[1]  Nor would such a facility would be generally useful IMO.  Users
who want to send mail to other hosts using sendmail will notice it's
broken quickly, and get expert help quickly.  They want it fixed, not
to be told "don't do that".  Most programs that automate remote
communications do not use email for the purpose any more.  Email
*cannot* provide reliability[2] to programs, while other protocols can
and already do.  It makes no sense to start with a protocol that is
likely to fail, and fallback to a reliable one, in automated reporting.

[2]  In the sense of a very high probability of success, while
providing a nearly absolute guarantee that failure will be detected.