smtp crap

smtp crap

[Miles Bader]

Why does emacs _keep_ asking me if I want to "Set up Emacs for sending
SMTP mail"?!

My computer has a MTA, it works; if Emacs tries to send smtp directly,
it very possibly _won't_ work[*].  So this question isn't just
annoying, it's harmful.

I kept answer "n" to this question, but just now I accidentally
answered "y" -- and now only did that one piece of mail end up in the
bit-bucket, but emacs now seems to be in a state where it thinks I
want to use smtp -- it keeps asking me for an smtp server -- even
though I've changed the variable (`send-mail-function') back to what I
guess it should be (`sendmail-send-it').

[*] the ISP's smtp server is picky: you need both authentication
(postscript does this; does gnus?) and to be careful about the
envelope sender -- it has to have a valid hostname, which the system
hostname is not (blame NTP...).

-miles

-- 
Conservative, n. A statesman enamored of existing evils, as opposed to a
Liberal, who wants to replace them with new ones.

smtp crap

[Miles Bader]

Why does emacs _keep_ asking me if I want to "Set up Emacs for sending
SMTP mail"?!

My computer has a MTA, it works; if Emacs tries to send smtp directly,
it very possibly _won't_ work[*].  So this question isn't just
annoying, it's harmful.

I kept answer "n" to this question, but just now I accidentally
answered "y" -- and now only did that one piece of mail end up in the
bit-bucket, but emacs now seems to be in a state where it thinks I
want to use smtp -- it keeps asking me for an smtp server -- even
though I've changed the variable (`send-mail-function') back to what I
guess it should be (`sendmail-send-it').  Ok, I needed to _also_
change back `message-send-mail-with-sendmail' (why?).

[*] the ISP's smtp server is picky: you need both authentication
(postscript does this; does gnus?) and to be careful about the
envelope sender -- it has to have a valid hostname, which the system
hostname is not (blame NTP...).

-miles

-- 
Conservative, n. A statesman enamored of existing evils, as opposed to a
Liberal, who wants to replace them with new ones.

Re: smtp crap

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> Why does emacs _keep_ asking me if I want to "Set up Emacs for sending
> SMTP mail"?!  I kept answer "n" to this question

I can't reproduce this.  The first time I answer "n", it customizes
send-mail-function and saves that variable to the init file.  This
should prevent the question from recurring.  Could you try to figure out
what's causing that to fail?

RE: smtp crap

[Drew Adams]

> > Why does emacs _keep_ asking me if I want to "Set up Emacs 
> > for sending SMTP mail"?!  I kept answer "n" to this question
> 
> I can't reproduce this.  The first time I answer "n", it customizes
> send-mail-function and saves that variable to the init file.  This
> should prevent the question from recurring.  Could you try to 
> figure out what's causing that to fail?

Even if it works flawlessly, this "feature" should _not_ be the default.

In particular, it is ridiculous that a user trying to send a simple bug report
with `emacs -Q' has to run through the extra hurdle of this inane, possibly
confusing, and error-prone dialog ("yes"; edit the `From' line; "n").  I cannot
believe this silliness has gone on this long already.

Nowadays especially, users already have email configured on whatever devices
they use.  They don't need Emacs asking them to help it out by configuring email
- ever.  Emacs does not need that by default, and neither do its users.  This is
akin to a spam popup - just annoying and uninvited.

If a user really wants or needs to configure Emacs for email, s?he can figure
out how to do that - that's what the doc should be for.  Let users go looking
for how to do it before you start asking them whether they really want to do it.

Why are we going backward, not forward?  Why is it suddenly important for every
user to be interrogated (even once!) about configuring email for Emacs?  (How
did we get by all these years without this annoyance?)

Re: smtp crap

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 7 Oct 2011 23:17:35 -0700
> Cc: ding@gnus.org, emacs-devel@gnu.org
> 
> Nowadays especially, users already have email configured on whatever devices
> they use.

That's mostly true on MS-Windows, but people are saying not on other
systems.  I'm not in a position to argue whether this is true or false
on Posix platforms.

Chong and Lars, any objections to changing the default value of
send-mail-function to mailclient-send-it for MS-Windows only?

RE: smtp crap

[Drew Adams]

> > Nowadays especially, users already have email configured on 
> > whatever devices they use.
> 
> That's mostly true on MS-Windows, but people are saying not on other
> systems.  I'm not in a position to argue whether this is true or false
> on Posix platforms.

And I'm not in a position to judge, but I would be surprised if nearly every
user of a smart device didn't already have email configured for it.  "Systems"
are mobile and Internet-connected now, whether they run on Windows, Posix,
petroleum, or plutonium.  Even photocopy machines and ebook readers know about
email nowadays.

> Chong and Lars, any objections to changing the default value of
> send-mail-function to mailclient-send-it for MS-Windows only?

That would be a start.  But I have yet to see any real argument for not
returning to the noiseless UI behavior of yore, pre this regression - for all
"systems".

Let users look for how to configure XYZ if they really need to configure XYZ.
Don't be annoying them by soliciting their participation in a configuration
dance.  If they really want to dance, they'll come ask you - no need to ask
them.

Re: smtp crap

[David Engster]

Drew Adams writes:
>> > Why does emacs _keep_ asking me if I want to "Set up Emacs 
>> > for sending SMTP mail"?!  I kept answer "n" to this question
>> 
>> I can't reproduce this.  The first time I answer "n", it customizes
>> send-mail-function and saves that variable to the init file.  This
>> should prevent the question from recurring.  Could you try to 
>> figure out what's causing that to fail?
>
> Even if it works flawlessly, this "feature" should _not_ be the default.
>
> In particular, it is ridiculous that a user trying to send a simple bug report
> with `emacs -Q' has to run through the extra hurdle of this inane, possibly
> confusing, and error-prone dialog ("yes"; edit the `From' line; "n").  I cannot
> believe this silliness has gone on this long already.

For the record: I remember the first time I tried to send a bug report
at my old institute on a GNU/Linux machine. The result was a mail with
something like a "funny" mail-host-not-set-so-tickle-me or something
somewhere, leading to a a phone call from IT asking what I could
possibly be doing. So at least I think the new behavior is better.

-David

Re: smtp crap

[Bastien]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > Why does emacs _keep_ asking me if I want to "Set up Emacs 
>> > for sending SMTP mail"?!  I kept answer "n" to this question
>> 
>> I can't reproduce this.  The first time I answer "n", it customizes
>> send-mail-function and saves that variable to the init file.  This
>> should prevent the question from recurring.  Could you try to 
>> figure out what's causing that to fail?
>
> Even if it works flawlessly, this "feature" should _not_ be the
> default.

+1.  I've been bugged by this before too.

-- 
 Bastien

Re: smtp crap

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> Even if it works flawlessly, this "feature" should _not_ be the default.

I agree.

Besides the reasons you list, as I mentioned in my previous message,
"simple" smtp may very well not work, even if the user knows the right
hostname to use (as is the case with my ISP).

_Allowing_ people to configure emacs to directly use SMTP is good;
_defaulting_ to it is not, nor is prompting the user like it does
currently (how many people will know how to respond to this unexpected
series of prompts?  what if they respond incorrectly?).

-Miles

-- 
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.

Re: smtp crap

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Chong and Lars, any objections to changing the default value of
> send-mail-function to mailclient-send-it for MS-Windows only?

I don't think `mailclient-send-it' is a very satisfactory solution for
sending email.  It pops up a different mailer, and the user has to take
actions there, too, to actually send the mail.

And it doesn't support MIME, so you can't add attachments, and so on.

mailclient makes Emacs into a second-rate mail client, which seems
unfortunate as a default.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: smtp crap

[Harry Putnam]

"Drew Adams" <drew.adams@oracle.com> writes:


[...]

> Even if it works flawlessly, this "feature" should _not_ be the default.
>
> In particular, it is ridiculous that a user trying to send a simple bug report
> with `emacs -Q' has to run through the extra hurdle of this inane, possibly
> confusing, and error-prone dialog ("yes"; edit the `From' line; "n").  I cannot
> believe this silliness has gone on this long already.

[...]

I agree but wanted to tell you that I too was seeing that problem for
a time.  I cannot recall now what I did to stop it, or maybe it just
went away on an update of nognus.

And I'm not finding anything in .gnus, .emacs or site-start.el
regarding smtp or send.

Sorry I cannot help but at least you know there is some kind of fix.

-------        ---------       ---=---       ---------      -------- 
OOOPS back that `can't help' part up a minitue

 I checked .emacs-custom on `send' and think I've found the fix
maybe:

(custom-set-faces
(custom-set-variables
     '(send-mail-function (quote sendmail-send-it))))

Must have done that in customize but I agree with you that I shouldn't
have had too.  Why change a default that has worked well for must of
us for so long. 

Maybe its a reflection of where the majority of the emacs user base is. 

Re: smtp crap

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: Drew Adams <drew.adams@oracle.com>,  cyd@stupidchicken.com,  emacs-devel@gnu.org,  ding@gnus.org,  miles@gnu.org
> Date: Sat, 08 Oct 2011 15:47:55 +0200
> 
> I don't think `mailclient-send-it' is a very satisfactory solution for
> sending email.  It pops up a different mailer, and the user has to take
> actions there, too, to actually send the mail.

Any user of a Windows system will already be familiar with the system
mailer.  And even if she isn't, pressing the "Send" button doesn't
require you to be Einstein ;-)

Anyway, we had that value for a long time, and I don't remember any
Windows users complaining.

> mailclient makes Emacs into a second-rate mail client, which seems
> unfortunate as a default.

It is vastly better than a sophisticated, first-class mailer that the
user doesn't know how to set up.

And mind you, we won't be preventing users from reconfiguring to use a
better mailer.  It's just the default, it can be customized.  If we
want, we can provide a command for such a configuration, which will
run the same code that is now in sendmail-query-once.

RE: smtp crap

[Drew Adams]

> > Chong and Lars, any objections to changing the default value of
> > send-mail-function to mailclient-send-it for MS-Windows only?
> 
> I don't think `mailclient-send-it' is a very satisfactory solution for
> sending email.  It pops up a different mailer,

A "different" mailer?  Different from what?  From Emacs?

How about: it pops up the SAME mailer the USER chose and is used to and
comfortable with.  Are we trying to shove Emacs down people's throats, as a
_mailer_?

> and the user has to take actions there, too, to actually send the mail.

Uh yeah, "take actions": `C-a C-v'.  Big deal.  No one has complained about
that.  And if you want to and can obviate the need to hit `C-a C-v' too, then by
all means, please do.

But please do not try to use that need to paste the composed message (`C-a C-v')
as a reason to keep to this ridiculous, extraneous dialog that is not even
initiated by the user.

> And it doesn't support MIME, so you can't add attachments, and so on.

What is "it"?  What are you talking about?  I add attachments all the time with
the mailer I use on Windows.  And of course it supports MIME.

Please stop worrying about what other mailers support.  And please stop imposing
the solicitation
"are-you-sure-you-don't-want-to-SWITCH-to-Emacs/gnus-NOW-as-your-mailer?" on
users.  This thing is completely misguided.

> mailclient makes Emacs into a second-rate mail client, which seems
> unfortunate as a default.

It doesn't make Emacs into anything.  It simply means _not_ using Emacs as a
mail client.  So what?  Stop trying to push Emacs as a mail client.  Let users
_request_ it if they want it.  _After_ they request it, then you can lead them
down the garden path through whatever contorted dialog you like.

When a user is simply trying to report a bug - to help improve Emacs! - is no
time to interrupt her with an attempt to get her to configure Emacs as her mail
client (even if she already has a mail client).  And in fact _no_ time is
appropriate for doing that.

I really cannot believe this one got past the maintainers and they have remained
silent about it for months.

Re: smtp crap

[Michael Welsh Duggan]

Miles Bader <miles@gnu.org> writes:

> Why does emacs _keep_ asking me if I want to "Set up Emacs for sending
> SMTP mail"?!
>
> My computer has a MTA, it works; if Emacs tries to send smtp directly,
> it very possibly _won't_ work[*].  So this question isn't just
> annoying, it's harmful.
>
> I kept answer "n" to this question, but just now I accidentally
> answered "y" -- and now only did that one piece of mail end up in the
> bit-bucket, but emacs now seems to be in a state where it thinks I
> want to use smtp -- it keeps asking me for an smtp server -- even
> though I've changed the variable (`send-mail-function') back to what I
> guess it should be (`sendmail-send-it').

I recently solved this problem for myself.  I was seeing the same
behavior.  The problem was this: sending mail called the function stored
in message-send-mail-function.  This variable is initialized in
message.el from send-mail-function, which defaults to
sendmail-query-once.  Once I answered "n" to the query, it changed
send-mail-function for sendmail-send-it via customize.  Unfortunately, I
use a separate custom file by setting custom-file in my .emacs.el.  At the
end of my .emacs.el, I load the file with (load custom-file).

What happens here is that send-mail-function is set to
sendmail-query-once, then my .emacs.el is read.  In my .emacs.el, I have a
(require 'message), which then initializes message-send-mail-function to
sendmail-query-once.  Then my .emacs.el loads my custom file, which sets
send-mail-function to sendmail-send-it.  Then, when I send mail, it
calls sendmail-query-once, as this is what message-send-mail-function is
set to.

I fixed this by loading my custom file before requiring message.el.
Your problem may be different, but if not, this experience of mine
might help.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: smtp crap

[Tim Cross]

Hi Lars,

putting aside all the excellent work you have put into updating and
improving smtpmail et. al., I think this message possibly sums up the
disconnect in opinions on this issue.

While you are correct that mailclient is a poorer solution for doing
email from within emacs, this overlooks those who in the main don't
want to use emacs for mail, but on occasion, for things like emacs bug
reports, may need/want to. For this class of user, having to setup
emacs mail support is irritating, maybe even annoying. The most likely
already have a configured mail client and it is likely the client they
are most familiar with. For them, mailclient may be a better solution
for those rare occasions they need to initiate an email message from
within emacs.

For those who really do want to use emacs as their mail client, I tend
to agree with Drew in that it is not unreasonable to expect them to
put in the effort to set it up.

This whole debate has a strong feeling of decisions being made by
people based on their own experience/desires and a belief that their
position is a majority perspective. This does not at all reflect my
own personal experience. While I do use emacs a lot as an email
client, most of the people I actually know who also use emacs don't -
in fact, they are somewhat amazed I do or that I bother contributing
to the maintenance of one of the older emacs MUA packages.

Part of the problem here is that we don't really have any idea of what
percentage of emacs users fall into what group. The current changes
appear to be driven by an underlying assumption that a majority of
users also use emacs as their email client.

I wonder if it would be worth analyzing mail header of emacs-devel
posters for a period to get a breakdown. As this would represent a
group of users with a considerable level of investment in emacs, it
would probably only give a rough metric, but would at least be
something to base decisions on rather than the current guesswork and
assumptions.

Tim


On Sun, Oct 9, 2011 at 12:47 AM, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Chong and Lars, any objections to changing the default value of
>> send-mail-function to mailclient-send-it for MS-Windows only?
>
> I don't think `mailclient-send-it' is a very satisfactory solution for
> sending email.  It pops up a different mailer, and the user has to take
> actions there, too, to actually send the mail.
>
> And it doesn't support MIME, so you can't add attachments, and so on.
>
> mailclient makes Emacs into a second-rate mail client, which seems
> unfortunate as a default.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>  bloggy blog http://lars.ingebrigtsen.no/
>
>



-- 
Tim Cross
Phone: 0428 212 217

Re: smtp crap

[Miles Bader]

Michael Welsh Duggan <md5i@md5i.com> writes:
>> Why does emacs _keep_ asking me if I want to "Set up Emacs for sending
>> SMTP mail"?!
>
> I recently solved this problem for myself.  I was seeing the same
> behavior.  The problem was this: sending mail called the function stored
> in message-send-mail-function.  This variable is initialized in
> message.el from send-mail-function, which defaults to
> sendmail-query-once.  Once I answered "n" to the query, it changed
> send-mail-function for sendmail-send-it via customize.  Unfortunately, I
> use a separate custom file by setting custom-file in my .emacs.el.  At the
> end of my .emacs.el, I load the file with (load custom-file).

Yes, I also use a separate ".custom" file, so that would appear to be
the issue...

> I fixed this by loading my custom file before requiring message.el.
> Your problem may be different, but if not, this experience of mine
> might help.

It shouldn't be necessary to do that, though.

-Miles

-- 
Accord, n. Harmony.

Re: smtp crap

[Sivaram Neelakantan]

On Sat, Oct 08 2011,Eli Zaretskii wrote:


[snipped 13 lines]

> Anyway, we had that value for a long time, and I don't remember any
> Windows users complaining.
>

This was done in the 23.1 release, right?  Because I was surprised
that Emacs was trying to launch F'Fox to send email on my win32
machine when I was using gnus for quite sometime.  I think I read the
NEWS file and the manual to figure out what to do next.  Though it did
take some time for me to figure it out.


[snipped 5 lines]

>
> And mind you, we won't be preventing users from reconfiguring to use a
> better mailer.  It's just the default, it can be customized.  If we
> want, we can provide a command for such a configuration, which will
> run the same code that is now in sendmail-query-once.
>
>

what about checking whether there's a .gnus file, or a VM,
Mews/rmail(and other Emacs only mail client) dot file and not doing
anything in such a case?  Yes, I understand, users can name their dot
files arbitrarily but since we are trying defaults....

 sivaram
 -- 

Re: smtp crap

[Michael Welsh Duggan]

Miles Bader <miles@gnu.org> writes:

> Michael Welsh Duggan <md5i@md5i.com> writes:
>>> Why does emacs _keep_ asking me if I want to "Set up Emacs for sending
>>> SMTP mail"?!
>>
>> I recently solved this problem for myself.  I was seeing the same
>> behavior.  The problem was this: sending mail called the function stored
>> in message-send-mail-function.  This variable is initialized in
>> message.el from send-mail-function, which defaults to
>> sendmail-query-once.  Once I answered "n" to the query, it changed
>> send-mail-function for sendmail-send-it via customize.  Unfortunately, I
>> use a separate custom file by setting custom-file in my .emacs.el.  At the
>> end of my .emacs.el, I load the file with (load custom-file).
>
> Yes, I also use a separate ".custom" file, so that would appear to be
> the issue...
>
>> I fixed this by loading my custom file before requiring message.el.
>> Your problem may be different, but if not, this experience of mine
>> might help.
>
> It shouldn't be necessary to do that, though.

I agree.  I think that rather than having message-send-mail-function
take the value of send-mail-function as a default, it should instead
default to a new function which calls send-mail-function.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: smtp crap

[Tim Cross]

On Mon, Oct 10, 2011 at 1:50 AM, Sivaram Neelakantan

[snip]

 > what about checking whether there's a .gnus file, or a VM,
> Mews/rmail(and other Emacs only mail client) dot file and not doing
> anything in such a case?  Yes, I understand, users can name their dot
> files arbitrarily but since we are trying defaults....
>

The issue is about whether your emacs uses smtp to send mail via a
remote MTA or a locally installed one.  It is further complicated by
the fact that an unknown number of users don't actaully want to use
emacs as their MUA AT ALL. and are irritated by questions concerning
emacs and smtp which they see as irrelevant.

Checking to see if the user is using gnus, VM, mew, wonderlust et. al.
doesn't really help as all of these mail user agents can use either a
local MTA or a remote MTA. For your suggestion to work, it would be
necessary to both know what all the config files are for each MUA and
then also interpret that config to tell if it is using a local MTA or
a remote MTA.  As you point out, there is also the problem of people
using non-standard names for config files. However, in addition to
this, there is the problem that many of these emacs MUAs can/do use
custom for configuration options and may not even have a MUA specific
config file or may have their config details spread between both
package specific config files and custom data, which itself could be
in .emacs or somewhere else.

Note that I think the behavior where emacs is repeatedly asking what
you want to do is a bug and not a feature. From my understanding of
what Lars wanted to do, this question should be asked only once.
Others have argued that asking it even once may be too often.

Tim

-
Tim Cross

Re: smtp crap

[Richard Riley]

Tim Cross <theophilusx@gmail.com> writes:

> On Mon, Oct 10, 2011 at 1:50 AM, Sivaram Neelakantan
>
> [snip]
>
>  > what about checking whether there's a .gnus file, or a VM,
>> Mews/rmail(and other Emacs only mail client) dot file and not doing
>> anything in such a case?  Yes, I understand, users can name their dot
>> files arbitrarily but since we are trying defaults....
>>
>
> The issue is about whether your emacs uses smtp to send mail via a
> remote MTA or a locally installed one.  It is further complicated by
> the fact that an unknown number of users don't actaully want to use
> emacs as their MUA AT ALL. and are irritated by questions concerning
> emacs and smtp which they see as irrelevant.

Its being repeatedly asked? I havent seen that.

Re: smtp crap

[Stefan Monnier]

>> > Why does emacs _keep_ asking me if I want to "Set up Emacs 
>> > for sending SMTP mail"?!  I kept answer "n" to this question
>> I can't reproduce this.  The first time I answer "n", it customizes
>> send-mail-function and saves that variable to the init file.  This
>> should prevent the question from recurring.  Could you try to 
>> figure out what's causing that to fail?
> Even if it works flawlessly, this "feature" should _not_ be the default.

As long as we don't have a better solution, yes it should be
the default.  And for Emacs-24 we won't have a better solution so it
will be the default.

mailclient-send-it is not a satisfactory solution, it's a workaround.

> In particular, it is ridiculous that a user trying to send a simple bug report
> with `emacs -Q' has to run through the extra hurdle of this inane, possibly
> confusing, and error-prone dialog ("yes"; edit the `From' line; "n").  I cannot
> believe this silliness has gone on this long already.

Editing the From is indeed a bug that we have to fix before
the release.  Maybe you could submit a patch for it?

> Nowadays especially, users already have email configured on whatever devices
> they use.

Yes, e.g. configured on Emacs.

> Why are we going backward, not forward?  Why is it suddenly important for every
> user to be interrogated (even once!) about configuring email for Emacs?  (How
> did we get by all these years without this annoyance?)

We got by all these years because both SMTP and /usr/sbin/sendmail
actually used to work or fail reliably.  Nowadays byzantine errors are
the rule for them so we need user input to figure out what to do.


        Stefan

Re: smtp crap

[Stefan Monnier]

> I don't think `mailclient-send-it' is a very satisfactory solution for
> sending email.

Agreed.  We need something better.

> It pops up a different mailer, and the user has to take
> actions there, too, to actually send the mail.

Popping up a different mailer is not a problem: it's what mailclient is
supposed to do.  The problem is that it comes into play much too late:
mailclient should not be an MTA function but a MUA function.

I.e. not a send-mail-function value but a mail-user-agent value.
Of course, the problem is that `compose-mail' assumes the
mail-user-agent is "inside Emacs", so we need to introduce a new
function that makes fewer assumptions.


        Stefan

RE: smtp crap

[Drew Adams]

> > It pops up a different mailer, and the user has to take
> > actions there, too, to actually send the mail.
> 
> Popping up a different mailer is not a problem: it's what 
> mailclient is supposed to do.  The problem is that it comes
> into play much too late: mailclient should not be an MTA
> function but a MUA function.
> 
> I.e. not a send-mail-function value but a mail-user-agent value.
> Of course, the problem is that `compose-mail' assumes the
> mail-user-agent is "inside Emacs", so we need to introduce a new
> function that makes fewer assumptions.

That sounds very much like a project for the next Emacs release.  And it sounds
like you have no real design in mind for it yet.

Until that project is well defined, more than half-baked, and you have something
to test for it, please revert the current behavior.  And especially, please do
not include the current behavior in the 24.1 _release_.

Re: smtp crap

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Editing the From is indeed a bug that we have to fix before the
> release.

Perhaps the simplest way would be to add these checks to the `M-x
report-emacs-bugs' hooks.  That is, if we're going to use
`mailclient-send-it', we obviously don't care about the From header, and
shouldn't check it.

The problem is that we don't really know whether we're going to be using
`mailclient-send-it' or not when we hit `C-c C-c', because we might get
prompted first.  (Especially in the "emacs -Q" case.)

So this is my suggestion: Make `C-c C-c' in `M-x report-emacs-bugs'
call the sendmail.el code to determine what mail transport we will be
using.  (This may prompt the user.)  And then, if it turns out that the
transport is `mailclient-send-it', we disable the From checks.

If this sounds reasonable, I can take a whack at implementing this.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

RE: smtp crap

[Drew Adams]

> > Even if it works flawlessly, this "feature" should _not_ be 
> > the default.
> 
> As long as we don't have a better solution, yes it should be
> the default.

We had a better solution before.  Why should the default be changed to something
worse, just because you don't have something better?

What improvement is represented by this annoyance and error-prone user
interaction?  It's pretty clear what the loss is.  What's the gain?  I haven't
heard one argument (reason) in support of the changed behavior.

> And for Emacs-24 we won't have a better solution so it
> will be the default.

Poor Emacs.  Maybe Emacs 24 should wait until you can "configure" a sane UI for
bug reporting.

> mailclient-send-it is not a satisfactory solution, it's a workaround.

Seems satisfactory enough on Windows.  Did any Windows user complain about it
and ask that we move to the present situation?  Why not do what Eli suggested,
as a compromise (while waiting for your "better solution")?

Workaround?  Did you say "workaround"?  What do you call the present kludge?

> > In particular, it is ridiculous that a user trying to send 
> > a simple bug report with `emacs -Q' has to run through the
> > extra hurdle of this inane, possibly confusing, and error-prone
> > dialog ("yes"; edit the `From' line; "n").  I cannot
> > believe this silliness has gone on this long already.
> 
> Editing the From is indeed a bug that we have to fix before
> the release.  Maybe you could submit a patch for it?

Here's the patch: Revert to what we had before.

What we have now is no improvement.  Have we heard from anyone who has mentioned
how this change has improved their life?  Did any users even request this
change?

> > Nowadays especially, users already have email configured on 
> > whatever devices they use.
> 
> Yes, e.g. configured on Emacs.

What does that mean?

> > Why are we going backward, not forward?  Why is it suddenly 
> > important for every user to be interrogated (even once!)
> > about configuring email for Emacs?  (How
> > did we get by all these years without this annoyance?)
> 
> We got by all these years because both SMTP and /usr/sbin/sendmail
> actually used to work or fail reliably.  Nowadays byzantine errors are
> the rule for them so we need user input to figure out what to do.

OK, blame it on SMTP and sendmail.  Email worked or failed reliably ... back in
the 1980s (mostly worked, and well).  But nowadays, because things are so much
more advanced and complex, we need to alert Emacs users whenever they try to
submit a bug report, notifying them that we don't really know what mail
configuration they want, and asking them to tell us.  Sheesh.

"Workaround"?!?   Please, find a junior high-school kid to implement a sane
Emacs bug-reporting UI for next weekend's take-home project.  Sending a bug
report was NOT broken.  Now it is.

Re: smtp crap

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Popping up a different mailer is not a problem: it's what mailclient is
> supposed to do.  The problem is that it comes into play much too late:
> mailclient should not be an MTA function but a MUA function.

I sort of agree.  But then you're asking people to even edit their
emails outside of Emacs, and that's not very nice.  :-)

But if that's what somebody wants, then I think that's what we should
do, as you say.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

RE: smtp crap

[Drew Adams]

> But then you're asking people to even edit their
> emails outside of Emacs, and that's not very nice.  :-)
> 
> But if that's what somebody wants, then I think that's what we should
> do, as you say.

No one has requested that.  But if there is such a request then it wouldn't hurt
to make it an option, provided users can still choose to edit it inside Emacs
instead.

Re: smtp crap

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Even if it works flawlessly, this "feature" should _not_ be the default.
>
> As long as we don't have a better solution, yes it should be
> the default.  And for Emacs-24 we won't have a better solution so it
> will be the default.

So, this presumes that "smtp-using-user-prompted-info" is on average
more reliable than "use sendmail," even in the case where sendmail can
be invoked.

Is there data to back up this presumption?

If they're of roughly equal reliablity, of course, the least annoying
option should be chosen -- and that's "sendmail."

-Miles

-- 
Americans are broad-minded people.  They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if
a man doesn't drive, there is something wrong with him.  -- Art Buchwald

Re: smtp crap

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> So this is my suggestion: Make `C-c C-c' in `M-x report-emacs-bugs'
> call the sendmail.el code to determine what mail transport we will be
> using.  (This may prompt the user.)  And then, if it turns out that the
> transport is `mailclient-send-it', we disable the From checks.

That seems clearly correct to me. (Also the use of yes/no versus y/n in
all these prompts should be consistent.)

Re: smtp crap

[Stefan Monnier]

>>> Even if it works flawlessly, this "feature" should _not_ be the default.
>> As long as we don't have a better solution, yes it should be
>> the default.  And for Emacs-24 we won't have a better solution so it
>> will be the default.
> So, this presumes that "smtp-using-user-prompted-info" is on average
> more reliable than "use sendmail," even in the case where sendmail can
> be invoked.

I'd hope that any user who's not dead-set on using Emacs's smtpmail
support will simply say "use mailclient".  So the likelihood of wrong
smtp setup should be rather low.

> Is there data to back up this presumption?

No.  Especially given that the current prompt doesn't really offer
mailclient as an option, so that needs to be fixed first.


        Stefan

Re: smtp crap

[Stefan Monnier]

> So this is my suggestion: Make `C-c C-c' in `M-x report-emacs-bugs'
> call the sendmail.el code to determine what mail transport we will be
> using.  (This may prompt the user.)  And then, if it turns out that the
> transport is `mailclient-send-it', we disable the From checks.

It sounds a bit ugly, but I guess it's about as good a solution as we'll
get for now.  Please take a stab at it.


        Stefan

Re: smtp crap

[Stefan Monnier]

>> Popping up a different mailer is not a problem: it's what mailclient is
>> supposed to do.  The problem is that it comes into play much too late:
>> mailclient should not be an MTA function but a MUA function.
> I sort of agree.  But then you're asking people to even edit their
> emails outside of Emacs, and that's not very nice.  :-)

I assume that asking them to "first edit them in Emacs, then edit them
in their MUA" is worse than to just edit them in their MUA.


        Stefan

Re: smtp crap

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 10 Oct 2011 17:43:55 -0400
> Cc: cyd@stupidchicken.com, ding@gnus.org, emacs-devel@gnu.org,
> 	Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>,
> 	miles@gnu.org
> 
> > I don't think `mailclient-send-it' is a very satisfactory solution for
> > sending email.
> 
> Agreed.  We need something better.

So is this a NO to my question regarding making mailclient-send-it the
default for Windows?

Re: smtp crap

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> As long as we don't have a better solution, yes it should be
>>> the default.  And for Emacs-24 we won't have a better solution so it
>>> will be the default.
>>
>> So, this presumes that "smtp-using-user-prompted-info" is on average
>> more reliable than "use sendmail," even in the case where sendmail can
>> be invoked.
>
> I'd hope that any user who's not dead-set on using Emacs's smtpmail
> support will simply say "use mailclient".  So the likelihood of wrong
> smtp setup should be rather low.

Hmm, remember, this issue applies to more than windows...
(I'm using debian and I got the question [repeatedly, though
the repetition is obviously a bug]).

Anyway, part of the problem is that I'm not really sure how prepared
people will be to answer that prompt when it unexpectedly pops up,-
even the initial y-or-n "use smtp?" question.  Unexpected prompts
asking detailed technical questions without any explanation are not a
good recipe for success...

>> Is there data to back up this presumption?
>
> No.  Especially given that the current prompt doesn't really offer
> mailclient as an option, so that needs to be fixed first.

mailclient is a windows-only option right?

How about in the gnu/linux case?  Here the choice is (apparently)
between sendmail (or really "system MTA," often not really sendmail)
and the new smtp.

"sendmail" has been the default for ages, and even if it does the
wrong thing in some cases, has the advantage being the status quo:
people that use emacs either have either made sure that works, or have
learned to refrain from sending mail in emacs.  This new prompt runs a
real risk of making things _worse_: people who have been sending email
from emacs for a long time, but aren't really familiar with the
details stand a real chance of answering it wrong, and unintentionally
misconfiguring emacs in a way that will cause mail to stop working.

So absent any data showing the new method would (or at least _might_)
improve things, isn't this change in behavior kind of dubious...?

-Miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: smtp crap

[chad]

On Oct 10, 2011, at 9:20 PM, Miles Bader wrote:
> So absent any data showing the new method would (or at least _might_)
> improve things, isn't this change in behavior kind of dubious...?


In one or two of the previous conversations on this topic, we talked
about the cases where it does improve things: it is common for a
machine to have a local sendmail (-doppelgänger) that silently eats
mail.

I have personally seen (several years ago, at MIT) a large number of
report-emacs-bug messages that ended up stranded on such a machine,
and the user had no reasonable way of knowing that the message had not
been sent (as far as they could tell, it *had* been sent).  I have no
idea how common this sort of configuration is today, but when we
discussed it before, it seemed that at least 2 or 3 common, popular
GNU/Linux distributions were likely to fall into this or similar
problem configurations.

I hope that helps,
*Chad

Re: smtp crap

[Stefan Monnier]

>> I'd hope that any user who's not dead-set on using Emacs's smtpmail
>> support will simply say "use mailclient".  So the likelihood of wrong
>> smtp setup should be rather low.
> Hmm, remember, this issue applies to more than windows...
> (I'm using debian and I got the question [repeatedly, though
> the repetition is obviously a bug]).

I don't see why the issue should be different for Debian (but see below).

>> No.  Especially given that the current prompt doesn't really offer
>> mailclient as an option, so that needs to be fixed first.
> mailclient is a windows-only option right?

No.

> How about in the gnu/linux case?  Here the choice is (apparently)
> between sendmail (or really "system MTA," often not really sendmail)
> and the new smtp.

That's exactly what I'm referring to when I say "the current prompt
doesn't really offer mailclient".  It needs to be fixed to offer
mailclient on all platforms.


        Stefan

Re: smtp crap

[Stefan Monnier]

>> > I don't think `mailclient-send-it' is a very satisfactory solution for
>> > sending email.
>> Agreed.  We need something better.
> So is this a NO to my question regarding making mailclient-send-it the
> default for Windows?

Not sure what was the question, but I don't think this issue has much to
do with the underlying OS: the problem is pretty much the same
everywhere nowadays.


        Stefan

RE: smtp crap

[Drew Adams]

> the use of yes/no versus y/n in all these prompts should
> be consistent.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9074#41

And from the same bug thread, 3 months ago:

"Why would we even think about mixing `(yes or no)' and `(y or n)' in the
same dialog?  Downright diabolical."

Re: smtp crap

[Tim Cross]

On Tue, Oct 11, 2011 at 3:41 PM, chad <yandros@mit.edu> wrote:
>
> On Oct 10, 2011, at 9:20 PM, Miles Bader wrote:
>> So absent any data showing the new method would (or at least _might_)
>> improve things, isn't this change in behavior kind of dubious...?
>
>
> In one or two of the previous conversations on this topic, we talked
> about the cases where it does improve things: it is common for a
> machine to have a local sendmail (-doppelgänger) that silently eats
> mail.
>
> I have personally seen (several years ago, at MIT) a large number of
> report-emacs-bug messages that ended up stranded on such a machine,
> and the user had no reasonable way of knowing that the message had not
> been sent (as far as they could tell, it *had* been sent).  I have no
> idea how common this sort of configuration is today, but when we
> discussed it before, it seemed that at least 2 or 3 common, popular
> GNU/Linux distributions were likely to fall into this or similar
> problem configurations.
>

The main argument supporting the change in default behaviour for mail
was that the mail environment has evolved, particularly with the
introduction of 'mobile devices' and apparently increasing incidence
of local MTAs not being configured or being incorrectly configured
etc. This all seemed fair enough. However, the devil is always in the
details and soon we began to encounter complications, particularly
with respect to emacs' bug reporting facilities and being able to use
these facilities when running emacs with the -Q switch.

More and more complicated solutions appear to be pushed forward and it
would seem many are less than satisfied with the results so far. I
think we may be over complicating matters and need to re-focus on what
we really are trying to do.

Some time back, it was suggested that perhaps we really need to
reconsider how emacs bug reporting processes should work. If the email
environment has evolved as has been suggested, then perhaps what we
really need to do is re-think how emacs supports the submission of bug
reports. For example, if it did not rely solely on email, we could
remove the hacks which have been proposed to enable bug reports when
running -Q and we could eliminate the whole issue of emacs users being
forced to configure emacs for mail simply to send a bug report. Those
who want to use emacs for email can and they will have the motivation
to configure it. Those who don't will not have to and won't get
frustrated by emacs forcing them to. We can avoid the overly complex
configuration wizard,. which I suspect will be very difficult to get
right for all platforms and will be a source of bugs for a long time.
I would suggest that whatever changes are made to bug reporting that
email remain as an option which users can choose if they so desire.
Apart from that, I would suggest opening up the discussion to see what
ideas people may have.

Initial suggestions to re-examine how we do bug reporting were largely
rejected. However, perhaps after the issues raised relating to the use
of email, maybe there is increased willingness to re-consider this
issue.

Tim




-- 
Tim Cross
Phone: 0428 212 217

RE: smtp crap

[Drew Adams]

> I'd hope that any user who's not dead-set on using Emacs's smtpmail
> support will simply say "use mailclient".  So the likelihood of wrong
> smtp setup should be rather low.

It's not about customizing Emacs email preferences to suit the user, whether
s?he is dead-set for or against smtpmail.  If a user wants to
customize/configure email, then making her jump through hoops and even badly
designed question sequences is not a big deal (a bug, but not a big bug).

What is bad is forcing this questioning on a user, instead of simply taking her
down that garden path _only_ on her request.

But even that is not what is most important - don't focus on the customization
problem.  It's really not the main problem, even if pushed on users.

It's about Emacs _bug reporting_, and in particular reporting from `emacs -Q'.
We should not be submitting users who want to report bugs to a configuration
scenario that interrogates them about email methods.

Really, this should be a no-brainer.

RE: smtp crap

[Drew Adams]

> I assume that asking them to "first edit them in Emacs, then edit them
> in their MUA" is worse than to just edit them in their MUA.

No, that's a bad, unwarranted assumption.

Some users might choose that, but it's important that users still be able to
edit a bug report using Emacs, and then just paste it into their mail client.

My non-Emacs mail client has lots of features that I take advantage of, but for
plain-text editing Emacs is far better.  There is no reason to force users to
choose to either use Emacs for everything from editing to sending mail or use
their mail client for everything.

RE: smtp crap

[Drew Adams]

> I say "the current prompt doesn't really offer mailclient".
> It needs to be fixed to offer mailclient on all platforms.

No - the problem is not just needing better questions with more possible
responses.

There should be _no_ such unsolicited prompting.  Any dialog about email
configuration should be only upon user request.

And it certainly should not ensue automatically just because a user tries to
send a bug report.

RE: smtp crap

[Drew Adams]

> I'm not really sure how prepared people will be to answer that
> prompt when it unexpectedly pops up,- even the initial y-or-n
> "use smtp?" question.  Unexpected prompts asking detailed
> technical questions without any explanation are not a
> good recipe for success...

Yes, this should be obvious.  And it was pointed out months ago.

Re: smtp crap

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  cyd@stupidchicken.com,  ding@gnus.org,  emacs-devel@gnu.org,  drew.adams@oracle.com,  miles@gnu.org
> Date: Tue, 11 Oct 2011 01:05:57 -0400
> 
> >> > I don't think `mailclient-send-it' is a very satisfactory solution for
> >> > sending email.
> >> Agreed.  We need something better.
> > So is this a NO to my question regarding making mailclient-send-it the
> > default for Windows?
> 
> Not sure what was the question

The question was: would it be okay to change the default value of
send-mail-function to mailclient-send-it, for Windows only?

> I don't think this issue has much to do with the underlying OS: the
> problem is pretty much the same everywhere nowadays.

I'm okay with changing the default to mailclient-send-it on all
platforms ;-)

I cannot speak for Posix platforms nowadays, but I do know that almost
every Windows box out there has its mail client set up, so it is a
sure bet to rely on that for Windows.  By contrast, many (if not most)
Windows users would not know how to set up SMTP, even if they are
sophisticated enough to use Emacs.

So I think, for Emacs 24.1 at least, having mailclient-send-it as the
default on Windows would be a good solution, until we figure out how
to satisfy all the different needs in this matter.

Re: smtp crap

[Stefan Monnier]

> I'm okay with changing the default to mailclient-send-it on all
> platforms ;-)

(Assuming we can eliminate the flaw that started this thread causing
repeatedly asking the debated question), the current behavior is
basically "before falling back on the mailclient-default, please confirm
that you indeed want to use mailclient?", so I think it's a small price
to pay to avoid pissing off long-time Emacs MUA users.


        Stefan

Re: smtp crap

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  cyd@stupidchicken.com,  ding@gnus.org,  emacs-devel@gnu.org,  drew.adams@oracle.com,  miles@gnu.org
> Date: Tue, 11 Oct 2011 08:40:23 -0400
> 
> > I'm okay with changing the default to mailclient-send-it on all
> > platforms ;-)
> 
> (Assuming we can eliminate the flaw that started this thread causing
> repeatedly asking the debated question), the current behavior is
> basically "before falling back on the mailclient-default, please confirm
> that you indeed want to use mailclient?", so I think it's a small price
> to pay to avoid pissing off long-time Emacs MUA users.

What will be the UI after "we eliminate the flaw that started this
thread"?  Right now, Emacs asks the user whether she wants to
configure smtp:

   (insert "Emacs has not been set up for sending mail.\n
  Type `y' to configure and use Emacs as a mail client,
  or `n' to use your system's default mailer.\n
  To change your decision later, customize `send-mail-function'.\n")

This is a very confusing request, and the way it asks 2 or even 3
questions in 2 sentences cannot possibly be TRT.  What do you propose
as the alternative?

RE: smtp crap

[Drew Adams]

> > I'm okay with changing the default to mailclient-send-it on all
> > platforms ;-)
> 
> (Assuming we can eliminate the flaw that started this thread causing
> repeatedly asking the debated question), the current behavior is
> basically "before falling back on the mailclient-default, 
> please confirm that you indeed want to use mailclient?", so I
> think it's a small price to pay to avoid pissing off long-time
> Emacs MUA users.

Have any "long-time Emacs MUA users" actually _requested_ this "feature"?  I've
asked this question several times in different forms, but gotten no answer.  Is
this a user-requested feature or just something that some Emacs developers
dreamed up as a cool thing to do?  If it _was_ requested by a user, how about
polling the users in general, to find out what they think as a (sampled)
population?

And what about long-time NON-Emacs MUA users?  (Tim is right to ask about the
numbers/proportion of Emacs users who do NOT use Emacs for email.  You are wrong
to ignore them.)

More importantly, what about newbie Emacs users, regardless of their MUA?

But MOST importantly, what about reporting bugs with `emacs -Q'?

That is the real problem here, and the one that you keep ignoring.  Instead, you
keep focusing on the problem of customization, which is, relatively speaking, no
big deal (assuming you finish fixing the repeated-interrogation bugs).

The problem of annoying, confusing, and slowing down users (not to mention
provoking errors) who are only trying to _help_ us by reporting a bug is, yes, a
BIG problem.  I'm sorry you don't see it as such.

Re: smtp crap

[Stefan Monnier]

> Right now, Emacs asks the user whether she wants to configure smtp:

>    (insert "Emacs has not been set up for sending mail.\n
>   Type `y' to configure and use Emacs as a mail client,
>   or `n' to use your system's default mailer.\n
>   To change your decision later, customize `send-mail-function'.\n")

There's fundamentally one question with 3 possible answers:

   How do you want to send email?
   1- Use the system mailer (old default).
   2- Use your favorite non-Emacs MUA.
   3- Configure Emacs so it can send email on its own.

If there's no /usr/sbin/sendmail, answer 1 is not available.


        Stefan

Re: smtp crap

[PJ Weisberg]

On Tue, Oct 11, 2011 at 7:53 AM, Drew Adams <drew.adams@oracle.com> wrote:

> But MOST importantly, what about reporting bugs with `emacs -Q'?
>
> That is the real problem here, and the one that you keep ignoring.  Instead, you
> keep focusing on the problem of customization, which is, relatively speaking, no
> big deal (assuming you finish fixing the repeated-interrogation bugs).

No, that's not the real problem.  There are two problems:
(1) What should Emacs do when the user asks it to send an email?
(2) What should Emacs do when the user asks it to report a bug?

This series of questions is appropriate in scenario 1, but not in
scenario 2.  (Especially with `emacs -Q', which causes an
already-configured Emacs to explicitly ignore its configuration.) The
fact that the two scenarios are related is an implementation detail of
report-emacs-bug.  The argument Drew is making would disappear
instantly if report-emacs-bug sent an HTTP POST request, for instance.

-PJ

RE: smtp crap

[Drew Adams]

> > But MOST importantly, what about reporting bugs with `emacs -Q'?
> >
> > That is the real problem here, and the one that you keep 
> > ignoring.  Instead, you keep focusing on the problem of
> > customization, which is, relatively speaking, no big deal
> > (assuming you finish fixing the repeated-interrogation bugs).
> 
> No, that's not the real problem.

To me it is.  It is a more important problem than how to help users configure
Emacs to use email.

> There are two problems:
> (1) What should Emacs do when the user asks it to send an email?
> (2) What should Emacs do when the user asks it to report a bug?

Agreed.

> This series of questions is appropriate in scenario 1, but not in
> scenario 2.

I would say that _some email configuration UI_ is appropriate for #1, but not
for #2.

But "some config UI" does not imply "this series of questions".

I don't really care too much (personally) about what UI is used for #1.  But
(FWIW) my advice would be for Emacs to (a) not _initiate_ that UI but only
provide it upon _user request_ and (b) probably not offer it as a sequence of
questions (e.g. wizard) at all, but rather as a form (e.g. checkboxes) to fill
in.  Look at how other apps help users configure email, for some inspiration...

> (Especially with `emacs -Q', which causes an already-configured
> Emacs to explicitly ignore its configuration.)

Exactly.  This is important.  It should be the starting point.

The fact that the UI interrogation-sequence-from-hell was (initially) completely
backward (see the bugs, some of which have been fixed), and that it is still,
well, weird, reflects the fact that this was NOT the starting point, even though
the configuration dialog is initiated by the `report-emacs-bug' code.

> The fact that the two scenarios are related is an implementation
> detail of report-emacs-bug.

It might be currently, but it should not be.

> The argument Drew is making would disappear instantly if
> report-emacs-bug sent an HTTP POST request, for instance.

Yes.  But in that case Drew would argue that we should still also let users
report bugs using email.  On this I support Richard's stance: users should be
able to report bugs using email.  AND they should be able to do so using HTTP.

We should make it as easy as possible for a user to report an Emacs bug,
especially using `emacs -Q'.  That should be the priority - the rest is
secondary, IMHO.  And yes, this _should_ be a no-brainer.

Re: smtp crap

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: larsi@gnus.org, cyd@stupidchicken.com, ding@gnus.org, emacs-devel@gnu.org,
>         drew.adams@oracle.com, miles@gnu.org
> Date: Tue, 11 Oct 2011 11:42:05 -0400
> 
> There's fundamentally one question with 3 possible answers:
> 
>    How do you want to send email?
>    1- Use the system mailer (old default).
>    2- Use your favorite non-Emacs MUA.
>    3- Configure Emacs so it can send email on its own.
> 
> If there's no /usr/sbin/sendmail, answer 1 is not available.

If (1) is sendmail, then its wording should be modified, because
Windows users will think it refers to their MUA.

Anyway, the question was not about the choices, which are quite clear.
The question was about the UI: how will we ask these questions, in
which sequence, and what wording?  I think getting this right is
crucial for avoiding the n+1st round of arguing about this issue.
Were these aspect finalized yet (I didn't track this thread closely)?

Re: smtp crap

[Stefan Monnier]

>> There's fundamentally one question with 3 possible answers:
>> 
>> How do you want to send email?
>> 1- Use the system mailer (old default).
>> 2- Use your favorite non-Emacs MUA.
>> 3- Configure Emacs so it can send email on its own.
>> 
>> If there's no /usr/sbin/sendmail, answer 1 is not available.

> If (1) is sendmail, then its wording should be modified, because
> Windows users will think it refers to their MUA.

I'd expect those Windows users won't have /usr/sbin/sendmail so the
option shouldn't be presented to them.

> Anyway, the question was not about the choices, which are quite clear.
> The question was about the UI: how will we ask these questions, in
> which sequence, and what wording?

I don't expect any sequence: it's just one question.
The wording above is a starting point.  It could be a x-popup-dialog, or
a completing-read, or read-char-choice.

> I think getting this right is crucial for avoiding the n+1st round of
> arguing about this issue.

Agreed.

> Were these aspect finalized yet (I didn't track this thread closely)?

I find the above so obvious that it didn't occur to me to put it
in writing.  Is there some other way to do it?


        Stefan

Re: smtp crap

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: cyd@stupidchicken.com, ding@gnus.org, emacs-devel@gnu.org, larsi@gnus.org,
>         drew.adams@oracle.com, miles@gnu.org
> Date: Tue, 11 Oct 2011 14:51:02 -0400
> 
> >> There's fundamentally one question with 3 possible answers:
> >> 
> >> How do you want to send email?
> >> 1- Use the system mailer (old default).
> >> 2- Use your favorite non-Emacs MUA.
> >> 3- Configure Emacs so it can send email on its own.
> >> 
> >> If there's no /usr/sbin/sendmail, answer 1 is not available.
> 
> > If (1) is sendmail, then its wording should be modified, because
> > Windows users will think it refers to their MUA.
> 
> I'd expect those Windows users won't have /usr/sbin/sendmail so the
> option shouldn't be presented to them.

Then (2) should be reworded to say something like

  Use the system's default email program

("non-Emacs" is too negative, and "MUA" is not necessarily a known
acronym).


> I don't expect any sequence: it's just one question.
> The wording above is a starting point.  It could be a x-popup-dialog, or
> a completing-read, or read-char-choice.

I'm  not sure each of these can present the 2 or 3 choices and allow
to select one of them.  Maybe I'm missing something.

Also, the choice shouldn't be a single character, but rather several
ones and a RET -- to avoid inadvertently hitting the wrong key.

> Is there some other way to do it?

One of the above is okay IMO, as long as the text of each choice is
clear.

Re: smtp crap

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Then (2) should be reworded to say something like
>
>   Use the system's default email program
>
> ("non-Emacs" is too negative, and "MUA" is not necessarily a known
> acronym).

It might be helpful if you're aware of what the current query is.  It's
this:

---
Emacs has not been set up for sending mail.
Type `y' to configure and use Emacs as a mail client,
or `n' to use your system's default mailer.
To change your decision later, customize `send-mail-function'.
---

If you have a better help text to propose, this text is in the function
`sendmail-query-once' in the file sendmail.el.  Edit accordingly.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: smtp crap

[Stefan Monnier]

>> I'd expect those Windows users won't have /usr/sbin/sendmail so the
>> option shouldn't be presented to them.
> Then (2) should be reworded to say something like
>   Use the system's default email program
> ("non-Emacs" is too negative, and "MUA" is not necessarily a known
> acronym).

It's clearly not choosing the system's default email program, but the
user's default email program (I know many people don't know the
difference, but we do).

>> I don't expect any sequence: it's just one question.
>> The wording above is a starting point.  It could be a x-popup-dialog, or
>> a completing-read, or read-char-choice.
> I'm not sure each of these can present the 2 or 3 choices and allow
> to select one of them.  Maybe I'm missing something.

Yes, they all do.

> Also, the choice shouldn't be a single character, but rather several
> ones and a RET -- to avoid inadvertently hitting the wrong key.

If you don't like the single-char choice, then read-char-choice is out.
So we're left with completing-read and x-popup-dialog.
What you describe corresponds to completing-read.


        Stefan

Re: smtp crap

[Tim Cross]

On Wed, Oct 12, 2011 at 3:24 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> > But MOST importantly, what about reporting bugs with `emacs -Q'?
>> >
>> > That is the real problem here, and the one that you keep
>> > ignoring.  Instead, you keep focusing on the problem of
>> > customization, which is, relatively speaking, no big deal
>> > (assuming you finish fixing the repeated-interrogation bugs).
>>
>> No, that's not the real problem.
>
> To me it is.  It is a more important problem than how to help users configure
> Emacs to use email.
>
>> There are two problems:
>> (1) What should Emacs do when the user asks it to send an email?
>> (2) What should Emacs do when the user asks it to report a bug?
>
> Agreed.
>
>> This series of questions is appropriate in scenario 1, but not in
>> scenario 2.
>
> I would say that _some email configuration UI_ is appropriate for #1, but not
> for #2.
>
> But "some config UI" does not imply "this series of questions".
>
> I don't really care too much (personally) about what UI is used for #1.  But
> (FWIW) my advice would be for Emacs to (a) not _initiate_ that UI but only
> provide it upon _user request_ and (b) probably not offer it as a sequence of
> questions (e.g. wizard) at all, but rather as a form (e.g. checkboxes) to fill
> in.  Look at how other apps help users configure email, for some inspiration...
>
>> (Especially with `emacs -Q', which causes an already-configured
>> Emacs to explicitly ignore its configuration.)
>
> Exactly.  This is important.  It should be the starting point.
>
> The fact that the UI interrogation-sequence-from-hell was (initially) completely
> backward (see the bugs, some of which have been fixed), and that it is still,
> well, weird, reflects the fact that this was NOT the starting point, even though
> the configuration dialog is initiated by the `report-emacs-bug' code.
>
>> The fact that the two scenarios are related is an implementation
>> detail of report-emacs-bug.
>
> It might be currently, but it should not be.
>
>> The argument Drew is making would disappear instantly if
>> report-emacs-bug sent an HTTP POST request, for instance.
>
> Yes.  But in that case Drew would argue that we should still also let users
> report bugs using email.  On this I support Richard's stance: users should be
> able to report bugs using email.  AND they should be able to do so using HTTP.
>
> We should make it as easy as possible for a user to report an Emacs bug,
> especially using `emacs -Q'.  That should be the priority - the rest is
> secondary, IMHO.  And yes, this _should_ be a no-brainer.
>
>
>
>

Totally agree - address the issue of bug reporting and most of this
kludgy mess goes away.

and please, DO NOT jump through all sorts of hoops with -Q to enable
'special' configuration settings to exist - the whole idea of -Q is
that it is a base, well known and repeatable configuration. Once you
start making exceptions that whole premise is lost. Using -Q should
allow me to have exactly the same configuration as someone else who
also runs -Q - it should not be 'the same configuration except for
....' If this means that users cannot submit bugs using emacs as their
MUA when running -Q it does not mean we need to hack at custom or make
exceptions - it means that email is not the right solution for
submitting bug messages when running under -Q. By all means, allow it
for other contexts, even make it the default for people who do
configure emacs as their MUA, but not when running under -Q and not
for those who do not configure emacs as a their MUA.


Tim
-- 

Tim Cross

Re: smtp crap

[Stefan Monnier]

> If you have a better help text to propose, this text is in the function
> `sendmail-query-once' in the file sendmail.el.  Edit accordingly.

I've just changed it so it doesn't mess with message any more
(especially since it wasn't done right) and it offers an OS-oblivious
3-way choice (using completing-read).


        Stefan

RE: smtp crap

[Drew Adams]

> and please, DO NOT jump through all sorts of hoops with -Q to enable
> 'special' configuration settings to exist - the whole idea of -Q is
> that it is a base, well known and repeatable configuration. Once you
> start making exceptions that whole premise is lost.
>
> Using -Q should allow me to have exactly the same configuration as
> someone else who also runs -Q - it should not be 'the same
> configuration except for ....'

1+

> If this means that users cannot submit bugs using emacs as their
> MUA when running -Q it does not mean we need to hack at custom or make
> exceptions - it means that email is not the right solution for
> submitting bug messages when running under -Q.

I acknowledge your "IF", Tim, but I disagree that we should accept a situation
where users cannot send bug reports using email.  Of course, to do so they need
_some_ way of sending email, but it does not follow that they need to use Emacs
as that way.  They should be able to compose the bug report in Emacs and send it
any way they want and can.

> By all means, allow it for other contexts, even make it the
> default for people who do configure emacs as their MUA, but not
> when running under -Q and not for those who do not configure emacs
> as a their MUA.

1+

Re: smtp crap

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 08:21:41 +1100
> From: Tim Cross <theophilusx@gmail.com>
> Cc: cyd@stupidchicken.com, ding@gnus.org, emacs-devel@gnu.org,
> 	Stefan Monnier <monnier@iro.umontreal.ca>,
> 	PJ Weisberg <pj@irregularexpressions.net>, larsi@gnus.org,
> 	Eli Zaretskii <eliz@gnu.org>, miles@gnu.org
> 
> and please, DO NOT jump through all sorts of hoops with -Q to enable
> 'special' configuration settings to exist - the whole idea of -Q is
> that it is a base, well known and repeatable configuration. Once you
> start making exceptions that whole premise is lost. Using -Q should
> allow me to have exactly the same configuration as someone else who
> also runs -Q - it should not be 'the same configuration except for
> ....' If this means that users cannot submit bugs using emacs as their
> MUA when running -Q it does not mean we need to hack at custom or make
> exceptions - it means that email is not the right solution for
> submitting bug messages when running under -Q.

Sorry, no.  That's unacceptable.  It was discussed long ago and
decided that the bug tracker will accept bug reports through email.
Trying to revert that, and during pretest at that, is a no-starter.

Re: smtp crap

[Lars Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> I've just changed it so it doesn't mess with message any more
> (especially since it wasn't done right) and it offers an OS-oblivious
> 3-way choice (using completing-read).

Reading the patch, it looks good except for the apparently oblivious
3-way choice:

+              (insert "Emacs has not been set up for sending mail.\n
+It can be told to send mail either via your favorite mail client,
+or via the system's mail transport agent (\"sendmail\"), if any,
+or it can send email on its own by configuring the SMTP parameters.\n

Should the "sendmail" option be off the table if the system doesn't have
a sendmail executable?  (I.e., Windows and OS X.)

I haven't actually tried the code, so I may be misreading the patch...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: smtp crap

[Tim Cross]

On Wed, Oct 12, 2011 at 9:00 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> and please, DO NOT jump through all sorts of hoops with -Q to enable
>> 'special' configuration settings to exist - the whole idea of -Q is
>> that it is a base, well known and repeatable configuration. Once you
>> start making exceptions that whole premise is lost.
>>
>> Using -Q should allow me to have exactly the same configuration as
>> someone else who also runs -Q - it should not be 'the same
>> configuration except for ....'
>
> 1+
>
>> If this means that users cannot submit bugs using emacs as their
>> MUA when running -Q it does not mean we need to hack at custom or make
>> exceptions - it means that email is not the right solution for
>> submitting bug messages when running under -Q.
>
> I acknowledge your "IF", Tim, but I disagree that we should accept a situation
> where users cannot send bug reports using email.  Of course, to do so they need
> _some_ way of sending email, but it does not follow that they need to use Emacs
> as that way.  They should be able to compose the bug report in Emacs and send it
> any way they want and can.
>

OK, I'll try to clarify. Emacs bug reporting should not prevent people
from using another MUA to submit a bug report and it may even
facilitate doing so if someone wants to implement such support.
However, I think it is quite reasonable if, while running under -Q,
you cannot use emacs as the MUA to submit the bug report. This has
been the situation when running under -Q for anyone who does not use a
local MTA for as long as I can remember. If the arguments that local
MTAs are seldom configured and most people now require smtpmail etc,
are correct, then it is reasonable to assume this has been the case
for a majority of users for some time and not something new.

Keep things simple and don't try to be too clever. All that is really
needed is for emacs to dump the relevant bug report data into a text
file and inform the user where tthis text file is and where it should
be sent to report a bug. This reflects a process which many of us who
do not use a local MTA or do not use emacs as our MUA have used for
years.

One point I totally agree with is the one you have been making about
not forcing people down the mail configuration path. By  all means,
assist people as much as possible once they choose that path, but
don't hurd them down it. This is why I raise the question concerning
numbers of people who actually use emacs as their MUA. It feels very
much like decisions being made based on personal experience and an
implicit assumption that an individuals personal experience is
representative of the majority of users - a common error we really
should be more aware of by now IMO.

If I find time, just for interest, I'm, going to try and do some
analysis of emacs-devel mail headers and see if I can get some stats
concerning MUAs being used. My ad hoc random non-scientific sampling
tends to indicate a lower number than perhaps many expect/assume.

Tim



-- 
Tim Cross

RE: smtp crap

[Drew Adams]

> >> If this means that users cannot submit bugs using emacs as their
> >> MUA when running -Q it does not mean we need to hack at 
> >> custom or make exceptions - it means that email is not the right
                                    ^^^^^^^^^^^^^^^^        
> >> solution for submitting bug messages when running under -Q.
> >
> > I acknowledge your "IF", Tim, but I disagree that we should 
> > accept a situation where users cannot send bug reports using
> > email.  Of course, to do so they need _some_ way of sending
> > email, but it does not follow that they need to use Emacs
> > as that way.  They should be able to compose the bug report 
> > in Emacs and send it any way they want and can.
>
> OK, I'll try to clarify. Emacs bug reporting should not prevent people
> from using another MUA to submit a bug report and it may even
> facilitate doing so if someone wants to implement such support.
> However, I think it is quite reasonable if, while running under -Q,
> you cannot use emacs as the MUA to submit the bug report.
                 ^^^^^

We are in agreement, I think.  I was reacting to your going beyond not using
Emacs as the MUA to not using email at all (for emacs -Q.  My guess is that you
misspoke and that we agree.

If we don't agree about that, at least we seem to agree about the rest (no
config to report a bug using emacs -Q, etc.).

Re: smtp crap

[Tim Cross]

On Wed, Oct 12, 2011 at 9:12 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 12 Oct 2011 08:21:41 +1100
>> From: Tim Cross <theophilusx@gmail.com>
>> Cc: cyd@stupidchicken.com, ding@gnus.org, emacs-devel@gnu.org,
>>       Stefan Monnier <monnier@iro.umontreal.ca>,
>>       PJ Weisberg <pj@irregularexpressions.net>, larsi@gnus.org,
>>       Eli Zaretskii <eliz@gnu.org>, miles@gnu.org
>>
>> and please, DO NOT jump through all sorts of hoops with -Q to enable
>> 'special' configuration settings to exist - the whole idea of -Q is
>> that it is a base, well known and repeatable configuration. Once you
>> start making exceptions that whole premise is lost. Using -Q should
>> allow me to have exactly the same configuration as someone else who
>> also runs -Q - it should not be 'the same configuration except for
>> ....' If this means that users cannot submit bugs using emacs as their
>> MUA when running -Q it does not mean we need to hack at custom or make
>> exceptions - it means that email is not the right solution for
>> submitting bug messages when running under -Q.
>
> Sorry, no.  That's unacceptable.  It was discussed long ago and
> decided that the bug tracker will accept bug reports through email.
> Trying to revert that, and during pretest at that, is a no-starter.
>
>

There is a BIG difference between what the bug tracker accepts/does
and how reports are entered into the system. There is also much that
is inconsistent in these arguments.

Preventing emacs from submitting bugs via email when running under -Q
does not prevent the user form submitting the bug report using another
email client.

There should be NO exceptions to -Q - it should represent an emacs
environment where ALL user configuration values are at their default
settings. Making special exceptions just to allow the submission of
bug reports via email is misguided and the thin edge of the wedge.
Keep it clean and keep it simple. The -Q switch should be consistent
and with no exceptions.

There is no technical reason we could not have an http (or whatever
protocol you prefer) to mail gateway that would allow the bugs to
still be submitted to the bug tracker via email.

If the big blocker to getting this right is that we are in pretest and
therefore cannot make significant change, then surely, given that the
current proposed solutions are less than adequate, the sensible
solution is to delay making ANY change to default behaviour until we
have a good solution. It makes no sense to push forward with something
that obviously has significant usability issues because of some
arbitrary pretest condition. If the arguments for changing the default
are valid and the majority of emacs users have to use smtpmail rather
than local MTAs or don't configure emacs as a MUA and the default MUA
settings are most often broken due to misconfigured local MTAs, then
email submission under -Q is already broken for a majority of users
and has been for some time. Therefore, leaving things as they are
until the post-24 release is not going to make matters worse.

Tim




-- 
Tim Cross

RE: smtp crap

[Drew Adams]

> If the big blocker to getting this right is that we are in pretest and
> therefore cannot make significant change, then surely, given that the
> current proposed solutions are less than adequate, the sensible
> solution is to delay making ANY change to default behaviour until we
> have a good solution. It makes no sense to push forward with something
> that obviously has significant usability issues because of some
> arbitrary pretest condition.

Hear, hear!  Get it right!  Precisely.
Stop worrying about hurrying up the pretest.
Make the release fully baked, something to be proud of.

Take the time to fix bugs that we already know about (e.g. `display-buffer'
fallout).

Some people (you know who you are) used to scream, groan, and holler when
Richard used to take pains to fix bugs and get the doc right before publishing a
release.  The release cycle was too long, was the complaint.

I did not complain about that, and I wish we still had the same careful policy.
It was a breath of fresh air compared to the usual
throw-some-software-over-the-wall hustle.  There should be no rush to add a 24th
notch to anyone's belt.

This bug-reporting-by-email mess-up was signaled as far back as January 2010
(almost 2 years ago) - see bugs #5299, #7469, and #8595.  Sometimes there was a
bit of a response in terms of trying to fix things.

But to the last go-round, which implemented the config-dialog-from-hell
(reported as far back as Nov 2010 - a year ago), complaints essentially got no
attention.  The problem wrt reporting bugs using `emacs -Q' was passed over in
silence by the maintainers, except for being dismissed by Stefan with "If it
hurts don't do it".

If it weren't for Miles adding his voice recently I'm sure there would not be
this discussion now.  Hard to tell whether the discussion will have any effect,
but at least it seems that people are starting to think about the problem and
possible solutions.

> If the arguments for changing the default
> are valid and the majority of emacs users have to use smtpmail rather
> than local MTAs or don't configure emacs as a MUA and the default MUA
> settings are most often broken due to misconfigured local MTAs, then
> email submission under -Q is already broken for a majority of users
> and has been for some time. Therefore, leaving things as they are
> until the post-24 release is not going to make matters worse.

Yup.

Re: smtp crap

[Stefan Monnier]

> +              (insert "Emacs has not been set up for sending mail.\n
> +It can be told to send mail either via your favorite mail client,
> +or via the system's mail transport agent (\"sendmail\"), if any,
> +or it can send email on its own by configuring the SMTP parameters.\n

> Should the "sendmail" option be off the table if the system doesn't have
> a sendmail executable?  (I.e., Windows and OS X.)

I kept it in the text (qualified with "if any"), although it is removed
from the possible completions.  I felt it is worthwhile to mention that
such an option exists, even if it's not currently available.


        Stefan

Re: smtp crap

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> I cannot speak for Posix platforms nowadays, but I do know that almost
> every Windows box out there has its mail client set up

Considering the increasing popularity of webmail, this may not be true
anymore.

Also, I don't like the argument that we should treat Windows users
differently from users on other platforms, just because they are likely
to use some proprietary mail client.  In that context, offering to set
up Emacs for sending email is actually good, if it encourages less
dependence on such mail clients.

RE: smtp crap

[Drew Adams]

> > I cannot speak for Posix platforms nowadays, but I do know 
> > that almost every Windows box out there has its mail client set up
> 
> Considering the increasing popularity of webmail, this may not be true
> anymore.

Really?  Is that in relative terms?  Numbers of emails sent per...?

> Also, I don't like the argument that we should treat Windows users
> differently from users on other platforms, just because they 
> are likely to use some proprietary mail client.

So now non-GNU-Emacs means "proprietary"?  Gonflés, we are.

Here is Wikipedia's list of email clients:
http://en.wikipedia.org/wiki/Comparison_of_e-mail_clients

Is Gnus the only one of them that you bless with the holy baptismal water of
"freeness"?  Shall we load the cannons and blast the bejesus out of Thunderbird,
Mutt, and Seamonkey?

> In that context, offering to set up Emacs for sending email
> is actually good, if it encourages less dependence on such
> mail clients.

So this _is_ about pushing people to use Emacs/Gnus for email.  The word
"misguided" comes to mind...  I guess this is what a little Gnus can do to you.
("This is your Emacs.  And this is your Emacs on Gnus...")

"Offer" to set up Emacs for sending mail all you want, but please keep the
SPECIAL OFFER!!! stuff under wraps.  Let users actually come looking for it
before you "offer" it to them, please.  (What exciting popups are in store for
us in Emacs 24.2?)

Re: smtp crap

[Tim Cross]

On Wed, Oct 12, 2011 at 12:30 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I cannot speak for Posix platforms nowadays, but I do know that almost
>> every Windows box out there has its mail client set up
>
> Considering the increasing popularity of webmail, this may not be true
> anymore.
>

This may be a very valid pint. I've noticed that a LOT of people are
now using web based mail clients and web based mail services. This
appears to be particularly common amongst less technical and younger
users. I suspect it is partially because of increased mobility and the
desire to have access to mail from multiple devices with minimal need
for configuration etc.

> Also, I don't like the argument that we should treat Windows users
> differently from users on other platforms, just because they are likely
> to use some proprietary mail client.  In that context, offering to set
> up Emacs for sending email is actually good, if it encourages less
> dependence on such mail clients.
>
>

I'd prefer it if we 'converted' people based on a superior solution
rather than what feels a bit too Machiavellian for my tastes :)

-- 
Tim Cross
Phone: 0428 212 217

Re: smtp crap

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I cannot speak for Posix platforms nowadays, but I do know that almost
>> every Windows box out there has its mail client set up
>
> Considering the increasing popularity of webmail, this may not be true
> anymore.

My unscientific analysis is that of all windows boxen I see during work
hours exactly everyone uses webmail in some form, and also some form of
Outlook mail client. People mostly use it to book meetings though.

Of all the much fewer private windows boxen I see exactly everyone uses webmail.

Precisely zero users have had only a Outlook client install do all their
mail.

Again, this is just my personal observation working with, say, a hundred
developers or so recently.

Of all these people two people used Emacs. Me and another guy. We both
use GNU/Linux and have mail setup already.

Anyway, IMHO an http->bugtracker additional interface should be set
up. I fail to see why this would be controversial apart from the added
problem of preventing spam on that additional interface.

> Also, I don't like the argument that we should treat Windows users
> differently from users on other platforms, just because they are likely
> to use some proprietary mail client.  In that context, offering to set
> up Emacs for sending email is actually good, if it encourages less
> dependence on such mail clients.

-- 
Joakim Verona

Re: smtp crap

[Eli Zaretskii]

> Date: Wed, 12 Oct 2011 10:11:45 +1100
> From: Tim Cross <theophilusx@gmail.com>
> Cc: cyd@stupidchicken.com, ding@gnus.org, emacs-devel@gnu.org, 
> 	monnier@iro.umontreal.ca, pj@irregularexpressions.net, larsi@gnus.org, 
> 	drew.adams@oracle.com, miles@gnu.org
> 
> Preventing emacs from submitting bugs via email when running under -Q
> does not prevent the user form submitting the bug report using another
> email client.

But it makes that harder, which is IMO unnecessary.

> There should be NO exceptions to -Q - it should represent an emacs
> environment where ALL user configuration values are at their default
> settings.

I agree, but this is correct only up to the point where Emacs
completed collecting the relevant data for the bug report.  After that
point, there's no problem in modifying the defaults, because they no
longer affect the bug report and the behavior reported therein.

> If the big blocker to getting this right is that we are in pretest and
> therefore cannot make significant change, then surely, given that the
> current proposed solutions are less than adequate, the sensible
> solution is to delay making ANY change to default behaviour until we
> have a good solution.

The default behavior until now WAS to send email from Emacs, using one
of the methods it supports.  So we are in agreement for this part.

Re: smtp crap

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, larsi@gnus.org, ding@gnus.org,
>         emacs-devel@gnu.org, drew.adams@oracle.com, miles@gnu.org
> Date: Tue, 11 Oct 2011 21:30:56 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I cannot speak for Posix platforms nowadays, but I do know that almost
> > every Windows box out there has its mail client set up
> 
> Considering the increasing popularity of webmail, this may not be true
> anymore.

It is still true.  Even if the local MUA is used less than it was
before, it is still set up.

> Also, I don't like the argument that we should treat Windows users
> differently from users on other platforms, just because they are likely
> to use some proprietary mail client.  In that context, offering to set
> up Emacs for sending email is actually good, if it encourages less
> dependence on such mail clients.

Sorry, I see no sense in this reasoning.  This discussion is about
letting "emacs -Q" be able to send mail with a high probability of
success and with the minimum fuss for the user.  This situation is
especially important when reporting bugs, because we actually request
users to use "emacs -Q" for that.  Why would we want to hurt this
goal, for the sake of some illusory "equality" between platforms?

Re: smtp crap

[Eli Zaretskii]

> From: joakim@verona.se
> Cc: Eli Zaretskii <eliz@gnu.org>, ding@gnus.org, emacs-devel@gnu.org,
>         Stefan Monnier <monnier@iro.umontreal.ca>, larsi@gnus.org,
>         drew.adams@oracle.com, miles@gnu.org
> Date: Wed, 12 Oct 2011 08:33:33 +0200
> 
> My unscientific analysis is that of all windows boxen I see during work
> hours exactly everyone uses webmail in some form, and also some form of
> Outlook mail client. People mostly use it to book meetings though.

If Outlook can be used for meetings, it is configured to send mail.
And that is all that matters in the context of this discussion.

Re: smtp crap

[Lennart Borgman]

On Wed, Oct 12, 2011 at 08:33,  <joakim@verona.se> wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
>
> Of all the much fewer private windows boxen I see exactly everyone uses webmail.

If you are using for example Gmail as a webmail there is a utility you
can install to make it the default MUA on your pc.

And there are also add-ons for different browsers to make
mailto:-links work with different webmails. (I think I suggested long
ago to make Emacs bug reporter write a html page to take advantage of
this.)

Re: smtp crap

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: joakim@verona.se
>> Cc: Eli Zaretskii <eliz@gnu.org>, ding@gnus.org, emacs-devel@gnu.org,
>>         Stefan Monnier <monnier@iro.umontreal.ca>, larsi@gnus.org,
>>         drew.adams@oracle.com, miles@gnu.org
>> Date: Wed, 12 Oct 2011 08:33:33 +0200
>> 
>> My unscientific analysis is that of all windows boxen I see during work
>> hours exactly everyone uses webmail in some form, and also some form of
>> Outlook mail client. People mostly use it to book meetings though.
>
> If Outlook can be used for meetings, it is configured to send mail.
> And that is all that matters in the context of this discussion.

Well I'm only relating my personal experience. Most developers I
described rather chew of their own arm than use the corporately provided
Outlook instance. Therefore they do not book meetings, they reply to
meeting bookings in a webmail client. Should they absolutely need to
book a meeting they first chew off their arm then book the meeting.

Anyway, I still can't understand why its absolutely necessary for Emacs
to use a traditional Mail agent to send a bugreport. To allow for that
feature, yes, that I do understand.

Anyway, I'll shut up now and come back only when I can provide a working
implementation.

-- 
Joakim Verona

Re: smtp crap

[Juanma Barranquero]

On Wed, Oct 12, 2011 at 08:33,  <joakim@verona.se> wrote:

> My unscientific analysis is that of all windows boxen I see during work
> hours exactly everyone uses webmail in some form, and also some form of
> Outlook mail client. People mostly use it to book meetings though.
>
> Of all the much fewer private windows boxen I see exactly everyone uses webmail.
>
> Precisely zero users have had only a Outlook client install do all their
> mail.

That's my experience too.

    Juanma

Re: smtp crap

[Juanma Barranquero]

On Wed, Oct 12, 2011 at 10:59, Eli Zaretskii <eliz@gnu.org> wrote:

> If Outlook can be used for meetings, it is configured to send mail.
> And that is all that matters in the context of this discussion.

In many private setups webmail is all that is used. I use Gmail and I
have not configured Outlook or any other MUA in my current computer.

    Juanma

Re: smtp crap

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 12 Oct 2011 00:24:32 +0200
> Cc: ding@gnus.org
> 
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> 
> > I've just changed it so it doesn't mess with message any more
> > (especially since it wasn't done right) and it offers an OS-oblivious
> > 3-way choice (using completing-read).
> 
> Reading the patch, it looks good except for the apparently oblivious
> 3-way choice:
> 
> +              (insert "Emacs has not been set up for sending mail.\n
> +It can be told to send mail either via your favorite mail client,
> +or via the system's mail transport agent (\"sendmail\"), if any,
> +or it can send email on its own by configuring the SMTP parameters.\n

This text should be improved, IMO.  See below for my suggestion.

> Should the "sendmail" option be off the table if the system doesn't have
> a sendmail executable?  (I.e., Windows and OS X.)

Yes, I think so.  Having options that aren't applicable is confusing.

Here's my suggestion for the text of this prompt:

   Emacs is about to send an email message.  However,
   it was not configured for sending email.

   You can instruct Emacs to send mail in one of the
   following ways:

   - Start your default mail client and pass it the message text

   - Invoke the system's mail transport agent ("sendmail")

   - Send mail directly by communicating with your mail server
     (requires setting up SMTP parameters)

   Please select one of these.  Emacs will record your selection
   and will use it thereafter.  To change the selection later,
   customize the option `send-mail-function'.

Re: smtp crap

[Jason Rumney]

PJ Weisberg <pj@irregularexpressions.net> writes:

> On Tue, Oct 11, 2011 at 7:53 AM, Drew Adams <drew.adams@oracle.com> wrote:
>
>> But MOST importantly, what about reporting bugs with `emacs -Q'?
>>
>> That is the real problem here, and the one that you keep
>> ignoring.  Instead, you
>> keep focusing on the problem of customization, which is, relatively
>> speaking, no
>> big deal (assuming you finish fixing the repeated-interrogation bugs).
>
> No, that's not the real problem.  There are two problems:
> (1) What should Emacs do when the user asks it to send an email?
> (2) What should Emacs do when the user asks it to report a bug?
>
> This series of questions is appropriate in scenario 1, but not in
> scenario 2.

In scenario 1, the inclusion of mailclient is a bit pointless - if a
user wants to set Emacs up as a MUA, then they won't want their mail
going through another MUA.  So these questions are obviously intended
for scenario 2.


> report-emacs-bug.  The argument Drew is making would disappear
> instantly if report-emacs-bug sent an HTTP POST request, for instance.

Then we'd have to start asking the user questions about their proxy
server.  It isn't really an improvement.

Re: smtp crap

[Jason Rumney]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Wed, Oct 12, 2011 at 08:33,  <joakim@verona.se> wrote:
>
> If you are using for example Gmail as a webmail there is a utility you
> can install to make it the default MUA on your pc.
>
> And there are also add-ons for different browsers to make
> mailto:-links work with different webmails. (I think I suggested long
> ago to make Emacs bug reporter write a html page to take advantage of
> this.)

What benefits would writing a web page bring compared to the current
mailclient implementation?

Re: smtp crap

[Stefan Monnier]

>> Should the "sendmail" option be off the table if the system doesn't have
>> a sendmail executable?  (I.e., Windows and OS X.)
> Yes, I think so.  Having options that aren't applicable is confusing.

OK.  Tho I'd still prefer it if we don't just remove it flat out but
replace it by a blurb saying that it's possible but not applicable for
lack of sendmail.

> Here's my suggestion for the text of this prompt:

Sounds good.  Feel free to install it.


        Stefan

Re: smtp crap

[Stefan Monnier]

>> No, that's not the real problem.  There are two problems:
>> (1) What should Emacs do when the user asks it to send an email?
>> (2) What should Emacs do when the user asks it to report a bug?
>> This series of questions is appropriate in scenario 1, but not in
>> scenario 2.
> In scenario 1, the inclusion of mailclient is a bit pointless - if a
> user wants to set Emacs up as a MUA, then they won't want their mail
> going through another MUA.  So these questions are obviously intended
> for scenario 2.

Agreed.  So we need some way for sendmail-query-once to figure out that
it's called from Gnus/MH-E/Rmail/younameit rather than independently and
take out the `mailclient-send-it' option in that case.

Note that `mailclient-send-it' should be an option if the user simply
did M-x mail (i.e. he's not using a MUA but not report-emacs-bug
either).


        Stefan

Re: smtp crap

[Lennart Borgman]

On Wed, Oct 12, 2011 at 16:16, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Wed, Oct 12, 2011 at 08:33,  <joakim@verona.se> wrote:
>>
>> If you are using for example Gmail as a webmail there is a utility you
>> can install to make it the default MUA on your pc.
>>
>> And there are also add-ons for different browsers to make
>> mailto:-links work with different webmails. (I think I suggested long
>> ago to make Emacs bug reporter write a html page to take advantage of
>> this.)
>
> What benefits would writing a web page bring compared to the current
> mailclient implementation?

I think that web pages will normally open in a web browser. So I guess
at least that part will work without problems for most users.

And if the user have one of these add-ons I mentioned above a simple
link on that page can open a new message to send to the bug reporter.
(And that link may contain the relevant information about the bug.
Perhaps the whole bug report - I am not sure about text length limits
there.)

And if the user does not use web mail it will propably still work
since the default MUA will be started by the link on that page. (So it
could be a good first alternative that can work for most everyone.)

RE: smtp crap

[Drew Adams]

> > What benefits would writing a web page bring compared to the current
> > mailclient implementation?
> 
> I think that web pages will normally open in a web browser. So I guess
> at least that part will work without problems for most users.

Until someone decides to do for HTTP what they've just done for email: lead you
down the garden path to choose Emacs as your Web browser.

 It looks like you want to access the Web.
 Let us lead you through a simple interrogation
 to set up Emacs for Web browsing...
 Press 1 to continue in English.

;-)

Re: smtp crap

[Lennart Borgman]

On Wed, Oct 12, 2011 at 16:47, Drew Adams <drew.adams@oracle.com> wrote:
>> > What benefits would writing a web page bring compared to the current
>> > mailclient implementation?
>>
>> I think that web pages will normally open in a web browser. So I guess
>> at least that part will work without problems for most users.
>
> Until someone decides to do for HTTP what they've just done for email: lead you
> down the garden path to choose Emacs as your Web browser.

If it works then it is no problem.

And I forgot to tell that there is another advantage with writing a
web page. You can write it so it has it has two links, one for
submitting it as a report through a web server (if the bug tracking
system allows for that).

Re: smtp crap

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Wed, 12 Oct 2011 10:30:05 -0400
> 
> > Here's my suggestion for the text of this prompt:
> 
> Sounds good.  Feel free to install it.

Done.

RE: smtp crap

[Drew Adams]

> From: Stefan Monnier Sent: Monday, October 10, 2011 2:38 PM
>
> Editing the From is indeed a bug that we have to fix before
> the release.

Still not fixed.

And the UI is now worse than before.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9877

Users reporting a bug with `emacs -Q' should not have to specify ANYTHING about
email methods.  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?

Re: smtp crap

[Adam Sjøgren]

In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9877 Drew Adams wrote:

> Emacs does NOT need to know how to send email if a user has a mail
> client.

Maybe you could provide a recipe of how to determine if a user - on any
type of system Emacs runs on - who invokes "emacs -Q" and reports a bug,
has a mail client (installed, preferred and configured) or not?


  Best regards,

-- 
 "Gav                                                         Adam Sjøgren
  Strik"                                                 asjo@koldfront.dk

Re: smtp crap

[chad]

On Oct 26, 2011, at 10:58 AM, 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, with the user having no idea that the bug never made it beyond the local workstation.  

I am not the only one to report this kind of problem. 

This type of configuration is (as near as we can tell) at least as common now than it was then.

This has been mentioned several times in the various discussion threads.

*Chad

RE: smtp crap

[Drew Adams]

> > 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, with the user having no idea that 
> the bug never made it beyond the local workstation.  
> I am not the only one to report this kind of problem. 
> This type of configuration is (as near as we can tell) at 
> least as common now than it was then.

Yes, that is undesirable.

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.

IOW, again, let users explicitly _ask_ to configure Emacs, if they want to.

Forcing users to deal with this when they simply want to report a bug is not
TRT.

Yes, if there is no other choice for some user than to configure Emacs as a
mailer right then and there, s?he will do so - it's enough to explain it.  But
all other users can pass over that information, which doesn't concern them.  And
with this approach _no_ user is then forced into a configuration dialog: they
get that only on request.

See the subject line, as a reminder of what this is about: Separate the dialog
for email configuration from bug reporting.  It's as simple as that.  If some
users might need to configure email before being able to report a bug, fine -
they will.  But that logical dependency does not require us to inflict an email
configuration dialog on everyone.

Re: smtp crap

[chad]

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, with the user having no idea that 
>> the bug never made it beyond the local workstation.  
>> I am not the only one to report this kind of problem. 
>> This type of configuration is (as near as we can tell) at 
>> least as common now than it was then.
> 
> 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?''.

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

So, you want to ask the user, in the middle of reporting a bug, to
notice that there's a warning somewhere, and then guess whether or not
emacs can send mail without extra steps on their part, when we know
that a common failure mode is ``it doesn't work and the user can't
reasonably know that it didn't/won't work''.  Seems like a pretty poor
default to me. YMMV.

*Chad

RE: smtp crap

[Drew Adams]

> pretty clearly answers the question ``Why burden and confuse
> users now?''.

No, it does not.  It neither justifies the burden and confusion nor explains why
_now_.

If as you say the problem is real and not new, why now?  Why didn't RMS et al
tackle it many, many moon ago?  Wasn't it important enough?  Fewer mails sat
idle in local queues back then?  I foresee your answer: email is more
complicated now.  Tough.  That's not a reason for Emacs to act idiotically.

> > 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.
> 
> So, you want to ask the user,

No. read what I said.  I do _not_ want Emacs to ask the user anything here.
That's the point, in fact.

> in the middle of reporting a bug, to notice that there's a warning

I did not mention "warning".  The instructions and information we give to users
preparing a bug report, including what I suggested, are not "warnings".

> somewhere, and then guess whether or not emacs can send mail
> without extra steps on their part,

Absolutely not.  Read what I wrote: "If _you_ have not yet configured...".

There is nothing requiring the user to guess whether Emacs might be able to send
mail.

> when we know that a common failure mode is ``it doesn't work and
> the user can't reasonably know that it didn't/won't work''.

The user will reasonably know whether s?he has an email client (can send mail
outside Emacs).  The user will reasonably know whether s?he has already
explicitly configured Emacs itself for email.  There are of course always some
users who fall outside of "reasonable".  And yes, knowledgable user X might lend
his machine and Emacs to ignorant user Y.  Stuff happens.

We have never even tried mentioning this to users.  Who knows how many of the
"reasonable" users you cite would still end up with local mail queues full of
bug reports, if we simply informed them.

We might also mention to them that they will receive a confirmation email, if
sending their bug report is successful.  How many unsuccessful bug reports do
you think will fill up the local queues of "reasonable" users if we tell them to
expect an ACK mail?

Will users read all of this info each time they prepare a bug report?  Of course
not.  But they will likely read it the first time.  And there's no reason not to
let them know these things.

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

We've seen the solution you favor.

Even a simple `mailto:' would, in most cases, cause a user with no SMTP
configured and no other support for `mailto:' to see an error raised (e.g. by a
browser).  Why assume that Emacs must blindly remain silent over and over,
simply filling up a local mail queue with bug reports?

I'm no expert on email, but I know a lousy UI when I see one.  If it weren't for
my complaints and those by a few others (e.g. Miles), we would still have the
bass ackwards dialog that Lars originally implemented to solve this problem.
That solution drew no objection from the Emacs maintainers or other developers
arguing your position.

Just because you can recognize a problem does not mean that you have found a
proper solution.  Burdening and confusing _all_ users is not the right way to
avoid having a few users think they sent email when they didn't.  Try harder.

Re: smtp crap

[Tim Cross]

On Thu, Oct 27, 2011 at 4:58 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> From: Stefan Monnier Sent: Monday, October 10, 2011 2:38 PM
>>
>> Editing the From is indeed a bug that we have to fix before
>> the release.
>
> Still not fixed.
>
> And the UI is now worse than before.
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9877
>
> Users reporting a bug with `emacs -Q' should not have to specify ANYTHING about
> email methods.  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?
>

Actually, this isn't strictly true.

Anyone who uses emacs as their mail client and uses a remote mail
server rather than a local server, has NEVER been able to submit a bug
report easily when running emacs -Q or any invocation of emacs which
does not load their local configurations for that matter).  The usual
workflow is to save backtraces and other bug report relevant data into
files, quite emacs, start emacs without -Q and then do the bug report
submission.

I think this is very much the central issue. If we accept that

     1. Few systems have a correctly configured local MTA
     2. Increasingly systems are mobile and need to use remote
authenticated MTAs
     3. Some (many?) users don't want to use emacs as a MUA
     4. When submitting a bug report, many users are not interested or
willing to configure mail just to submit the          report. In some
cases, they may not even understand the issues involved to provide the
necessary information.

then perhaps we should also consider that it might be time to add an
ADDITIONAL way to submit bug reports that can avoid the complex,
fragile, error prone and frequently frustrating approaches that have
been proposed simply to maintain a mail based submission mechanism. By
all means, continue to support submission of bug reports by mail, but
ADD another mechanism which is able to work more reliably on systems
which may not have email configured or use a configuration which is
not available. Allow the user to select the method they want - if they
select email submission and emacs needs to ask them a bunch of
configuration questions, thats fine as they chose that route.

Note that the suggestion to add another mechanism, such as an http
based gateway has been rejected in the past on a couple of grounds. It
has been suggested that RMS doesn't want this, though from looking in
the archives, I would suggest he was actually more concerned about the
loss of email as a way to submit bug reports, not that it can/should
be the only way to submit such reports. Also, it has been suggested
that this cannot be done because the bug tracker won't support it -
this too is nonsense. There are plenty of http -> mail examples out
there which could just as easily be applied in this situation. Note
that I'm just using http as an example, other possible solutions exist
and should be explored. My only suggestion is that many of the issues
which have been raised wrt changes in the default mail configuration
can be avoided simply by providing another means to submit bug
reports.

Tim




-- 
Tim Cross

Re: smtp crap

[Stefan Monnier]

>> Users reporting a bug with `emacs -Q' should not have to specify ANYTHING about
>> email methods.

Users have no reason to report bugs with "emacs -Q".  I won't stand in
their way if they want to do so, but it is a use-case that
I consider irrelevant.

> The usual workflow is to save backtraces and other bug report relevant
> data into files, quit Emacs, start Emacs without -Q and then do the
> bug report submission.

Almost, except that the "Emacs without -Q" doesn't need to be started,
since it's been running for the last few days at least.


        Stefan

Re: smtp crap

[Stephen J. Turnbull]

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?