Re: smtp crap

[Tim Cross]

On Tue, Oct 11, 2011 at 3:41 PM, chad <address@hidden> 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