bug#28902: 25.3; M-x report-emacs-bug requires smtp

[Alexis]

Faré <fahree@gmail.com> writes:

> M-x report-emacs-bug tries to send mail from the localhost, but 
> these
> days, due to spam issues, SMTP is not quite as available as it 
> was say
> twenty years ago. Most localhost do not have a mail server; most 
> ISPs
> do not offer SMTP and further block SMTP ports; most servers on 
> the
> internet will not relay mail without authentication; to setup 
> your own
> server requires possessing a domain and a stable server, 
> altering DNS
> records and mastering technologies such as DKIM, DMARC, SPF, 
> etc.,
> that did not exist back in the days when M-x report-emacs-bug 
> was
> originally written.

True. On the other hand, those are not the only possibilities; a 
number
of people, such as myself, use a dedicated email service provider, 
and
have set up SMTP clients such as `msmtp' to send email via that
provider's SMTP servers.

> To remain usable, M-x report-emacs-bug should at the very least
> document how one may send the mail via some webmail instead

i might be missing something, but do people think they can't just 
copy
and paste the report text into a new email, and send it to the 
address
specified in the report buffer's To: field, 
i.e. bug-gnu-emacs@gnu.org?

> or offer to configure emacs (or the underlying system) to offer 
> some
> interface that will bridge the SMTP gap somehow.

The problem is that there are just so many different ways of 
setting up
email - not only across operating systems, but also within a given
OS/distro. Even if one settled on, say, using msmtp (rather than, 
say,
exim, postfix, esmtp, opensmtpd, sendmail etc.) as the underlying 
MTA,
there's still the question of how to actually get that on the 
user's
system if it's not already installed:

* Via a package manager? If so, then the various package UIs (apt, 
 yum,
 dnf, YaST, pacman, apk, etc.) need to be taken into 
 consideration, as
 do the various locations that different OSes might put the 
 various
 configuration files. Further, not all users will necessarily 
 have the
 permissions to allow installing arbitrary packages.

* Build it from source? Many users won't have the necessary build 
 setup
 on their machine (or indeed, be able to install the necessary 
 setup).

* Bundle it with Emacs? Assuming the license allows that, that's 
 going
 to create maintenance burdens in terms of tracking upstream's
 bug/security fixes, and e.g. having to release a new version of 
 Emacs
 in order to get a security fix for the MTA onto users' machines.

And then there are the security issues that come with having an
configured MTA available on a machine; it's one thing if someone 
is
making use of that MTA for various email needs, it's another if 
it's
only being used by Emacs ....

So it seems to me that designing an interface to covering all, or 
even
many, of the possibilities would be an /enormous/ task.


Alexis.