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