help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: sending mail is very slow


From: Tim X
Subject: Re: sending mail is very slow
Date: Fri, 12 Sep 2008 13:08:10 +1000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

tyler <tyler.smith@mail.mcgill.ca> writes:

> Hi,
>
> I use VM for email, and it's *very* slow to send emails when I'm
> connected to my university network. It's noticeably slow at home
> sometimes too, but not so bad. For example, after I compose a message
> and send it with C-c C-c I'll see the message in the mini-buffer
> indicating that the message has been copied to my sent folder, but the
> actual message remains on the screen for 10 seconds or more, and during
> this time I cannot interact with Emacs.
>
> This same behaviour occurs when I send a message using the regular emacs
> M-x mail command, so I don't think it's VM specific. Is there something
> I can tweak in my configuration to correct this? Any other tips? I don't
> notice this problem in Gnus, but opening Gnus itself takes a very long
> time when I'm using the University network as well.
>
> I thought the size of my sent mail file might be the problem, but
> cutting it down from 2.9M to 210K didn't help at all.
>
> Emacs 23.0.60.1, built from source on Debian Lenny/Testing
>
> Thanks,
>

This sounds like an issue with your mail server rather than anything to
do with emacs or VM. I'm assuming you have things configured to use the
University or ISP mail server directly. 

solutions depend on the platform your on and how the mail servers are
configured. One solution is to configure a local mail server as a
smarthost on your system. Essentially, VM or any other mail program will
dispatch your message to the local mail server, which in turn will
dispatch it to the University/ISP mail server. Delays/failures in
sending the mail is hidden from you and doesn't result in emacs being
locked up. However, there are some drawbacks, including

 * some anti-spam software will possibly reject your mail because it is
   from an unknown IP address (your mail will appear to have originated
   from your local mail server - there are ways around this, but they
   can be a bit complex and depend on the mail server your using). 

 * If you are on a laptop, or if you shutdown your system regularly, you
   need to ensure the mail has been dispatched before you
   shutdown/disconnect. 

 * You have to maintain a mail server. This is relatively easy with
   modern mail servers, especially in a smart host configuration where
   it only dispatches mail and doesn't recieve it.

 * There are a few configuration issues to consider - for example,
   what/how is mail from root and other system accounts handled and how
   is mail to root and other system accounts handled. For exmaple, you
   don't want your mail server to relay mail for root to the main server
   as it will then likely end up in the mailboxes of that servers sys
   admins rather than in yours. 

Other solutions could be to look at other mail agents, such as mew,
which I believe may have an option to send mail in batches. The real
problem here is that because emacs is single threaded, you have to wait
until the mail has been accepted by the mail server before emacs can
return and you can continue doing stuff. If the mail server you are
using is sometimes heavily loaded or if your network connection is
slow/unreliable, you will see this sort of problem frequently. In such a
case, the local mail server solution is probably the only thing that
will work. Note that I think there are some very 'light-weight' mail
servers designed for this type of situation (I seem to remember seeing a
package in Debian called something like smtp-send or something similar
that was designed for this type of problem. It is essentially a basic
smtp injection program. It doesn't stop the delays, but moves them away
form where you notice it directly i.e. the smtp-send program may take 10
or 15 seconds to hand the mail to the main mail server, but yo don't see
this as smto\p-send has already returned a message to the client
essentially saying OK, I'll try to deliver that for you". 

HTH

Tim


-- 
tcross (at) rapttech dot com dot au


reply via email to

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