[comp.mail.sendmail] MAXHOPS

hubert@cac.washington.edu (Steve Hubert) (11/09/90)

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.  These were a combination of mailing
lists in mailing lists and forwards and so on.  I'm not worried about cases
like this failing now and then, but it did make me think that maybe it is
time to raise the value of MAXHOPS in the next version of sendmail so that
this is fixed before it becomes a real problem.

Steve Hubert
Networks and Distributed Computing, Univ. of Wash., Seattle
hubert@cac.washington.edu

rickert@mp.cs.niu.edu (Neil Rickert) (11/09/90)

In article <10811@milton.u.washington.edu> hubert@cac.washington.edu (Steve Hubert) writes:
>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.  These were a combination of mailing
>lists in mailing lists and forwards and so on.  I'm not worried about cases
>like this failing now and then, but it did make me think that maybe it is
>time to raise the value of MAXHOPS in the next version of sendmail so that
>this is fixed before it becomes a real problem.

 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.  Supporting this interpretation is the
encouragement in RFC1123 do avoid source-routing, and mail direct.

 I suspect this is mostly a problem of mailing lists which are being expanded
too many times, and perhaps should be taken as an indication that the mailing
list needs some reorganization.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

brian@ucsd.Edu (Brian Kantor) (11/10/90)

In article <1990Nov8.230931.15216@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
> I suspect this is mostly a problem of mailing lists which are being expanded
>too many times, and perhaps should be taken as an indication that the mailing
>list needs some reorganization.

I STRONGLY suggest that this is taking the wrong approach to the problem
of bulk distribution of electronic messages.

One of the main reasons we developed the NNTP was to use it and the
associated news software to REPLACE mailing lists.  All you have to do
is create a newsgroup and shove the traffic into it.

There are MANY top-level distributions that are NOT mainstream USENET,
are NOT hamstrung by its group creation "voting" guidelines, and they
ARE carrying a lot of former mailing-list traffic.

It's working.  Now all we need to do is to get more site administrators
to go for it.

For example, we take ONE subscription to each of many mailing lists
here at UCSD, then use NNTP to distribute them as 'mail.XXX' groups
among several hundred workstations and multiuser systems on campus with
a potential readership of over 5,000.  That way, we don't have hundreds
of people subscribing to a group and the resulting hundreds of copies
of mail arriving.

On a more global scale, most of the BITNET mailing lists are available
worldwide as bit.* newsgroups, and we recieve those as well.  Most of
them had at least one subscriber here at UCSD already;  now they don't
have to arrive as mail at all.  That's a potential savings of a LOT of
traffic.  Since we're already handling well over 12,000 messages a day,
I'd like to reserve the immediacy of e-mail for correspondence, not for
bulk distribution.  NNTP lets me do that.

	Brian Kantor	UCSD Postmaster
		UCSD Network Operations
		UCSD C-024, La Jolla, CA 92093-0124 USA	
		brian@ucsd.edu	BRIAN@UCSD ucsd!brian

Craig_Everhart@TRANSARC.COM (11/10/90)

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