Re: smtp crap

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

chad writes:
 > 
 > On Oct 26, 2011, at 3:32 PM, Drew Adams wrote:
 > 
 > >>> This is nothing but a regression - reporting a bug with `emacs
 > >>> -Q' has never been a problem in past releases.  Why burden 
 > >>> and confuse users now?
 > >> 
 > >> I have personally seen dozens, of emacs bug reports sitting 
 > >> stuck in local mail queues, [...].
 > > 
 > > Yes, that is undesirable.
 > 
 > Undesirable, well know, and obviously the opposite of ``has never been
 > a problem in the past'', as you knew before you wrote those words.  It
 > also pretty clearly answers the question ``Why burden and confuse
 > users now?''.

Incredible!  The problem is clearly in the bug report instructions,
which should say something like:

    Note that emacs *may* be able to send mail on some systems, but if
    you haven't tested sending mail from Emacs[*], it is best to
    compose your report using M-x report-emacs-bug, and save that
    buffer to a file.  Then read it into your usual mail agent (or
    attach it as a file to your mail).  If you do send the bug report
    directly via C-c C-c, please double check that your return address
    is correct before doing so.

[*] A reference here to an Info node about configuring mail for Emacs
*might* be appropriate.  But then again, it might not.

and

    - It is best if you provide a recipe starting from "emacs -Q",
      with a minimum number of external libraries etc needed to
      demonstrate the bug.

      ("emacs -Q" is relatively unlikely to be able to send mail, and
      may not even be able to report failures.  If you use Emacs as
      your MUA and have not tested mail under "emacs -Q", you should
      save the bug report buffer to a file and send it via a normal
      emacs process, ie, without "-Q".)

The blurb in the bug report buffer should repeat the paragraph
starting with "Note".  The "save and attach" dance really is not a lot
of trouble compared to the rest of the bug reporting process.

Or perhaps those notices are already present, and the problem is in
the deplorable deterioration of the reading level of some users.  But
users who don't pay attention to those notices are hardly likely to be
able *and* willing to configure mail to send one bug report.[1]

 > > The solution is to simply _mention_ in the bug-report
 > > instructions that "IF you have no mail client and IF you have not
 > > yet configured Emacs itself as a mailer, THEN invoke `M-x XYZ' to
 > > so configure it.", where XYZ is a command that leads you down
 > > whatever configuration garden path is required.

Drew, I'm shocked.  This is no time to be configuring mail, which is a
process fraught with fear, uncertainty, and doubt.

The real solution (which bears repeating, despite the resistance it
has encountered from some quarters) is to try to submit initial
reports via a reliable point-to-point protocol (eg, HTTP) that will
either succeed or fail immediately, then fall back to email.  (The
fact that HTTP can fail due to lack of a configured proxy etc is
immaterial; what's important is that the user is informed of the
failure, which a store-and-forward protocol like mail cannot do.)

If "bug reports in email queues not configured for relay to remote
hosts" is on the increase, it is almost certainly due to users'
familiarity with bug report processes that do not use mail for
transport, whose expectation is that the bug report system knows what
it's doing.

 > Seems like a pretty poor default to me. YMMV.

Asking anyone except maybe Eric Allman to configure mail in the middle
of the bug report process is about as poor a default as I can imagine.



Footnotes: 
[1]  I'll concede that the word "deplorable" is unfair to many users,
particularly those who use English as a second language.  But if
reading the bug report instructions is difficult in a second language,
how can mail configuration instructions be any easier?