Test, No reply Necessary

[James Wilkinson]

Bob Chiodini wrote:
> I'm having difficulty posting to the list from my ISP, Bellsouth.
> Posting at work indicated no problems, but posting through Bellsouth has
> been delayed by in one case over 30 hours.  Usually it averages between
> two and three hours.
> 
> I've posted the headers to their tech support, but seem to getting
> "robotic" answers suggesting it's my email client.  Right!

I know you said "no reply necessary", but I'm going to reply to
illustrate what the problem is.

Taking certain e-mails of yours...

> Received: from imf04aec.mail.bellsouth.net (imf04aec.mail.bellsouth.net
>         [205.152.59.52])
>         by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id k056G4jE018073
>         for <fedora-list at redhat.com>; Thu, 5 Jan 2006 01:16:32 -0500
> Received: from ibm66aec.bellsouth.net ([67.34.137.95])
>         by imf23aec.mail.bellsouth.net with ESMTP id
>         <20060104222554.CWCM2507.imf23aec.mail.bellsouth.net at ibm66aec.bellsouth.net>
>         for <fedora-list at redhat.com>; Wed, 4 Jan 2006 17:25:54 -0500

You read from the bottom up. The time zone is the same in both cases. It
takes nearly eight hours to get between imf23aec.mail.bellsouth.net,
imf04aec.mail.bellsouth.net, and Red Hat.

Another example:
> Received: from imf10aec.mail.bellsouth.net (imf10aec.mail.bellsouth.net
>         [205.152.59.58])
>         by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k074L4Fr025106
>         for <fedora-list at redhat.com>; Fri, 6 Jan 2006 23:21:05 -0500
> Received: from ibm56aec.bellsouth.net ([67.34.137.95])
>         by imf16aec.mail.bellsouth.net with ESMTP id
>         <20060107002809.MYGU3957.imf16aec.mail.bellsouth.net at ibm56aec.bellsouth.net>
>         for <fedora-list at redhat.com>; Fri, 6 Jan 2006 19:28:09 -0500

This time the delay is four hours, and it's at the same stage.

A quick review of your other e-mail shows a delay at the same stage. I
think we can rule out clocks being too far wrong, since when you send
via NASA, the message gets through nearly immediately, and all
timestamps are consistent.

So either it's a problem in that imfxxaec.mail.bellsouth.net step, or
one between Bell South and Red Hat.

I understand Red Hat have implemented "greylisting". This means that
when the Red Hat e-mail server first receives a connection from a
particular server for and from particular e-mail addresses, the Red Hat
server sends a "try again later" message. If the sending server cares
enough to actually try again later, it's taken to be a valid e-mail.
Real e-mail servers all do this: nearly all spamming engines don't.

A number of list members have reported that this is a very effective
technique in stopping spam without permanently rejecting real e-mail.

One problem is when a *different* server retries later. The
"greylisting" code thinks this is a different attempted e-mail, and
sends the "try again later" message again. It looks like Bell South have
a number of servers that send out e-mail: it's possible that a different
server is chosen to try each time. In that case, Bell South keep getting
"try again later" messages until they try sending the message with a
server that's already tried sending it.

When your e-mail comes via NASA, the same server can retry if necessary.
That server probably gets put on a "believed OK" list since it always
retries promptly.

I don't know, but I'd imagine it likely that the pattern of "a few
messages are retried, but not all" from the Bell South servers looks
dodgy to the Red Hat servers. So Bell South are always greylisted by Red
Hat.

If this is the case, then it would be Red Hat that would need to fix the
problem: either by "whitelisting" the Bell South servers, or treating
them all as the same computer. You might get more luck e-mailing the
list master and asking him to get in touch with the Red Hat sysadmins.

Hope this helps,

James.

-- 
E-mail address: james | Who knows what evil lurks in the database?
@westexe.demon.co.uk  |     -- The megahal program, trained on my quote file.