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