gnu-arch-users
[Top][All Lists]
Advanced

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

[Gnu-arch-users] Slow mailinglist, DNS problems?


From: Jan Harkes
Subject: [Gnu-arch-users] Slow mailinglist, DNS problems?
Date: Thu, 21 Aug 2003 23:24:55 -0400
User-agent: Mutt/1.5.4i

Hi,

I've noticed that the new mailinglist seems to be very lagged. I'll add
the headers from Tom's latest post as an example.

    Received: from monty-python.gnu.org ([199.232.76.173]) by cs.cmu.edu
            id aa28574; 21 Aug 2003 22:40 EDT
    Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org)
            by monty-python.gnu.org with esmtp (Exim 4.20)
            id 19q1ce-0005Yd-14
            for address@hidden; Thu, 21 Aug 2003 22:25:52 -0400
    Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20)
            id 19q0CC-00060Y-09
            for address@hidden; Thu, 21 Aug 2003 20:54:28 -0400
    Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20)
            id 19pzJ1-0007gM-L7
            for address@hidden; Thu, 21 Aug 2003 19:57:59 -0400
    Received: from [65.234.195.45] (helo=morrowfield.regexps.com)
            by monty-python.gnu.org with esmtp (Exim 4.20) id 19ptbg-00006x-1u
            for address@hidden; Thu, 21 Aug 2003 13:52:20 -0400

As we can see the email was sent around 2pm this afternoon, but didn't
leave the mail server until almost 11pm. A nine hour lag is really
excessive.

Now if we look at where the significant delays are introduced, the
spam-scan takes about 6 hours, tdma-scan 1 hour, list processing 30
minutes and final delivery 15 minutes. All nice multiples of 15 minutes,
so I assume that exim is configured to only queue email and runs
approximately once every 15 minutes.

The long delays could be explained by having one or more bad nameservers
listed in /etc/resolv.conf. The spam-scan is probably trying to look up
the sender's domain in several RBL lists etc. Having a local caching
nameserver (bind/pdns/dnsmasq) should speed that up considerably and
drop the roundtrip time down to just over 1 hour, avoiding the
batch-wise processing (or removing some of those intermediate steps)
should bring it even further down.

Jan





reply via email to

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