Re: delayed transfer of mail to Pine
On Wed, Feb 06, 2002 at 11:17:22AM -0800, Paul E Condon wrote:
> On Wed, Feb 06, 2002 at 10:53:39AM -0600, Mark S. Reglewski wrote:
> >
> > If you are using exim as your MTA, edit /etc/exim.conf and change the value
> > of smtp_accept_queue_per_connection to a sane value for your mail volume.
> > The default value is 10. For a smarthost set-up, I believe this is changed
> > to 100, which is way too low if you subscribe to active mail lists like
> > debian-user. What is happening is that exim is queueing everything over
> > 100 messages for later delivery.
> >
> > Either set the value to a very high number that will allow delivery of all
> > mails in one connection, or set it to zero to disable the feature.
> >
> I'm using fetchmail/exim/mutt (not pine). I looked at my exim.conf just now.
> I find that I have
>
> smtp_accept_queue_per_connection = 100
>
> but I have never noticed a delay in lots of mail showing up in mutt.
> I think there may be something else involved in Cheryl's problem, but I'm
> not sufficiently skilled at this to make an intelligent suggestion.
Interesting comment, Paul. First, a disclaimer, then my reply.
Disclaimer:
I am a complete and clueless Debian and Linux newbie. The only reason that I
ventured a reply to Cheryl's original query was that I recently encountered
exactly the same problem in setting up mail in Linux. I too run a setup of
mutt + fetchmail + exim, and have recently been poring over docs and
configuration files.
Reply:
After getting my mail setup going in Debian, I noticed emails being
delivered into my spool file index as I was working my mail in mutt. For a
couple of days I naturally thought that these were just messages being
pulled off my ISP's server by the fetchmail daemon. But by chance I noticed
that some of the deliveries were completely out of sync with fetchmail's
polling interval. I checked /var/log/exim/mainlog and discovered that any
messages in excess of 100 that were retrieved by fetchmail and passed to
exim were being queued for deferred delivery. So more study led me to the
/etc/exim.conf file, and the setting of smtp_accept_queue_per_connection.
So, it's possible that you have been seeing deferred message deliveries
without realizing it. If your smtp_accept_queue_per_connection is set to
100 and messages are *not* being queued, then I think you have a bug against
exim. Check your exim logs to see if you are experiencing deferred delivery
of messages in excess of 100. If so, you might want to edit your
/etc/exim.conf file along the lines I suggested earlier.
You could also do this: The next time you boot up, run fetchmail -c -v
to see how many messages are on your POP server before you actually invoke
fetchmail to retrieve them. Run tail -f /var/log/exim/mainlog in a terminal
window while fetchmail is retrieving your messages. You should see messages
in excess of 100 being queued in real time.
Of course, the acid test for Cheryl will be whether she gets all her
messages delivered in one connection the next time she invokes fetchmail
with 100+ messages on her mail server. I hope she will report success or
failure. If it's failure, then some mail guru will have to chime in, since
this clueless newbie is at the outer limits of his knowledge.
Cordially,
Mark S. Reglewski
Reply to: