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

[Tim Cross <theophilusx@gmail.com>]

On Fri, Jul 8, 2011 at 10:06 AM, Richard Stallman <rms@gnu.org> wrote:
>    What I find is still unclear is whether those who will benefit will
>    outweigh those who will be disadvantaged.
>
> If we do what I suggest, some will gain and none will lose.
>

Hi Richard,

yes, if we are talking about your suggestion to test and determine if
the local MTA is configured, in theory that would possibly work. Your
suggestion of using make install is unlikely to work though. Most
emacs users seem to work from pre-built binaries and never run make.
While we could then say this is a distro packaging issue, I doubt any
distros will implement it due to the complexity involved.

I think the main problems with determining if a local MTA is installed
and configured are

     - There are many different MTAs. While most have at least partial
compatibility with 'sendmail', they don't always and they do things in
different ways. Reliably determining which MTA is installed can impact
on how you will test for a working config - some have good support for
this, others do not.

     - Testing for things in the local spool file is not reliable.
Some MTAs don't use the traditional mbox spool file for user's mail,
some use maildir, some can offer either etc.

     - The location used to store users mail can vary a lot. While
/var/mail is now common, it use to be /var/spool/mail and I've seen
many configurations that put it in the users home directory directly.

With respect to the question of why bounced messages would end up in
root (or postmaster's mailbox), the reasons are many. In the years
where I was responsible for administering mail servers for large
numbers of users, the three most common reasons were

     - Misconfigure 'from' address i.e. wrong username or domain. This
is surprisingly common. Mail servers never silently throw mail away.
If it cannot be delivered or bounced back to the sender, it is given
to postmaster, which is often aliased to root (at least on smaller and
single user systems). This can be somewhat mitigated with local MTAs
depending on the configuration. In the 'old' days, sendmail only
allowed 'trusted' users to set a from address different to the
username or owner of the process injecting the message for delivery.
You could use the -f (from memory) switch to sendmail to alter the
from address, but if yhou were not a trusted user, this was not
allowed. There also use to be restrictions on being able to modify the
envelop-from address. This greatly reduced the number of messages that
could not be returned to the sender as the from address had to be
correct i.e. had to have a real account on that system. However, newer
MTAs don't seem to have this restriction and many systems don't appear
to enforce this sort of restriction any more. It is now much easier to
get the from address settings wrong and have your mail appear to be
sent when in fact it was bounced, but the bounce never got to you.


     - Quota issues. Sometimes, the users mbox is past quota and won't
allow any additional messages to be put into their mailbox.  Usually,
the mail will be bounced back to the sender, but if that sender is
also the recipient, we end up with a looping problem. The loop is
broken by delivering the message to postmaster.

     - Misconfigured procmail or other delivery scripts. Sometimes
this is caused by the user and sometimes it is just mistakes made by
the sys admin. The types of problems are almost limitless and there is
no way to be certain about what will happen or where the mail will go.
Usually, when all else fails, the message will be delivered to
postmaster, but it is possible it will just be logged and never
delivered anywhere (though this is the extreme and rare case).

While with a lot of effort, I believe someone could probably implement
something that would get us 80% of the way, I think the effort would
be significant and maintenance would be very high. I also suspect we
are trying to solve a problem from an emacs perspective which should
really be solved from outside. Imagine the benefits to many packages
if there was a standard mechanism that could be used to determine if
the client should use a local MTA or a remote server and in the case
of the remote server, provide details, such as server name, port etc.
Maybe something similar to what the xdg group have done in other
areas.

Despite my negative assessment of your suggestion, I think the
underlying assumptions/principals are spot on. The new default should
have an overall beneficial result. I was previously focusing on the
impact for GNU/Linux users and thought the change was potentially
positive given that email environments have moved on and many people
do use remote smtp servers, especially those using laptops. However, I
didn't want those who currently get the functionality with little to
no effort to lose, especially when emacs is not their primary email
client. Maybe I expect too much!

At any rate, I've tried to express my concerns and feel its time to
let the decison be whatever it will be. In all likelihood, most people
will just accept the change and move on. There doesn't seem to be much
more to gain from this back and forth. At least the new default being
proposed is an improvement on the original suggestion of just setting
it to smtpmail.

Tim