From: "Nelson R. Pardee" > Too many hops error on Comcast.net persists. Wondering if there's anything > knew to be known on that? I didn't respond earlier because I thought there was a chance it was a short-term phenomenon, or my list's traffic was too recent to have kicked out the error yet. But if it's persisting on your list, there's something different happening. I have five subscribers receiving mail in the comcast.net domain, and I have seen no instance at all of this error. Traffic's been in a lull on that list, but there were four messages distributed on 10/7 and one yesterday, and if the problem affected all subscribers in the domain, I should have seen error reports by now. So it might be something peculiar to your list, or your subscribers. In the past, I have had such errors caused by this combination of circumstances: (1) A sender's email accumulates an unusual number of hops before escaping their home domain. (2) Our hosting domain added several hops into the list server, and back out. (3) The destination domain had multiple hops before delivery. The accumulation of Received: header trace entries sometimes exceeded limits in the destination domains. This is more likely because most equipment seems to ship with a default limit of 16 hops, whereas the later versions of email RFCs recommended limits around 100, because the IETF had realized that typical implementations were heading for an ugly confrontation with reality. One thing you could do--assuming you're subscribed to the list--is examine your own copies to see how many hops have accumulated at the point where the list email was transferred from your list server's domain to a destination domain. (I seem to have stopped seeing the problem because my host at the IEEE now tends to pass on the mail with only six or seven Received: entries, instead of 12 or 13.) Another thing you could do is check your list for comcast.net subscribers and determine whether this is affecting all of them or just a subset. I'm assuming you're getting error summaries rather than direct copies, and thus don't have any copies of the returned email headers. If you want to see actual headers, you could change your list's Auto-Delete setting from YES to NO. Depending on your traffic level and the severity of problems, you might find it necessary to change it back quickly (and all the error counts for individual subscriptions will probably be reset in the process, if that matters). But because you'll get copies of individual error reports instead of summaries, it may give you actual headers to study, which could reveal (a) how many hops the domain is allowing before bouncing the email, and (b) whether it actually gets forwarded in a loop before that happens. I have reviewed the responses from others, and I notice the only person confirming problems with Comcast was writing about a completely different issue. A blacklist should not be reported as "too many hops." Hal Keen ############################ To unsubscribe from the LSTOWN-L list: write to: mailto:[log in to unmask] or click the following link: http://peach.ease.lsoft.com/scripts/wa-PEACH.exe?SUBED1=LSTOWN-L&A=1