[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stephen J. Turnbull
Subject: Re: Changing the default for `send-mail-function'
Date: Tue, 05 Jul 2011 17:28:37 +0900

Richard Stallman writes:

 >     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.

What was unclear about the description of the initial bug submission
process that followed?  It was somewhat elliptical, but I thought the
general idea was clear enough.

 > 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.

No, it's not about using multiple protocols for sending mail.  It's
about using a non-mail protocol for the initial submission only, it
doesn't apply to later correspondence about a particular issue, and
certainly not to general mail.  The process for deciding was described
there and is further elaborated below.

 > I want to avoid asking users to configure SMTP on systems where
 > sendmail works.

I'm suggesting that report-emacs-bug need not ask users to configure
SMTP ever.  Ask them if they know "for sure" that Emacs can send mail.
If the answer is "yes", (1) send the mail, and (2) configure Emacs to
always use mail.

If the answer is "no", then (1') ask for the user's mail address
(report-emacs-bug may default to something bogus), (1'') submit it via
an HTTP-to-mail gateway, and (2') if submission succeeds, configure
Emacs to always use the HTTP-to-mail gateway, otherwise (3) report the
failure to the user and attempt to send by mail, notifying the user
that mail submission is unreliable and suggesting they check the bg
database using a web browser or debbugs.el (in the future Emacs will
ask for preferred submission method again).

There are possible interactive variations on (2) and (2'), but this is
the minimal interaction setup.

 > 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.

Let's put it this way: my opinion is that extensive discussion will
profit nobody involved, unless you desire to learn a huge amount of
detail about the mail system and the packaging and installation
procedures for MTAs for their own sake.  From their posts, I suspect
that Stefan and Yidong agree.

 > 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.

I understand that; my opinion is that (a) what you have in mind as
described is not sufficient to meet your own requirements, unless you
relax the reliability requirement to a point unacceptable to people
using the system, and (b) it is not possible without the cooperation
of many third parties, who will demand many adjustments before they
are willing to implement.  Not to mention that changes to the mail
system take time measured in decades to implement fully.  It's not
something that should concern the Emacs project, IMO YMMV.

I think that the amount of work, especially on your part, to come to a
meeting of minds (the lead maintainers and yours) on "fixing sendmail"
far exceeds the costs of "Just Do It"-ing the HTTP gateway proposal,
which is a very simple design and therefore easy to evaluate, both
cost and benefit, and requires no cooperation from anyone outside of
the GNU Project.

Ted Z proposed a method[1], which I have elaborated above, that
satisfies all of your requirements, except that it isn't 100% email
for *all* users.  (Most users can still use email for all of their bug
reporting, however.)  The costs are:

(1) A one-time yes-no configuration for all users of report-emacs-bug,
    requiring about 10-15 lines including the prompt strings.
(2) An estimated 10-15 lines of hacking using url.el for the HTTP
    submission, including the status report strings.  The message
    generation part of report-emacs-bug needs no change -- the report
    will be submitted as an RFC-822-formatted message, and gatewayed
    verbatim to a standard MTA.
(3) Installation of a very simple CGI at a gnu.org host.

(1) could be avoided by simply having report-emacs-bug always use the
HTTP gateway, but this may not work in firewall configurations where
users gateway SMTP mail via a smarthost and otherwise may have no
connection to the net from personal workstations, (2) is on offer from
Ted IIUC, but I can do it in late August if nobody else does it by
then, and (3) will require somebody with privileges on an appropriate
host.  I won't do (3) -- there are security implications on a
sensitive host, and I am familiar with neither security policy nor the
infrastructure there -- so somebody would need to volunteer for that.

[1]  Lars proposed a very similar method using the same design but a
different submission protocol.  However, Ted and I agree that it is
inferior in terms of robustness to intervening firewalls.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]