send-mail-function / mailclient

send-mail-function / mailclient

[David Reitter]

Back when we introduced mailclient.el, we used it as default for OS X,  
because there, the built-in postfix mail sending function did not work  
right and led to e-mail being swallowed.  In recent OS X versions,  
this has been fixed.  Postfix is started on demand without the need  
for user configuration.

Second, there are issues with mailclient's "mailto" URL method of  
invoking the mail client application in connection with the popular  
Gmail service (the helper application that passes the mailto URL on to  
the web service does not accept long URLs).  This is a bug in Google's  
software, not ours, but users are struggling with it.

Third, the mailclient method would be more convenient if mail was  
composed by Emacs, but then passed on to the mail client to be edited  
there.  This is the normal intention of the "mailto" method.  Right  
now, the message is edited in Emacs and then passed on to the mail  
client, where it is edited (or editable) again, before being sent  
off.  I think this is inconvenient.

It may therefore be sensible to revise the default for send-mail- 
function in Emacs 23, given that it was a workaround for the lack of  
Postfix configuration.  The workaround is not needed any more, and we  
could use the local mail server in all cases (maybe not on Windows).

On the downside, I find that sending mail Postfix-style does not work  
as well as it used to, due to crippled mail servers that refuse to  
accept mail from dynamic IP ranges (i.e. home broadband) as a spam- 
defense.

So, the whole thing is debatable.  The argument is less dependent on  
the specific system now.  Quite possibly, a choice of `mailclient' for  
all systems (sans Windows?) may be in order.

In order to ensure that Emacs bug reports always reach the  
destination, one could also use a `mailclient' variant that sends e- 
mail directly to a CGI running on Savannah.  That would require online  
connectivity, of course. 

Re: send-mail-function / mailclient

[Stefan Monnier]

> Back when we introduced mailclient.el, we used it as default for OS X,
> because there, the built-in postfix mail sending function did not work
> right and led to e-mail being swallowed.  In recent OS X versions,  this has
> been fixed.  Postfix is started on demand without the need  for
> user configuration.

Even if Postfix works differently now, the problem is not solved.
It's just that it works now "just as poorly as under most GNU/Linux
systems".

> On the downside, I find that sending mail Postfix-style does not work as
> well as it used to, due to crippled mail servers that refuse to  accept mail
> from dynamic IP ranges (i.e. home broadband) as a spam- 
> defense.

Yes, that's the problem.  Nowadays, "systems" are basically not allowed
to email any more, only "users".  So using `postfix' (which is not
under the control of a user. but only under the control of the system)
doesn't cut it.


        Stefan

Re: send-mail-function / mailclient

[David Reitter]

On 19 Jan 2009, at 23:52, Stefan Monnier wrote:

>> On the downside, I find that sending mail Postfix-style does not  
>> work as
>> well as it used to, due to crippled mail servers that refuse to   
>> accept mail
>> from dynamic IP ranges (i.e. home broadband) as a spam-
>> defense.
>
> Yes, that's the problem.  Nowadays, "systems" are basically not  
> allowed
> to email any more, only "users".  So using `postfix' (which is not
> under the control of a user. but only under the control of the system)
> doesn't cut it.

In order to use the `mailclient' method on all systems, we should  
consider the following issues:

- some incorrect implementations of mail clients (notably GMail  
Notifier) fails to handle long URLs.  In the case of Gmail it seems to  
be the server software that cuts off long URLs (intentionally, I  
assume).  You may argue that this is a bug in these "mail clients",  
but that doesn't help our users.  I have received several bug reports  
from Aquamacs users regarding this and I now use a workaround that  
falls back to the "sendmail" method if Gmail is used.

- Buffers are edited twice - once in Emacs, and then again in the mail  
client.  The mailto:// protocol wasn't designed to handle full  
messages to be sent off without editing.  We're abusing the protocol.   
Sending bug reports may best be handled by composing the template and  
then having users edit the report in their preferred mail client.   
Sending e-mail with packages such as VM requires user to configure an  
SMTP server anyways, so `send-mail-function' can be expected to be  
customized,too.

- What happens if Emacs is used as mailto:// handler?  At least on my  
system, we don't provide the function directly, but in principle,  
users should be able to do this.  If GNU/Linux has some kind of  
accepted standard to announce "I can handle xxx:// URLs", then perhaps  
we should implement it (for all systems).

Re: send-mail-function / mailclient

[Lennart Borgman]

On Tue, Jan 20, 2009 at 9:06 PM, David Reitter <david.reitter@gmail.com> wrote:
> On 19 Jan 2009, at 23:52, Stefan Monnier wrote:
>
>>> On the downside, I find that sending mail Postfix-style does not work as
>>> well as it used to, due to crippled mail servers that refuse to  accept
>>> mail
>>> from dynamic IP ranges (i.e. home broadband) as a spam-
>>> defense.
>>
>> Yes, that's the problem.  Nowadays, "systems" are basically not allowed
>> to email any more, only "users".  So using `postfix' (which is not
>> under the control of a user. but only under the control of the system)
>> doesn't cut it.
>
> In order to use the `mailclient' method on all systems, we should consider
> the following issues:
>
> - some incorrect implementations of mail clients (notably GMail Notifier)
> fails to handle long URLs.  In the case of Gmail it seems to be the server
> software that cuts off long URLs (intentionally, I assume).  You may argue
> that this is a bug in these "mail clients", but that doesn't help our users.
>  I have received several bug reports from Aquamacs users regarding this and
> I now use a workaround that falls back to the "sendmail" method if Gmail is
> used.
>
> - Buffers are edited twice - once in Emacs, and then again in the mail
> client.  The mailto:// protocol wasn't designed to handle full messages to
> be sent off without editing.  We're abusing the protocol.  Sending bug
> reports may best be handled by composing the template and then having users
> edit the report in their preferred mail client.  Sending e-mail with
> packages such as VM requires user to configure an SMTP server anyways, so
> `send-mail-function' can be expected to be customized,too.
>
> - What happens if Emacs is used as mailto:// handler?  At least on my
> system, we don't provide the function directly, but in principle, users
> should be able to do this.  If GNU/Linux has some kind of accepted standard
> to announce "I can handle xxx:// URLs", then perhaps we should implement it
> (for all systems).

When this was discussed some time ago a workaround was implemented for
w32. I think this can be used on most platforms.

With this workaround you can edit the data in both Emacs and the mail
client. When you finish editing the mail message in Emacs the users
mail client is started to edit a new mail message. This message has
the subject from Emacs, but the body just says

   *** E-Mail body has been placed on clipboard, please paste them here! ***

This is implemented in mailclient.el

Re: send-mail-function / mailclient

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

On 20 Jan 2009, at 15:25, Lennart Borgman wrote:

> When this was discussed some time ago a workaround was implemented for
> w32. I think this can be used on most platforms.
>
> With this workaround you can edit the data in both Emacs and the mail
> client. When you finish editing the mail message in Emacs the users
> mail client is started to edit a new mail message. This message has
> the subject from Emacs, but the body just says


That is a clean, working solution.  Any application that sends e-mail  
will have the problem of making users configure mail servers.  Thus, I  
would find it acceptable to use mailclient as default.  It would be  
important to point people to `send-mail-function' when they configure  
the mail servers (i.e. in the appropriate doc strings at least).   It  
is clear that mailclient makes no sense once somebody uses Emacs for  
mail...

Similarly, M-x report-emacs-bug wasn't conceived for such an  
arrangement:

>> - Buffers are edited twice - once in Emacs, and then again in the  
>> mail
>> client.  The mailto:// protocol wasn't designed to handle full  
>> messages to
>> be sent off without editing.  We're abusing the protocol.

Finally:

> - What happens if Emacs is used as mailto:// handler?  At least on my
> system, we don't provide the function directly, but in principle,  
> users
> should be able to do this.  If GNU/Linux has some kind of accepted  
> standard
> to announce "I can handle xxx:// URLs", then perhaps we should  
> implement it
> (for all systems).

Perhaps GNU/Linux doesn't offer a central way to advertise URL  
protocol handlers, but other systems do.  We need a way to set this in  
Emacs 23.2.


However, there seems to be a consensus that mailclient would be the  
right default on all systems now.  Is this agreed?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]