<strong>Report forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Mark Baker &lt;mbaker@iee.org&gt;</code>:<br>
<code>Bug#59134</code>; Package <code>exim</code>.


debian-bugs-dist@lists.debian.orgMark Baker <mbaker@iee.org>

Subject: Bug#59134: exim: delayed delivery of incoming messages
Reply-To: Brian White <bcwhite@pobox.com>, 59134@bugs.debian.org
Resent-From: Brian White <bcwhite@pobox.com>
Orignal-Sender: bcwhite
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Mark Baker <mbaker@iee.org>
Resent-Date: Sun, 27 Feb 2000 17:48:01 GMT
Resent-Message-ID: <handler.59134.B.95167356919039@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 59134
X-Debian-PR-Package: exim
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by bugs@bugs.debian.org id=B.95167356919039
          (code B ref -1); Sun, 27 Feb 2000 17:48:01 GMT
Sender: bcwhite
Message-ID: <38B96301.677D11FE@pobox.com>
Date: Sun, 27 Feb 2000 12:46:41 -0500
From: Brian White <bcwhite@pobox.com>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: submit@bugs.debian.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Package: exim
Version: 3.03-4
Severity: wishlist

I'm having a problem running exim behind a slow modem.  When a large
volume of mail starts getting queued outbound, exim tries to deliver
each one immediately.  As a result, my poor, slow modem gets bogged down
with 20+ pieces of simultaneous (large) outgoing email and they almost
all fail.

My only recourse at the moment is to set the "deliver_load_max" to some
exceedingly tiny value such that immediate deliveries never happen.
Unfortunately, this means that no deliveries will happen until the
next 'runq' starts -- adding an average 7 minute delay to _all_ outbound
email.

An option like "max_simultaneous_deliveries" would solve this reasonably
nicely by forcing any additional messages to get put in the queue instead.
The "deliver_load_max" does not effectively measure the number of delivery
processes since they are all blocked behind the slow modem and thus are
not counted as "ready to run".  This option isn't an ideal solution, of
course, since those extra will get delivered only come the next 'runq'
instead of as soon as the current deliveries finish, but it would still
be a big improvement.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
               He who has infinite patience sees instant results.



<strong>Acknowledgement sent</strong> to <code>Brian White &lt;bcwhite@pobox.com&gt;</code>:<br>
New Bug report received and forwarded.  Copy sent to <code>Mark Baker &lt;mbaker@iee.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Brian White <bcwhite@pobox.com>
Subject: Bug#59134: Acknowledgement (exim: delayed delivery of incoming messages)
Message-ID: <handler.59134.B.95167356919039.ack@bugs.debian.org>
In-Reply-To: <38B96301.677D11FE@pobox.com>
References: <38B96301.677D11FE@pobox.com>
X-Debian-PR-Message: ack 59134

Thank you for the problem report you have sent regarding Debian.
This is an automatically generated reply, to let you know your message has
been received.  It is being forwarded to the developers mailing list for
their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Mark Baker <mbaker@iee.org>

If you wish to submit further information on your problem, please send
it to 59134@bugs.debian.org (and *not* to
bugs@bugs.debian.org).

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at submit) by bugs.debian.org; 27 Feb 2000 17:46:09 +0000
Received: (qmail 19037 invoked from network); 27 Feb 2000 17:46:09 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
  by master.debian.org with SMTP; 27 Feb 2000 17:46:08 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
	by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
	id 12P7ll-0008Ut-00; Sun, 27 Feb 2000 12:46:13 -0500
Sender: bcwhite
Message-ID: <38B96301.677D11FE@pobox.com>
Date: Sun, 27 Feb 2000 12:46:41 -0500
From: Brian White <bcwhite@pobox.com>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: submit@bugs.debian.org
Subject: exim: delayed delivery of incoming messages
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Package: exim
Version: 3.03-4
Severity: wishlist

I'm having a problem running exim behind a slow modem.  When a large
volume of mail starts getting queued outbound, exim tries to deliver
each one immediately.  As a result, my poor, slow modem gets bogged down
with 20+ pieces of simultaneous (large) outgoing email and they almost
all fail.

My only recourse at the moment is to set the "deliver_load_max" to some
exceedingly tiny value such that immediate deliveries never happen.
Unfortunately, this means that no deliveries will happen until the
next 'runq' starts -- adding an average 7 minute delay to _all_ outbound
email.

An option like "max_simultaneous_deliveries" would solve this reasonably
nicely by forcing any additional messages to get put in the queue instead.
The "deliver_load_max" does not effectively measure the number of delivery
processes since they are all blocked behind the slow modem and thus are
not counted as "ready to run".  This option isn't an ideal solution, of
course, since those extra will get delivered only come the next 'runq'
instead of as soon as the current deliveries finish, but it would still
be a big improvement.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
               He who has infinite patience sees instant results.



<strong>Reply sent</strong> to <code>Mark Baker &lt;mbaker@iee.org&gt;</code>:<br>
You have marked Bug as forwarded.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Mark Baker <mbaker@iee.org>
Bcc: debian-bugs-forwarded@lists.debian.org
Subject: Bug#59134: marked as forwarded (exim: delayed delivery of incoming messages)
Message-ID: <header.59134.F59134.95176713526932.ackfwdd@bugs.debian.org>
In-Reply-To: <20000228192931.A4338@aziraphale.demon.co.uk>
References: <20000228192931.A4338@aziraphale.demon.co.uk> <38B96301.677D11FE@pobox.com>
X-Debian-PR-Message: forwarded 59134

Your message dated Mon, 28 Feb 2000 19:29:31 +0000
with message-id <20000228192931.A4338@aziraphale.demon.co.uk>
and subject line [bcwhite@pobox.com: Bug#59134: exim: delayed delivery of incoming messages]
has caused the Debian Bug report #59134,
regarding exim: delayed delivery of incoming messages
to be marked as having been forwarded to the upstream software
author(s) exim-users@exim.org.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Darren Benham
(administrator, Debian Bugs database)

Received: (at submit) by bugs.debian.org; 27 Feb 2000 17:46:09 +0000
Received: (qmail 19037 invoked from network); 27 Feb 2000 17:46:09 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
  by master.debian.org with SMTP; 27 Feb 2000 17:46:08 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
	by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
	id 12P7ll-0008Ut-00; Sun, 27 Feb 2000 12:46:13 -0500
Sender: bcwhite
Message-ID: <38B96301.677D11FE@pobox.com>
Date: Sun, 27 Feb 2000 12:46:41 -0500
From: Brian White <bcwhite@pobox.com>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: submit@bugs.debian.org
Subject: exim: delayed delivery of incoming messages
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Package: exim
Version: 3.03-4
Severity: wishlist

I'm having a problem running exim behind a slow modem.  When a large
volume of mail starts getting queued outbound, exim tries to deliver
each one immediately.  As a result, my poor, slow modem gets bogged down
with 20+ pieces of simultaneous (large) outgoing email and they almost
all fail.

My only recourse at the moment is to set the "deliver_load_max" to some
exceedingly tiny value such that immediate deliveries never happen.
Unfortunately, this means that no deliveries will happen until the
next 'runq' starts -- adding an average 7 minute delay to _all_ outbound
email.

An option like "max_simultaneous_deliveries" would solve this reasonably
nicely by forcing any additional messages to get put in the queue instead.
The "deliver_load_max" does not effectively measure the number of delivery
processes since they are all blocked behind the slow modem and thus are
not counted as "ready to run".  This option isn't an ideal solution, of
course, since those extra will get delivered only come the next 'runq'
instead of as soon as the current deliveries finish, but it would still
be a big improvement.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
               He who has infinite patience sees instant results.



Received: (at 59134-forwarded) by bugs.debian.org; 28 Feb 2000 19:45:35 +0000
Received: (qmail 26917 invoked from network); 28 Feb 2000 19:45:34 -0000
Received: from va.debian.org (mail@198.186.203.20)
  by master.debian.org with SMTP; 28 Feb 2000 19:45:34 -0000
Received: from anchor-post-34.mail.demon.net [194.217.242.92] 
	by va.debian.org with esmtp (Exim 2.05 #1 (Debian))
	id 12PW1o-00008x-00; Mon, 28 Feb 2000 11:40:24 -0800
Received: from aziraphale.demon.co.uk ([194.222.242.160])
	by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1)
	id 12PVzI-000F1C-0Y; Mon, 28 Feb 2000 19:37:49 +0000
Received: from mark by aziraphale.demon.co.uk with local (Exim 3.12 #1 (Debian))
	id 12PVrH-000187-00; Mon, 28 Feb 2000 19:29:31 +0000
Date: Mon, 28 Feb 2000 19:29:31 +0000
From: Mark Baker <mbaker@iee.org>
To: exim-users@exim.org
Cc: 59134-forwarded@bugs.debian.org
Subject: [bcwhite@pobox.com: Bug#59134: exim: delayed delivery of incoming messages]
Message-ID: <20000228192931.A4338@aziraphale.demon.co.uk>
Mail-Followup-To: exim-users@exim.org, 59134-forwarded@bugs.debian.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i

----- Forwarded message from Brian White <bcwhite@pobox.com> -----

Envelope-to: mark@aziraphale.demon.co.uk
Subject: Bug#59134: exim: delayed delivery of incoming messages
Reply-To: Brian White <bcwhite@pobox.com>, 59134@bugs.debian.org
Orignal-Sender: bcwhite
X-Debian-PR-Message: report 59134
X-Debian-PR-Package: exim
X-Debian-PR-Keywords: 
Date: Sun, 27 Feb 2000 12:46:41 -0500
From: Brian White <bcwhite@pobox.com>
X-Accept-Language: en
To: submit@bugs.debian.org

Package: exim
Version: 3.03-4
Severity: wishlist

I'm having a problem running exim behind a slow modem.  When a large
volume of mail starts getting queued outbound, exim tries to deliver
each one immediately.  As a result, my poor, slow modem gets bogged down
with 20+ pieces of simultaneous (large) outgoing email and they almost
all fail.

My only recourse at the moment is to set the "deliver_load_max" to some
exceedingly tiny value such that immediate deliveries never happen.
Unfortunately, this means that no deliveries will happen until the
next 'runq' starts -- adding an average 7 minute delay to _all_ outbound
email.

An option like "max_simultaneous_deliveries" would solve this reasonably
nicely by forcing any additional messages to get put in the queue instead.
The "deliver_load_max" does not effectively measure the number of delivery
processes since they are all blocked behind the slow modem and thus are
not counted as "ready to run".  This option isn't an ideal solution, of
course, since those extra will get delivered only come the next 'runq'
instead of as soon as the current deliveries finish, but it would still
be a big improvement.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
               He who has infinite patience sees instant results.

----- End forwarded message -----



<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Mark Baker &lt;mbaker@iee.org&gt;</code>:<br>
<code>Bug#59134</code>; Package <code>exim</code>.


debian-bugs-dist@lists.debian.orgMark Baker <mbaker@iee.org>

Subject: Bug#59134: [Exim] [bcwhite@pobox.com: Bug#59134: exim: delayed delivery of incoming messages]
Reply-To: Philip Hazel <ph10@cus.cam.ac.uk>, 59134@bugs.debian.org
Resent-From: Philip Hazel <ph10@cus.cam.ac.uk>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Mark Baker <mbaker@iee.org>
Resent-Date: Mon, 28 Feb 2000 21:03:14 GMT
Resent-Message-ID: <handler.59134.B59134.95177132521609@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 59134
X-Debian-PR-Package: exim
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 59134-bugs@bugs.debian.org id=B59134.95177132521609
          (code B ref 59134); Mon, 28 Feb 2000 21:03:14 GMT
Date: Mon, 28 Feb 2000 20:55:17 +0000 (GMT)
From: Philip Hazel <ph10@cus.cam.ac.uk>
To: Mark Baker <mbaker@iee.org>
cc: exim-users@exim.org, 59134-forwarded@bugs.debian.org, 
    Brian White <bcwhite@pobox.com>, 59134@bugs.debian.org
In-Reply-To: <20000228192931.A4338@aziraphale.demon.co.uk>
Message-ID: <Pine.SOL.3.96.1000228205028.23415G-100000@ursa.cus.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 28 Feb 2000, Mark Baker wrote:

> I'm having a problem running exim behind a slow modem.  When a large
> volume of mail starts getting queued outbound, exim tries to deliver
> each one immediately.  As a result, my poor, slow modem gets bogged down
> with 20+ pieces of simultaneous (large) outgoing email and they almost
> all fail.

As I keep saying, Exim was designed for online, well-connected hosts.
I'm amazed people use it in these other situations.

> My only recourse at the moment is to set the "deliver_load_max" to some
> exceedingly tiny value such that immediate deliveries never happen.

Why not set queue_only? 

> Unfortunately, this means that no deliveries will happen until the
> next 'runq' starts -- adding an average 7 minute delay to _all_ outbound
> email.

Or possibly queue_only_domains?

> An option like "max_simultaneous_deliveries" would solve this reasonably
> nicely by forcing any additional messages to get put in the queue instead.

Exim's processes are distributed. It just doesn't know how many 
simultaneous deliveries it is doing. If you want to control that, set 
queue_only, start queue runners every (say) 30s, and limit the maximum 
number of queue runners.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.




<strong>Acknowledgement sent</strong> to <code>Philip Hazel &lt;ph10@cus.cam.ac.uk&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Mark Baker &lt;mbaker@iee.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Philip Hazel <ph10@cus.cam.ac.uk>
Subject: Bug#59134: Info received (was [Exim] [bcwhite@pobox.com: Bug#59134: exim: delayed delivery of incoming messages])
Message-ID: <handler.59134.B59134.95177132521609.ackinfo@bugs.debian.org>
In-Reply-To: <Pine.SOL.3.96.1000228205028.23415G-100000@ursa.cus.cam.ac.uk>
References: <Pine.SOL.3.96.1000228205028.23415G-100000@ursa.cus.cam.ac.uk>
X-Debian-PR-Message: ack-info-maintonly 59134

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Mark Baker <mbaker@iee.org>

If you wish to continue to submit further information on your problem,
please send it to 59134@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 59134) by bugs.debian.org; 28 Feb 2000 20:55:25 +0000
Received: (qmail 21561 invoked from network); 28 Feb 2000 20:55:24 -0000
Received: from ursa.cus.cam.ac.uk (cusexim@131.111.8.6)
  by master.debian.org with SMTP; 28 Feb 2000 20:55:24 -0000
Received: from ph10 (helo=localhost)
	by ursa.cus.cam.ac.uk with local-smtp (Exim 3.13 #1)
	id 12PXCH-0006g7-00; Mon, 28 Feb 2000 20:55:17 +0000
Date: Mon, 28 Feb 2000 20:55:17 +0000 (GMT)
From: Philip Hazel <ph10@cus.cam.ac.uk>
To: Mark Baker <mbaker@iee.org>
cc: exim-users@exim.org, 59134-forwarded@bugs.debian.org, 
    Brian White <bcwhite@pobox.com>, 59134@bugs.debian.org
Subject: Re: [Exim] [bcwhite@pobox.com: Bug#59134: exim: delayed delivery of incoming messages]
In-Reply-To: <20000228192931.A4338@aziraphale.demon.co.uk>
Message-ID: <Pine.SOL.3.96.1000228205028.23415G-100000@ursa.cus.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 28 Feb 2000, Mark Baker wrote:

> I'm having a problem running exim behind a slow modem.  When a large
> volume of mail starts getting queued outbound, exim tries to deliver
> each one immediately.  As a result, my poor, slow modem gets bogged down
> with 20+ pieces of simultaneous (large) outgoing email and they almost
> all fail.

As I keep saying, Exim was designed for online, well-connected hosts.
I'm amazed people use it in these other situations.

> My only recourse at the moment is to set the "deliver_load_max" to some
> exceedingly tiny value such that immediate deliveries never happen.

Why not set queue_only? 

> Unfortunately, this means that no deliveries will happen until the
> next 'runq' starts -- adding an average 7 minute delay to _all_ outbound
> email.

Or possibly queue_only_domains?

> An option like "max_simultaneous_deliveries" would solve this reasonably
> nicely by forcing any additional messages to get put in the queue instead.

Exim's processes are distributed. It just doesn't know how many 
simultaneous deliveries it is doing. If you want to control that, set 
queue_only, start queue runners every (say) 30s, and limit the maximum 
number of queue runners.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.




Received: (at 59134-forwarded) by bugs.debian.org; 28 Feb 2000 20:55:25 +0000
Received: (qmail 21561 invoked from network); 28 Feb 2000 20:55:24 -0000
Received: from ursa.cus.cam.ac.uk (cusexim@131.111.8.6)
  by master.debian.org with SMTP; 28 Feb 2000 20:55:24 -0000
Received: from ph10 (helo=localhost)
	by ursa.cus.cam.ac.uk with local-smtp (Exim 3.13 #1)
	id 12PXCH-0006g7-00; Mon, 28 Feb 2000 20:55:17 +0000
Date: Mon, 28 Feb 2000 20:55:17 +0000 (GMT)
From: Philip Hazel <ph10@cus.cam.ac.uk>
To: Mark Baker <mbaker@iee.org>
cc: exim-users@exim.org, 59134-forwarded@bugs.debian.org, 
    Brian White <bcwhite@pobox.com>, 59134@bugs.debian.org
Subject: Re: [Exim] [bcwhite@pobox.com: Bug#59134: exim: delayed delivery of incoming messages]
In-Reply-To: <20000228192931.A4338@aziraphale.demon.co.uk>
Message-ID: <Pine.SOL.3.96.1000228205028.23415G-100000@ursa.cus.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 28 Feb 2000, Mark Baker wrote:

> I'm having a problem running exim behind a slow modem.  When a large
> volume of mail starts getting queued outbound, exim tries to deliver
> each one immediately.  As a result, my poor, slow modem gets bogged down
> with 20+ pieces of simultaneous (large) outgoing email and they almost
> all fail.

As I keep saying, Exim was designed for online, well-connected hosts.
I'm amazed people use it in these other situations.

> My only recourse at the moment is to set the "deliver_load_max" to some
> exceedingly tiny value such that immediate deliveries never happen.

Why not set queue_only? 

> Unfortunately, this means that no deliveries will happen until the
> next 'runq' starts -- adding an average 7 minute delay to _all_ outbound
> email.

Or possibly queue_only_domains?

> An option like "max_simultaneous_deliveries" would solve this reasonably
> nicely by forcing any additional messages to get put in the queue instead.

Exim's processes are distributed. It just doesn't know how many 
simultaneous deliveries it is doing. If you want to control that, set 
queue_only, start queue runners every (say) 30s, and limit the maximum 
number of queue runners.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.




Received: (at 59134-forwarded) by bugs.debian.org; 29 Feb 2000 14:04:50 +0000
Received: (qmail 6694 invoked from network); 29 Feb 2000 14:04:50 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
  by master.debian.org with SMTP; 29 Feb 2000 14:04:50 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
	by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
	id 12PnGF-0002PG-00; Tue, 29 Feb 2000 09:04:27 -0500
Sender: bcwhite
Message-ID: <38BBD205.550A2E98@pobox.com>
Date: Tue, 29 Feb 2000 09:04:53 -0500
From: Brian White <bcwhite@pobox.com>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Philip Hazel <ph10@cus.cam.ac.uk>
CC: Mark Baker <mbaker@iee.org>, 59134-forwarded@bugs.debian.org
Subject: Re: [Exim] [bcwhite@pobox.com: Bug#59134: exim: delayed delivery of   
 incoming messages]
References: <Pine.SOL.3.96.1000229123449.21541G-100000@ursa.cus.cam.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > The implementation of such a feature wouldn't involve much more than
> > a semaphore.  Apache, for example, uses a shared-memory scoreboard, but
> > that would be excessive in this case.
> 
> Er, how do you mean? Exim is cunningly (?) implemented so that its
> processes are highly independent, communicating only via shared files.
> It doesn't get involved in complicated things like semaphores. (Which I
> have no doubt are different in different Unixes.)

Semaphores are actually SYSv, so they're reasonably portable.  I suppose
they could always be compile-time enabled, too.  My (brief and
unresearched idea) was something like this...

    (process starts)

    // get semophore described by unique key "EXIM_KEY"
    union semid arg;
    semid = semget(EXIM_KEY,1,O_RDWR)

    // if we couldn't get it, create it
    if (semid < 0) {
	semid = semget(EXIM_KEY,1,IPC_CREAT|O_RDWR);
	if (semid < 0) fail;

	// initialize semaphore to maximum delivery processes
	arg.val = max_delivery_processes;
	result = semctl(semid,0,SETVAL,arg);
	if (result < 0) fail;
    }
    DeliverySemaphore = semid;

    (when it comes time to do a delivery)

    // try to lock the semaphore
    struct sembuf arg;
    arg.sem_num = 0;
    arg.sem_op  =-1;
    arg.sem_flg = IPC_NOWAIT;
    result = semop(DeliverySemaphore,&arg,1);

    // result tells if we should continue delivery or queue
    if (result < 0) {
	// delivery maximum reached -- queue it
    } else {
	// do delivery

	// tell semaphore we're done
	arg.sem_op  = 1;
	arg.sem_flg = 0;
	semop(DeliverySemaphore,&arg,1);
    }

    (continue on)

In essence, this tries to get a semaphore described by some unique key
"EXIM_KEY".  If it fails, it creates one and sets it's count to "max
delivery processes".  When delivery time comes, we attempt to lock the
semaphone non-blocking.  If the lock fails, then we've reached our maximum
count and should queue it.  Otherwise, proceed with delivery and then
unlock the semaphore.


> But wait. A dim bell is ringing. I've been round this loop once before..
> Ah yes. Have you noticed "serialize_hosts" in the smtp transport? Is
> this too large a sledgehammer for you? Or possibly the wrong
> sledgehammer, since it operates on a per-host rather than a total basis.
> It was implemented for a server with a slow link to a client, rather
> than the other way round.

It might be just fine because I forward everything to our ISP's smarthost.
If I add that smarthost to the "serialize_hosts" line, would that work?
What about "serialize_nets"?  Could I serialize the entire Internet that
way?  These would limit me to a single delivery process at any one time,
instead of being a configurable number, but that's okay with me.


> > Don't get me wrong...  I think Exim is a great MTA.  I love it's power
> > and configurability.  I'm just mentioning a potential feature that would
> > make it even better in a case such as mine.
> 
> Don't get me wrong either! I'm always happy to discuss and think about
> features that could be helpful to people. It's just that sometimes they
> sound as though they would require a lot of bending to implement.

<grin>  Been there!  Some ideas simply don't justify the work they would
take to implement them.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
         Only those who dare to fail greatly can ever achieve greatly.



Received: (at 59134-forwarded) by bugs.debian.org; 29 Feb 2000 14:32:55 +0000
Received: (qmail 26607 invoked from network); 29 Feb 2000 14:32:54 -0000
Received: from ursa.cus.cam.ac.uk (cusexim@131.111.8.6)
  by master.debian.org with SMTP; 29 Feb 2000 14:32:54 -0000
Received: from ph10 (helo=localhost)
	by ursa.cus.cam.ac.uk with local-smtp (Exim 3.13 #1)
	id 12Pnhg-0006yL-00; Tue, 29 Feb 2000 14:32:48 +0000
Date: Tue, 29 Feb 2000 14:32:48 +0000 (GMT)
From: Philip Hazel <ph10@cus.cam.ac.uk>
To: Brian White <bcwhite@pobox.com>
cc: Mark Baker <mbaker@iee.org>, 59134-forwarded@bugs.debian.org
Subject: Re: [Exim] [bcwhite@pobox.com: Bug#59134: exim: delayed delivery of    incoming messages]
In-Reply-To: <38BBD205.550A2E98@pobox.com>
Message-ID: <Pine.SOL.3.96.1000229142745.21541L-100000@ursa.cus.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 29 Feb 2000, Brian White wrote:

> Semaphores are actually SYSv, so they're reasonably portable.  I suppose
> they could always be compile-time enabled, too. 

Probably a good idea, since some of the wilder OS (e.g. GNU/Hurd) may 
not have them, I suppose. They do seem to be on some BSD systems (a 
quick check shows)O, however.

> My (brief and
> unresearched idea) was something like this...

Noted.

> It might be just fine because I forward everything to our ISP's smarthost.

Oh well, that's all right then. :-)

> If I add that smarthost to the "serialize_hosts" line, would that work?
> What about "serialize_nets"?  

It's a host list. You can put (masked) IP addresses in it if you like.

> Could I serialize the entire Internet that
> way?  

serialize_hosts = *

But that would just serialize each individual host.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Mark Baker &lt;mark@mnb.org.uk&gt;</code>:<br>
<code>Bug#59134</code>; Package <code>exim</code>.


debian-bugs-dist@lists.debian.orgMark Baker <mark@mnb.org.uk>

X-Loop: owner@bugs.debian.org
Subject: Bug#59134: exim: delayed delivery of incoming messages
Reply-To: "Adam D. Barratt" <debian-bts@adam-barratt.org.uk>, 59134@bugs.debian.org
Resent-From: "Adam D. Barratt" <debian-bts@adam-barratt.org.uk>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Mark Baker <mark@mnb.org.uk>
Resent-Date: Thu, 28 Jul 2005 13:33:15 UTC
Resent-Message-ID: <handler.59134.B59134.11225570254868@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 59134
X-Debian-PR-Package: exim
X-Debian-PR-Keywords: 
Received: via spool by 59134-submit@bugs.debian.org id=B59134.11225570254868
          (code B ref 59134); Thu, 28 Jul 2005 13:33:15 UTC
Received: (at 59134) by bugs.debian.org; 28 Jul 2005 13:23:45 +0000
Received: from mail0.avcosystems.co.uk [195.224.236.86] 
	by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
	id 1Dy8MT-00015u-00; Thu, 28 Jul 2005 06:23:45 -0700
Received: from lexx.avco ([192.168.0.1] helo=andromeda)
	by mail0.avcosystems.co.uk with esmtp (Exim 4.52 #1 (Debian))
	id 1Dy8Ly-0006rf-4r; Thu, 28 Jul 2005 14:23:14 +0100
Received: from 127.0.0.1 (AVG SMTP 7.0.338 [267.9.6]); Thu, 28 Jul 2005 14:23:13 +0100
Message-ID: <146f01c59377$81e99f50$eb00010a@andromeda>
From: "Adam D. Barratt" <debian-bts@adam-barratt.org.uk>
To: "Brian White" <bcwhite@pobox.com>,
	<59134@bugs.debian.org>
References: <38B96301.677D11FE@pobox.com>
Date: Thu, 28 Jul 2005 14:23:13 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-AVCO-Scan-Signature: 78f2efbd55f823e3c7a715c69d54c74c
Delivered-To: 59134@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level: 
X-Spam-Status: No, hits=-5.1 required=4.0 tests=BAYES_44,HAS_BUG_NUMBER,
	VALID_BTS_CONTROL autolearn=no version=2.60-bugs.debian.org_2005_01_02

package exim
tags 59134 + upstream wontfix
thanks

On Sunday, February 27, 2000 6:46 PM, Brian White <bcwhite@pobox.com> wrote:

> An option like "max_simultaneous_deliveries" would solve this
> reasonably nicely by forcing any additional messages to get put in
> the queue instead. The "deliver_load_max" does not effectively
> measure the number of delivery processes since they are all blocked
> behind the slow modem and thus are not counted as "ready to run".
> This option isn't an ideal solution, of course, since those extra
> will get delivered only come the next 'runq' instead of as soon as
> the current deliveries finish, but it would still be a big
> improvement.

Upstream development on exim 3 stopped over three years ago, and it is no
longer Debian's default MTA. The behaviour discussed in this bug report is
never going to change / be fixed in the Debian packages, so I'm tagging the
report to indicate that.

Regards,

Adam





<strong>Tags added: upstream, wontfix</strong>
Request was from <code>&quot;Adam D. Barratt&quot; &lt;debian-bts@adam-barratt.org.uk&gt;</code>
to <code>control@bugs.debian.org</code>. 


Received: (at control) by bugs.debian.org; 28 Jul 2005 13:23:45 +0000
From debian-bts@adam-barratt.org.uk Thu Jul 28 06:23:45 2005
Return-path: <debian-bts@adam-barratt.org.uk>
Received: from mail0.avcosystems.co.uk [195.224.236.86] 
	by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
	id 1Dy8MT-00015u-00; Thu, 28 Jul 2005 06:23:45 -0700
Received: from lexx.avco ([192.168.0.1] helo=andromeda)
	by mail0.avcosystems.co.uk with esmtp (Exim 4.52 #1 (Debian))
	id 1Dy8Ly-0006rf-4r; Thu, 28 Jul 2005 14:23:14 +0100
Received: from 127.0.0.1 (AVG SMTP 7.0.338 [267.9.6]); Thu, 28 Jul 2005 14:23:13 +0100
Message-ID: <146f01c59377$81e99f50$eb00010a@andromeda>
From: "Adam D. Barratt" <debian-bts@adam-barratt.org.uk>
To: "Brian White" <bcwhite@pobox.com>,
	<59134@bugs.debian.org>
References: <38B96301.677D11FE@pobox.com>
Subject: Re: Bug#59134: exim: delayed delivery of incoming messages
Date: Thu, 28 Jul 2005 14:23:13 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-AVCO-Scan-Signature: 78f2efbd55f823e3c7a715c69d54c74c
Delivered-To: control@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level: 
X-Spam-Status: No, hits=-5.1 required=4.0 tests=BAYES_44,HAS_BUG_NUMBER,
	VALID_BTS_CONTROL autolearn=no version=2.60-bugs.debian.org_2005_01_02

package exim
tags 59134 + upstream wontfix
thanks

On Sunday, February 27, 2000 6:46 PM, Brian White <bcwhite@pobox.com> wrote:

> An option like "max_simultaneous_deliveries" would solve this
> reasonably nicely by forcing any additional messages to get put in
> the queue instead. The "deliver_load_max" does not effectively
> measure the number of delivery processes since they are all blocked
> behind the slow modem and thus are not counted as "ready to run".
> This option isn't an ideal solution, of course, since those extra
> will get delivered only come the next 'runq' instead of as soon as
> the current deliveries finish, but it would still be a big
> improvement.

Upstream development on exim 3 stopped over three years ago, and it is no
longer Debian's default MTA. The behaviour discussed in this bug report is
never going to change / be fixed in the Debian packages, so I'm tagging the
report to indicate that.

Regards,

Adam





<strong>Reply sent</strong> to <code>Barry deFreese &lt;bddebian@comcast.net&gt;</code>:<br>
You have taken responsibility.


-t

MIME-Version: 1.0
X-Mailer: MIME-tools 5.420 (Entity 5.420)
X-Loop: owner@bugs.debian.org
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Barry deFreese <bddebian@comcast.net>
Subject: Bug#59134: marked as done (exim: delayed delivery of incoming 
 messages)
Message-ID: <handler.59134.D59134.120839560120301.ackdone@bugs.debian.org>
References: <1208382043.763835.16284.nullmailer@comcast.net>
 <38B96301.677D11FE@pobox.com>
X-Debian-PR-Message: closed 59134
X-Debian-PR-Package: exim
X-Debian-PR-Keywords: wontfix upstream
X-Debian-PR-Source: exim
Content-Type: multipart/mixed; boundary="----------=_1208395695-21394-0"

This is a multi-part message in MIME format...

------------=_1208395695-21394-0
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8


Your message dated Wed, 16 Apr 2008 17:40:43 -0400
with message-id <1208382043.763835.16284.nullmailer@comcast.net>
and subject line exim has been removed from Debian, closing #59134
has caused the Debian Bug report #59134,
regarding exim: delayed delivery of incoming messages
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


--=20
59134: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D59134
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

------------=_1208395695-21394-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at submit) by bugs.debian.org; 27 Feb 2000 17:46:09 +0000
Received: (qmail 19037 invoked from network); 27 Feb 2000 17:46:09 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
  by master.debian.org with SMTP; 27 Feb 2000 17:46:08 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
	by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
	id 12P7ll-0008Ut-00; Sun, 27 Feb 2000 12:46:13 -0500
Sender: bcwhite
Message-ID: <38B96301.677D11FE@pobox.com>
Date: Sun, 27 Feb 2000 12:46:41 -0500
From: Brian White <bcwhite@pobox.com>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: submit@bugs.debian.org
Subject: exim: delayed delivery of incoming messages
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Package: exim
Version: 3.03-4
Severity: wishlist

I'm having a problem running exim behind a slow modem.  When a large
volume of mail starts getting queued outbound, exim tries to deliver
each one immediately.  As a result, my poor, slow modem gets bogged down
with 20+ pieces of simultaneous (large) outgoing email and they almost
all fail.

My only recourse at the moment is to set the "deliver_load_max" to some
exceedingly tiny value such that immediate deliveries never happen.
Unfortunately, this means that no deliveries will happen until the
next 'runq' starts -- adding an average 7 minute delay to _all_ outbound
email.

An option like "max_simultaneous_deliveries" would solve this reasonably
nicely by forcing any additional messages to get put in the queue instead.
The "deliver_load_max" does not effectively measure the number of delivery
processes since they are all blocked behind the slow modem and thus are
not counted as "ready to run".  This option isn't an ideal solution, of
course, since those extra will get delivered only come the next 'runq'
instead of as soon as the current deliveries finish, but it would still
be a big improvement.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
               He who has infinite patience sees instant results.

------------=_1208395695-21394-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at 59134-done) by bugs.debian.org; 17 Apr 2008 01:26:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.4-bugs.debian.org_2005_01_02 
	(2006-07-26) on rietz.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=4.0 tests=BAYES_00,DATE_IN_PAST_03_06,
	DNS_FROM_RFC_POST,SUBJ_HAS_UNIQ_ID autolearn=no 
	version=3.1.4-bugs.debian.org_2005_01_02
Return-path: <bdefreese@comcast.net>
Received: from qmta07.westchester.pa.mail.comcast.net ([76.96.62.64])
	by rietz.debian.org with esmtp (Exim 4.63)
	(envelope-from <bdefreese@comcast.net>)
	id 1JmItd-0005Fp-7q
	for 59134-done@bugs.debian.org; Thu, 17 Apr 2008 01:26:41 +0000
Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20])
	by QMTA07.westchester.pa.mail.comcast.net with comcast
	id EL5t1Z0020SCNGk570GU00; Thu, 17 Apr 2008 01:24:59 +0000
Received: from comcast.net ([71.224.175.179])
	by OMTA09.westchester.pa.mail.comcast.net with comcast
	id ERRt1Z00D3sciBK3V00000; Thu, 17 Apr 2008 01:25:53 +0000
X-Authority-Analysis: v=1.0 c=1 a=h7--_groeaoA:10 a=ECxIkXgHcbUA:10
 a=xNf9USuDAAAA:8 a=4R3UzAt-SoKSjXdOBbcA:9 a=FU2Jw3VsHMYcqgDMxd8A:7
 a=gA4t5htGNQA5YkXD4QqwQeih0C4A:4 a=10sAvMsTeQkA:10
Received: (nullmailer pid 16285 invoked by uid 1000);
	Wed, 16 Apr 2008 21:40:43 -0000
From: Barry deFreese <bddebian@comcast.net>
To: 59134-done@bugs.debian.org
Subject: exim has been removed from Debian, closing #59134
Date: Wed, 16 Apr 2008 17:40:43 -0400
Message-Id: <1208382043.763835.16284.nullmailer@comcast.net>

Version: 3.36-18.2+rm

The exim package has been removed from Debian testing, unstable and
experimental, so I am now closing the bugs that were still opened
against it.

For more information about this package's removal, read
http://bugs.debian.org/420191 . That bug might give the reasons why
this package was removed, and suggestions of possible replacements.

Don't hesitate to reply to this mail if you have any question.

Thank you for your contribution to Debian.
Barry deFreese


------------=_1208395695-21394-0--



<strong>Notification sent</strong> to <code>Brian White &lt;bcwhite@pobox.com&gt;</code>:<br>
Bug acknowledged by developer.


-t

MIME-Version: 1.0
X-Mailer: MIME-tools 5.420 (Entity 5.420)
X-Loop: owner@bugs.debian.org
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Brian White <bcwhite@pobox.com>
Subject: Bug#59134 closed by Barry deFreese <bddebian@comcast.net> (exim 
 has been removed from Debian, closing #59134)
Message-ID: <handler.59134.D59134.120839560120301.notifdone@bugs.debian.org>
References: <1208382043.763835.16284.nullmailer@comcast.net>
 <38B96301.677D11FE@pobox.com>
X-Debian-PR-Message: they-closed 59134
X-Debian-PR-Package: exim
X-Debian-PR-Keywords: wontfix upstream
X-Debian-PR-Source: exim
Reply-To: 59134@bugs.debian.org
Content-Type: multipart/mixed; boundary="----------=_1208395695-21394-1"

This is a multi-part message in MIME format...

------------=_1208395695-21394-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"


This is an automatic notification regarding your Bug report
which was filed against the exim package:

#59134: exim: delayed delivery of incoming messages

It has been closed by Barry deFreese <bddebian@comcast.net>.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Barry deFreese <bddebi=
an@comcast.net> by
replying to this email.


--=20
59134: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D59134
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

------------=_1208395695-21394-1
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at 59134-done) by bugs.debian.org; 17 Apr 2008 01:26:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.4-bugs.debian.org_2005_01_02 
	(2006-07-26) on rietz.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=4.0 tests=BAYES_00,DATE_IN_PAST_03_06,
	DNS_FROM_RFC_POST,SUBJ_HAS_UNIQ_ID autolearn=no 
	version=3.1.4-bugs.debian.org_2005_01_02
Return-path: <bdefreese@comcast.net>
Received: from qmta07.westchester.pa.mail.comcast.net ([76.96.62.64])
	by rietz.debian.org with esmtp (Exim 4.63)
	(envelope-from <bdefreese@comcast.net>)
	id 1JmItd-0005Fp-7q
	for 59134-done@bugs.debian.org; Thu, 17 Apr 2008 01:26:41 +0000
Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20])
	by QMTA07.westchester.pa.mail.comcast.net with comcast
	id EL5t1Z0020SCNGk570GU00; Thu, 17 Apr 2008 01:24:59 +0000
Received: from comcast.net ([71.224.175.179])
	by OMTA09.westchester.pa.mail.comcast.net with comcast
	id ERRt1Z00D3sciBK3V00000; Thu, 17 Apr 2008 01:25:53 +0000
X-Authority-Analysis: v=1.0 c=1 a=h7--_groeaoA:10 a=ECxIkXgHcbUA:10
 a=xNf9USuDAAAA:8 a=4R3UzAt-SoKSjXdOBbcA:9 a=FU2Jw3VsHMYcqgDMxd8A:7
 a=gA4t5htGNQA5YkXD4QqwQeih0C4A:4 a=10sAvMsTeQkA:10
Received: (nullmailer pid 16285 invoked by uid 1000);
	Wed, 16 Apr 2008 21:40:43 -0000
From: Barry deFreese <bddebian@comcast.net>
To: 59134-done@bugs.debian.org
Subject: exim has been removed from Debian, closing #59134
Date: Wed, 16 Apr 2008 17:40:43 -0400
Message-Id: <1208382043.763835.16284.nullmailer@comcast.net>

Version: 3.36-18.2+rm

The exim package has been removed from Debian testing, unstable and
experimental, so I am now closing the bugs that were still opened
against it.

For more information about this package's removal, read
http://bugs.debian.org/420191 . That bug might give the reasons why
this package was removed, and suggestions of possible replacements.

Don't hesitate to reply to this mail if you have any question.

Thank you for your contribution to Debian.
Barry deFreese


------------=_1208395695-21394-1
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at submit) by bugs.debian.org; 27 Feb 2000 17:46:09 +0000
Received: (qmail 19037 invoked from network); 27 Feb 2000 17:46:09 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
  by master.debian.org with SMTP; 27 Feb 2000 17:46:08 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
	by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
	id 12P7ll-0008Ut-00; Sun, 27 Feb 2000 12:46:13 -0500
Sender: bcwhite
Message-ID: <38B96301.677D11FE@pobox.com>
Date: Sun, 27 Feb 2000 12:46:41 -0500
From: Brian White <bcwhite@pobox.com>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: submit@bugs.debian.org
Subject: exim: delayed delivery of incoming messages
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Package: exim
Version: 3.03-4
Severity: wishlist

I'm having a problem running exim behind a slow modem.  When a large
volume of mail starts getting queued outbound, exim tries to deliver
each one immediately.  As a result, my poor, slow modem gets bogged down
with 20+ pieces of simultaneous (large) outgoing email and they almost
all fail.

My only recourse at the moment is to set the "deliver_load_max" to some
exceedingly tiny value such that immediate deliveries never happen.
Unfortunately, this means that no deliveries will happen until the
next 'runq' starts -- adding an average 7 minute delay to _all_ outbound
email.

An option like "max_simultaneous_deliveries" would solve this reasonably
nicely by forcing any additional messages to get put in the queue instead.
The "deliver_load_max" does not effectively measure the number of delivery
processes since they are all blocked behind the slow modem and thus are
not counted as "ready to run".  This option isn't an ideal solution, of
course, since those extra will get delivered only come the next 'runq'
instead of as soon as the current deliveries finish, but it would still
be a big improvement.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
               He who has infinite patience sees instant results.

------------=_1208395695-21394-1--



Received: (at 59134-done) by bugs.debian.org; 17 Apr 2008 01:26:41 +0000
From bdefreese@comcast.net Thu Apr 17 01:26:41 2008
X-Spam-Checker-Version: SpamAssassin 3.1.4-bugs.debian.org_2005_01_02 
	(2006-07-26) on rietz.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=4.0 tests=BAYES_00,DATE_IN_PAST_03_06,
	DNS_FROM_RFC_POST,SUBJ_HAS_UNIQ_ID autolearn=no 
	version=3.1.4-bugs.debian.org_2005_01_02
Return-path: <bdefreese@comcast.net>
Received: from qmta07.westchester.pa.mail.comcast.net ([76.96.62.64])
	by rietz.debian.org with esmtp (Exim 4.63)
	(envelope-from <bdefreese@comcast.net>)
	id 1JmItd-0005Fp-7q
	for 59134-done@bugs.debian.org; Thu, 17 Apr 2008 01:26:41 +0000
Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20])
	by QMTA07.westchester.pa.mail.comcast.net with comcast
	id EL5t1Z0020SCNGk570GU00; Thu, 17 Apr 2008 01:24:59 +0000
Received: from comcast.net ([71.224.175.179])
	by OMTA09.westchester.pa.mail.comcast.net with comcast
	id ERRt1Z00D3sciBK3V00000; Thu, 17 Apr 2008 01:25:53 +0000
X-Authority-Analysis: v=1.0 c=1 a=h7--_groeaoA:10 a=ECxIkXgHcbUA:10
 a=xNf9USuDAAAA:8 a=4R3UzAt-SoKSjXdOBbcA:9 a=FU2Jw3VsHMYcqgDMxd8A:7
 a=gA4t5htGNQA5YkXD4QqwQeih0C4A:4 a=10sAvMsTeQkA:10
Received: (nullmailer pid 16285 invoked by uid 1000);
	Wed, 16 Apr 2008 21:40:43 -0000
From: Barry deFreese <bddebian@comcast.net>
To: 59134-done@bugs.debian.org
Subject: exim has been removed from Debian, closing #59134
Date: Wed, 16 Apr 2008 17:40:43 -0400
Message-Id: <1208382043.763835.16284.nullmailer@comcast.net>

Version: 3.36-18.2+rm

The exim package has been removed from Debian testing, unstable and
experimental, so I am now closing the bugs that were still opened
against it.

For more information about this package's removal, read
http://bugs.debian.org/420191 . That bug might give the reasons why
this package was removed, and suggestions of possible replacements.

Don't hesitate to reply to this mail if you have any question.

Thank you for your contribution to Debian.
Barry deFreese





<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Mark Baker &lt;mark@mnb.org.uk&gt;</code>:<br>
<code>Bug#59134</code>; Package <code>exim</code>.


debian-bugs-dist@lists.debian.orgMark Baker <mark@mnb.org.uk>

X-Loop: owner@bugs.debian.org
Subject: Bug#59134: Top tips for an accessible home
Reply-To: vaidya <furkan-etty{kin@txdirect.net>, 59134@bugs.debian.org
Resent-From: vaidya <furkan-etty{kin@txdirect.net>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Mark Baker <mark@mnb.org.uk>
Resent-Date: Tue, 29 Jul 2008 08:48:10 +0000
Resent-Message-ID: <handler.59134.B59134.121732125111187@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: followup 59134
X-Debian-PR-Package: exim
X-Debian-PR-Keywords: wontfix upstream
X-Debian-PR-Source: exim
Received: via spool by 59134-submit@bugs.debian.org id=B59134.121732125111187
          (code B ref 59134); Tue, 29 Jul 2008 08:48:10 +0000
Received: (at 59134) by bugs.debian.org; 29 Jul 2008 08:47:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.4-bugs.debian.org_2005_01_02 
	(2006-07-26) on rietz.debian.org
X-Spam-Level: **
X-Spam-Status: No, score=2.1 required=4.0 tests=BAYES_50,OPERAMAIL,
	RCVD_IN_SORBS_WEB autolearn=no 
	version=3.1.4-bugs.debian.org_2005_01_02
Received: from 65.146.46.84.ip.erdves.lt ([84.46.146.65] helo=[65.242.254.33])
	by rietz.debian.org with esmtp (Exim 4.63)
	(envelope-from <furkan-etty{kin@txdirect.net>)
	id 1KNkri-0002sq-Jt
	for 59134@bugs.debian.org; Tue, 29 Jul 2008 08:47:31 +0000
To: 59134@bugs.debian.org
From:   vaidya <furkan-etty{kin@txdirect.net>
Content-Type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Tue, 29 Jul 2008 11:48:46 +0300
Message-ID: <yi.vlvrwyzzktgmyi@dp18395nb>
User-Agent: Opera Mail/9.50 (Win32)

Cats attack, kill student
http://vonmulert-gartenbau.de/default.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/





<strong>Acknowledgement sent</strong> to <code>vaidya &lt;furkan-etty{kin@txdirect.net&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Mark Baker &lt;mark@mnb.org.uk&gt;</code>.


-t

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.420 (Entity 5.420)
Content-Type: text/plain; charset=utf-8
X-Loop: owner@bugs.debian.org
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: vaidya <furkan-etty{kin@txdirect.net>
Subject: Bug#59134: Info received (Top tips for an accessible home)
Message-ID: <handler.59134.B59134.121732125111187.ackinfo@bugs.debian.org>
References: <yi.vlvrwyzzktgmyi@dp18395nb>
X-Debian-PR-Message: ack-info 59134
X-Debian-PR-Package: exim
X-Debian-PR-Keywords: wontfix upstream
X-Debian-PR-Source: exim
Reply-To: 59134@bugs.debian.org


Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Mark Baker <mark@mnb.org.uk>

If you wish to submit further information on this problem, please
send it to 59134@bugs.debian.org, as before.

Please do not send mail to owner@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.


--=20
59134: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D59134
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems



Received: (at 59134) by bugs.debian.org; 29 Jul 2008 08:47:31 +0000
From furkan-etty{kin@txdirect.net Tue Jul 29 08:47:31 2008
X-Spam-Checker-Version: SpamAssassin 3.1.4-bugs.debian.org_2005_01_02 
	(2006-07-26) on rietz.debian.org
X-Spam-Level: **
X-Spam-Status: No, score=2.1 required=4.0 tests=BAYES_50,OPERAMAIL,
	RCVD_IN_SORBS_WEB autolearn=no 
	version=3.1.4-bugs.debian.org_2005_01_02
Return-path: <furkan-etty{kin@txdirect.net>
Received: from 65.146.46.84.ip.erdves.lt ([84.46.146.65] helo=[65.242.254.33])
	by rietz.debian.org with esmtp (Exim 4.63)
	(envelope-from <furkan-etty{kin@txdirect.net>)
	id 1KNkri-0002sq-Jt
	for 59134@bugs.debian.org; Tue, 29 Jul 2008 08:47:31 +0000
To: 59134@bugs.debian.org
Subject: Top tips for an accessible home
From:   vaidya <furkan-etty{kin@txdirect.net>
Content-Type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Tue, 29 Jul 2008 11:48:46 +0300
Message-ID: <yi.vlvrwyzzktgmyi@dp18395nb>
User-Agent: Opera Mail/9.50 (Win32)

Cats attack, kill student
http://vonmulert-gartenbau.de/default.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/