Re: `send-mail-function' default change

[Tim Cross]

On Fri, Jul 8, 2011 at 6:56 AM, Lars Magne Ingebrigtsen <address@hidden> wrote:
> Stefan Monnier <address@hidden> writes:
>
>> This can't be done, because there's no reliable way to check whether
>> sendmail does work.
>
> One thing that I don't think has been discussed in this area (yay!
> another sub-thread in an unending thread) is the issue of failing early
> versus retrying.
>
> Here's the issue:
>
> You're using a laptop at home, and you've got exim configured to (for
> instance) send mail directly (because your ISP does not block port 25),
> and things work fine.
>
> Then you bring the laptop with you while going on holiday.  You read
> your email, as usual, from imap.example.com, and you're replying as
> usual.  But the hotel you're at is blocking port 25.
>
> exim will then queue up the messages, and after a certain time period,
> it'll send you a (local) message saying that it couldn't send the
> emails.  (If I recall correctly, the default is one day.)  It will retry
> sending for four days, so if you go home before that time, it will send
> all the messages when you get home.
>
> Now, you won't see any error messages in this period.  You most likely
> aren't reading the local /var/mail/spool/.  So if this is something
> you're not familiar with, you'll wonder where the emails went.  If you
> are familiar with this situation, you'll figure it out after a while,
> reconfigure, and flush the queue.
>
> If Emacs talks SMTP directly, you will get an error message immediately
> at the hotel, and can choose to reconf, or you can choose to queue the
> mail in Emacs.
>
> Now, some people will prefer different behaviours.  Some people probably
> use the let-exim-queue-locally-until-I-get-home behaviour, and find that
> it suits their needs.
>
> But I have a suspicion that most people would like to get an error
> message as early as possible.
>

For me, this scenario is just one of the complexities covered under
the mobile computing paradigm. It is probably the most compelling
argument for changing the default. However, it is probably only really
relevant for those who use emacs as their mail client.

 The specific case you raise is likely quite rare as most ISPs have
blocked port 25 due to issues relating to their domain being used for
spamming and needing to have some control over what can be sent. THe
common configuration is to allow anyone with an IP address within
their control to relay mail through their server (usually without
authentication) and to block port 25.  Most ISPs also offer and
authenticated server as well, which is there to support their clients
who use mobile devices and want to use the ISPs mail server from
foreign networks.

The configuration you propose was fairly common prior to this change
by ISPs. However, it would be vary rare for a mail client to be setup
to send mail through the local MTA and NOT also read mail from the
local mail spool. The many mail clients I've used on systems with a
local MTA default to reading the local mail spool and need to be
explicitly configured not to (mutt, pine, exmh and most emacs based
clients - I think even thunderbird will by default if you configure it
to use the local MTA, though it does by default look for a remote
server using thier ISP server lookup functionality).

To some extent, I think we need to be less worried about users who do
explicit mail customization. These are usually users who have a
certain level of investment in getting things working. The ones at
issue are those who found mail just worked and those who only use
emacs for mail as a side-effect of some other action, such as sending
a bug report.

Tim