emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mailclient-send-it usage of browse-url


From: David Reitter
Subject: Re: mailclient-send-it usage of browse-url
Date: Tue, 13 Apr 2010 18:06:25 -0400

Christian,

On Apr 13, 2010, at 3:51 PM, Christian Lynbech wrote:

> I would like to question the wisdom of letting `mailclient-send-it'
> blindly relying on `browse-url' to send mail, especially since this is
> set up as the default mail sending client on mac and windows.


> I am certainly not fully on top of how emacs-w3m is supposed to handle
> mailto. My `w3m-mailto-url-function' variable is nil and then the
> documentation says control goes back to `mail-user-agent' which sort of
> looks like the receipe of an infinite loop to me.

>  Browse-url seems a shaky foundation
> for mail sending given it is anyway not well-specified what it really
> points to.


first of all, the reason why we don't go via `sendmail' is that mail gets 
swallowed by firewalls and spam filters.  I have recent first-hand experience 
with this when a user complained about bug reports vanishing after the send 
mail function got accidentally switched back to sendmail in a beta release of 
Aquamacs.

I thought of recommending to switch back to `sendmail' when Apple fixed their 
sendmail mechanism (it was broken at some point, prompting mailclient.el), but 
the above experience made me discard that thought.

Second, as you state, the "from" field isn't filled in right (at least on the 
two systems you mention), and third, users will have configured their preferred 
mail client, where the message is supposed to be archived.

"mailto:"; URLs are an established standard ( 
http://www.ietf.org/rfc/rfc1738.txt ) and most browsers handle it correctly, 
i.e. by calling the system's mail function.  I know of no more appropriate 
system-specific mechanism to let the default mail client handle mail on OS X.  
I think there was a way to send e-mail on Windows, which was very populars 
among writers of viruses and trojans.

There are issues with long messages not going through GMail (via "Google Mail 
Notifier"), but this is due to Google's servers and long URLs, and a bug on 
their side.

So, the problem lies in the infinite loop that you point out and one could and 
should do something about it.  Perhaps "mailclient" shouldn't use browse-url in 
case of an infinite loop, but that may be difficult to detect (asynchronous API 
in some situations).  
Perhaps w3m (being a third party package) should detect the send-mail-function 
setting and temporarily bind it to `sendmail-send-it' or so.

Sending mail isn't trivial.  But we really don't want to lose bug reports or 
user's mail.  The mailclient solution is standards-compliant and does the right 
thing in the majority of configurations.  I agree: pretty it is not.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]