[26443] in Athena Bugs

home help back first fref pref prev next nref lref last post

Re: linux 9.3.18: evolution

daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Wed Jun 1 09:17:50 2005

Date: Wed, 1 Jun 2005 09:17:33 -0400 (EDT)
Message-Id: <200506011317.j51DHXA0015513@bearing-an-hourglass.mit.edu>
To: John Hawkinson <jhawk@mit.edu>
In-reply-to: "[26440] in Athena Bugs"
From: Jonathon Weiss <jweiss@mit.edu>
X-Spam-Score: 1.657
X-Spam-Level: * (1.657)
X-Spam-Flag: NO
cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu


   > What's wrong:
   >
   > 	It is incredibly slow for email.  It now takes 5-6 seconds per
   >       email.
   > 
   > What should have happened:
   >
   > 	It should send in under a second, even with some sort of
   >       authentication.

   Is there not an option to make evolution send its email in the background?
   (e.g. sendmail with -odb, or whatever)

It seems really silly to do this for one client.  I suspect that if we
want to do this at all, what we ant to do is change the sendmail.cf so
the default delivery mode is background, rather than interactive.
However, it is the way it is for a reason.  IIRC (can anyone confirm?)
the reason is so that someone doesn't end up kdestroying mid-delivery,
such that the authentication blew out.  That said, even if they did,
the mail message should end up in the local queue and be delivered
(directly) when the next queue runner comes along.  Further,
kdestroying during the 7-9 seconds that outgoing is busy gazing at its
navel (unsurprisingly) does not pose a problem for the authenticated
connection, though I suppose having sendmail killed by the logout (I'm
not sure if that would actually happen or not) would.

The delay to outgoing is starting to get annoying enough that I'm
tempted to suggest we switch to background delivery and screw the
consequences, but I'm interested in hearing other opnions.

-- 

	Jonathon

home help back first fref pref prev next nref lref last post