More info on posting delays

On Oct 16, 13:40, John Lawson wrote: As 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