[26444] in Athena Bugs
Re: linux 9.3.18: evolution
daemon@ATHENA.MIT.EDU (John Hawkinson)
Wed Jun 1 11:54:37 2005
Date: Wed, 1 Jun 2005 11:53:48 -0400
From: John Hawkinson <jhawk@mit.edu>
To: Jonathon Weiss <jweiss@mit.edu>
Message-ID: <20050601155348.GK23850@multics.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200506011317.j51DHXA0015513@bearing-an-hourglass.mit.edu>
X-Spam-Score: 1.041
X-Spam-Level: * (1.041)
X-Spam-Flag: NO
cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
Jonathon Weiss <jweiss@MIT.EDU> wrote on Wed, 1 Jun 2005
at 09:17:33 -0400 in <200506011317.j51DHXA0015513@bearing-an-hourglass.mit.edu>:
> It seems really silly to do this for one client.
Well, I don't care a lot either way, and think any solution would be
better than what we have now.
But that said, I would worry that it might confuse some clients and
scripts. Also, if it were done at the MUA level, then users would have
the option to change it back if they wished.
I think [not sure], also, that MUAs may be able to handle the situation
a bit better than just -odb -ing sendmail, i.e. by forking and watching
the sendmail status and then communicating it back to the main client
via some IPC.
mutt's option is sendmail_wait=-1 pine's is enable-background-sending (docs
below).
Perhaps it is moot since I don't see any such option in evolution's
UI, nor in a cursory glance in third/evolution/camel/providers/sendmail.
> 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,
Really? I assume it's that way because its the sendmail default,
because usually the cost of real-time feedback is low, because the delay
is low. -- Hmm, nope. For sendmail 8, at least, background is the
default (I am now less worried about scripts). We added it (for Solaris)
in:
----------------------------
revision 1.21
date: 2003/07/25 05:20:36; author: zacheiss; state: Exp; lines: +21 -3
Add authinfo ruleset to sendmail.cf, and try to deliver to port 587
(mail submission port). Replace athconf text map with a program map
using /etc/athena/sendmail-relay-select to determine whether to do
direct delivery at run time.
Make sendmail-noauth.cf a copy of of our old sendmail.cf file with only
the athconf map change in place.
----------------------------
--jhawk
6.3.192. sendmail_wait
Type: number
Default: 0
Specifies the number of seconds to wait for the ````$sendmail''''
process to finish before giving up and putting delivery in the
background.
Mutt interprets the value of this variable as follows:
>0 number of seconds to wait for sendmail to finish before
continuing
0 wait forever for sendmail to finish
<0 always put sendmail in the background without waiting
Note that if you specify a value other than 0, the output of the child
process will be put in a temporary file. If there is some error, you
will be informed as to where to find the output.
PINE 4.58L HELP FOR SETUP CONFIGURATION Line 25 of 25 ALL
FEATURE: enable-background-sending
This feature affects the behavior of Pine's mail sending. If set, this
feature enables a subcommand in the composer's "Send?" confirmation
prompt. The subcommand allows you to tell Pine to handle the actual
posting in the background. While this feature usually allows posting to
appear to happen very fast, it has no affect on the actual delivery time
it takes a message to arrive at its destination.
Please Note:
1. This feature will have no effect if the feature
"Send-Without-Confirm" is set.
2. This feature isn't supported on all systems. All DOS and Windows, as
well as several Unix ports, do not recognize this feature.
3. Error handling is significantly different when this feature is
enabled. Any message posting failure results in the message being
appended to your "Interrupted" mail folder. When you type the Compose
command, Pine will notice this folder and offer to extract any
messages contained. Upon continuing a failed message, Pine will
display the nature of the failure in the status message line.
4. WARNING: Under extreme conditions, it is possible for message data to
get lost. Do not enable this feature if you typically run close to
any sort of disk-space limits or quotas.
<End of help on this topic>
> 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
