On Oct 16, 13:40, John Lawson wrote:
> ----------------cut n paste----------------------------
>
> Received: from huey.classiccmp.org (huey.classiccmp.org
> [209.145.140.36])
> by mail3.panix.com (Postfix) with ESMTP
> id B220098214; Thu, 16 Oct 2003 13:00:45 -0400 (EDT)
> Received: from huey.classiccmp.org (localhost [127.0.0.1])
> by huey.classiccmp.org (8.12.8p1/8.12.8) with ESMTP id
> h9GGjaH5086939;
> Thu, 16 Oct 2003 11:45:38 -0500 (CDT)
> (envelope-from cctalk-bounces_at_classiccmp.org)
> Received: from linux.local ([128.195.166.138])
> by huey.classiccmp.org (8.12.8p1/8.12.8) with ESMTP id
> h9DIMuH3076162
> for <cctalk_at_classiccmp.org>;
> Mon, 13 Oct 2003 13:22:56 -0500 (CDT)
> (envelope-from tomj_at_wps.com)
> Received: by linux.local (Postfix, from userid 500)
> id A6B2C378DC; Mon, 13 Oct 2003 11:14:43 -0700 (PDT)
> From: Tom Jennings <tomj_at_wps.com>
> To: cctalk_at_classiccmp.org
> In-Reply-To: <200310131508.h9DF8gH5075481_at_huey.classiccmp.org>
>
>
> ------------end cut n paste-----------------
>
> I see there is quite a delay between two of the entries - 3 days.
As
> Arte Johnson used to say on Laugh-In: "Veeeeeeeery Eeeenteresting!"
But schtupid :-)
Those headers show that it took a few minutes to get tpo
huey.classiccmp.org (acting as receiver) -- that might be just mismatch
between the clocks -- and then 3 days to get to be forwarded (from the
same machine!). I've noticed a few headers with delays since we last
discussed this, but none quite as extreme! However, I can think of
some possible reasons.
In this case, I'd guess that for some reason (maybe the sender isn't
subscribed, or sent from an address that differs in some way from the
address he subscribed with) the message had to be moderated -- we rely
on Jay's goodwill and free time to do that, and if he's busy, I imagine
that he does the really obvious ones in batches where he doesn't really
need to examine them closely, and some get held over for a closer look
when time permits. He also has to sleep and eat sometimes!
In some other cases I've noticed, where the delay is a few hours, the
same reasoning might still apply, even to messages sent by a
subscriber. If you send to the list, and your headers give a different
username, hostname, or domainname than the one you used to subscribe,
it will need to be moderated.
Another possibility is that any kind of DNS lookup failure -- including
a slow response -- could cause the sending process on huey to requeue
the message. This happens a lot with people who use dynamic DNS
services and try to run their own mailserver on an ADSL line. They
forget that even though they can update the DNS within a few seconds
(or usually several minutes) when their IP address changes, most of the
rest of the world that's interested in them has already cached the old
data and it doesn't expire for a while (I've know it take days).
Yet another possibility right now, with all the viruses, and floods of
mail saying "we didn't deliver your mail because it had a virus and
we're too stupid to read the headers and see they're forged"[1] (not
mentioning AOL or certain other ISPs) is that some ISPs are finding
their mail servers swamped and hence slow. The ISPs that have suddenly
put virus-checking in place are particularly badly off, because the
scanning takes several times as many computrons as simple mail handling
does. huey might try to deliver a message and not be able to at some
particular instant, so it gets requeued. I've seen this happening on
our mailservers at work (we can easily handle what we're getting and
sending, but sometimes outgoing mail is queued because the recipient's
servers can't).
The above also happens a lot with ADSL users trying to run their own
servers, because right now some of them are getting hit with lots of
spam and virus-generated crap. However, that wouldn't explain why you
saw such a delay (since panix is not a little linux box on the end of a
DSL line).
[1] Several viruses currently forge the "From" line, making it seem
that email from some infected machine actually came from a different
user/machine. Easy to spot if you bother to look, but lots of people
-- even serious ISPs -- don't.
There are lots of other possibilites. Most mail transport agents, like
sendmail, have several built-in timeout functions, to cover various
eventualities. Sendmail has loads of them, mostly short, but the net
effect is that if some check or lookup takes too long, the associated
email is queued. Most MTAs only run the queues periodically (common
settings in sendmail are every 15 or 30 minutes) so you see that if
some recipient has some systematic problem (like bad/slow DNS, or being
hammered by DOS attacks or viruses) it doesn't take many delivery
attempts for the delay to mount up *for that recipient*. One I came
across the other day was that one sendmail was trying to do an ident
lookup on incoming mail. The ident protocol is an old and not very
useful way of trying to validate a sender's username; not many people
run ident daemons so if a recipient's server tries to do this
validation, it can take tens of seconds for it to decide it's not going
to get anywhere with it. Meanwhile, the sender may give up. Another
one I've seen, though not for a little while, is using an out-of-date
blackhole list -- depending on how the recipient server checks
blackhole lists, it might take a long time to decide whether to accept
a message, and meanwhile -- you guessed it -- the sender has given up
waiting and requeued the mail.
--
Pete Peter Turnbull
Network Manager
University of York
Received on Thu Oct 16 2003 - 19:06:44 BST