At 11:38 AM 4/2/97 -0500, Russ wrote:
>Forgive my ignorance here, but I frequently get lots of messages
>indicating mail failures due to too many hops. I recently decided that I
>would remove these subscribers, but rather than doing it quietly I
>figured I would send them notification. Since the unsubscribe
>notifications wouldn't cause too many hops I figured they would get
>there and people would see that they had been unsubscribed.
>
>Anyway, most of the people whom I removed were not thrilled that I had
>done so. Seems they have been receiving the list messages, despite their
>apparent failure according to the bounce messages I've been getting.

They were probably getting some but not all of the messages.  I can
see why they were not thrilled, since it's something completely out
of their control (although I got one of my own ISP's to raise the
limit, which only helps at the very end -- the last hop).

>My question is, what does an error message indicating too many hops
>really mean. I know it means that the SMTP server feels there have been
>too many re-routings in the message header, but does it mean it didn't
>get delivered? Is it just a warning?

No, it's the end.  It's a way of attempting to catch mail loops.
It refers to the number of "Received:" headers on the message.
One is added at each relay point ("hop") for the mail.  So if
somebody has two accounts and accidentally has A forward mail to B,
and B forward mail to A, you can picture what would happen unless
there's some way of stopping it.

There's a relatively common sendmail default of 17 hops max.
It can be (and should be) raised, since now we're seeing much more
diverse routing that involves perhaps a few hops at the sender's
end, a few at the receiver's end, and I've seen as many as ten
within the listserv backbone alone.  Sometimes, extra hops occur when
mail needs to be directed around an outage, as well.

>Finally, is there some way to hide the confirmation process within the
>header of outgoing messages? Currently there are 8 Received: lines which
>account for the steps each message must go through from coming in from
>the poster to getting delivered to the first subscriber SMTP server (see
>the headers below).

Well, you can't hide it (I don't think) but is that really your goal?
What I think you and/or problem subscribers want to do is eliminate
some of the Received: headers.  To accomplish this, you (and/or they)
can set them to SHORTHDR, and they will only get the Received: headers
coming out of listserv; the ones going in will be stripped.  This
should be many fewer.  It's also a useful option for people tight on
disk space.  I don't run a moderated list, so I don't know whether
the Received: headers in the approval loop will be eliminated or not,
but I'd guess they'd be stripped.

I strongly recommend against globally changing the *whole* list to that,
however.  Some will want full headers (I like them as a spam-hater).
Others, if you're on 1.8c, will want SUBJECTHDR (which, alas, is
incompatible with SHORTHDR.  <sniff>  Eric, pleeeze?  :-) .

[snip]

>Apart from reconfiguring how my machines are designated, any suggestions
>as to how I can reduce the number of hops a message takes within my
>control?

You can't reduce the hops, but SHORTHDR will remove some of the
Received: headers, hopefully enough that the bounces will stop.
As I said before, this removes origination information, so it should
be used with caution, knowing this will happen.

The random user who just wants to discuss the topic of the list
probably won't care what's in their headers, and SHORTHDR will do
just fine for those users (except those who want SUBJECTHDR).

The listowner him/herself should probably always get FULL or IETF
headers on at least one copy somewhere, on general principles.

Cheers,
Stan