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@xxxxxxxxxx>; 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@xxxxxxxxxxxxxxxxxxxxxx> > for <fedora-list@xxxxxxxxxx>; 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@xxxxxxxxxx>; 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@xxxxxxxxxxxxxxxxxxxxxx> > for <fedora-list@xxxxxxxxxx>; 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.
