Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!ucbvax!TRANSARC.COM!Craig_Everhart
From: Craig_Everhart@TRANSARC.COM
Newsgroups: comp.mail.sendmail
Subject: Re: MAXHOPS
Message-ID: <QbCmM8r0BwwOFHC1xq@transarc.com>
Date: 9 Nov 90 21:56:24 GMT
References: <1990Nov8.230931.15216@mp.cs.niu.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 56

Excerpts from netnews.comp.mail.sendmail: 8-Nov-90 Re: MAXHOPS Neil
Rickert@mp.cs.niu.e (1448)

> >We've actually had a couple recent cases of "legitimate" addresses that
> >went through more than 17 hops and were returned.  They were legitimate
> >in the sense that they would have eventually reached the address if the
> >value of MAXHOPS had been higher....

>  I find this suggestion quite confusing.  The growth of the Internet, and
> the growing number of hosts with MX addresses who are only 1 or 2 hops of
> the network would seem to imply that the typical number of hops is
> decreasing, not increasing. ...

I believe that what's happening is that the number of transport agents
that are adding Received: lines is increasing, in addition to the
general Internet/internet growth and addition of multiple other nets. 
Another prevalent trend is that as companies come to terms with e-mail,
they tend to centralize mail service so that they have some measure of
access control.  More control means more hops.

For that matter, I think RFC 1123 doesn't discourage source-routing
because it's no longer necessary, but rather because lots of agents
couldn't deal with full-blown source routes.  They might recommend that
routes not be used, but they're pragmatic enough to recognize the %-hack
and its buddies.

I agree with the first poster (Steve Hubert) that a maximum count of 17
Received: headers is a low bound that keeps legitimate mail from being
delivered.

As an aside, I removed the sendmail code that counts Received: headers
entirely from the sendmail that I've been maintaining, in favor of a
different scheme that avoids forwarding loops.  Unfortunately for some,
that other scheme is in AMDS (part of Andrew, in X.V11R4), rather than
in sendmail.  It works real well, though.  In the transport agent
({andrew}/ams/delivery/trymail/strong.c in the distribution):
    - for each message delivered, it records in an NDBM database the
    message-ID (or resent-message-ID) and the destination address, as
    well as the then-current time;
    - before delivering any message, it checks to see if that message-ID
    () had been delivered to that destination address, and if so, shunts
    the message to a low-priority postmaster in-folder;
    - before forwarding a message that has no message-id (or
    resent-message-id if that's what's warranted), add one to it.
    - every day, the NDBM database is purged of entries more than 4 days old.

The only false firings have been bogus Message-ID fields, most of which
are trapped by simple syntactic checks on the Message-id field text.  Of
course, when J. Random User decides to make up his/her own mail user
agent, and guesses wrong for the message-ID format, they can't much help
but to lose.

One other nice attribute of this scheme is that it gets rid of other
silly duplicate mail as well.

		Craig