whm@arizona.edu (Bill Mitchell) (10/12/87)
Increasingly often I've seen mail returned because sendmail's hop count was exceeded by a valid sequence of hops. As distributed on 4.3, the hop count (MAXHOP in conf.h) is 17 and I've seen a few sendmails that have a hop count of 15. Unfortunately, this isn't enough -- some Internet mail endpoints are more than 17 hops apart. I don't know that there's any solution for this other than to raise the hop count (which is non-trivial for binary-only sites).
thompson@dalcs.UUCP (Michael A. Thompson) (10/13/87)
If you use the vanilla paths from news articles then yes the hop count is liable to be too small, but if you use something like pathalias to construct mail paths or forward your mail to a smart mailer (i.e. one of the backbone sites) then a hop count of 15 should be sufficient. smail is a P.D. smart mailer available from a comp.sources.unix archive site that you could use instead of sendmail (I've never used it but from what I've heard it might solve you problem, pathalias is also available from the same source) -- Michael A. Thompson, Dept. Math, Stats, & C.S., Dalhousie U., Halifax, N.S. thompson@dalcs.uucp From Bitnet or Uucp thompson@cs.dal.cdn From Bitnet or Cdn thompson%dalcs.uucp@uunet.uu.net From Arpa
kyle@xanth.UUCP (Kyle Jones) (10/15/87)
[ Followups go to comp.mail.headers ] In article <2373@megaron.arizona.edu>, whm@arizona.edu (Bill Mitchell) writes: > Increasingly often I've seen mail returned because sendmail's hop count > was exceeded by a valid sequence of hops. As distributed on 4.3, the > hop count (MAXHOP in conf.h) is 17 and I've seen a few sendmails that > have a hop count of 15. Unfortunately, this isn't enough -- some Internet > mail endpoints are more than 17 hops apart. I don't know that there's > any solution for this other than to raise the hop count (which is non-trivial > for binary-only sites). I thought sendmail sources were available for everyone from ucbarpa.berkeley.edu. Is this no longer the case? Sendmail checks the hop count by noting the number of Received: headers in a message. One way to reduce the number of Received: headers is to compact them as a message moves from one organizational domain to the next. For example, suppose a message is delivered to megastron.arizona.edu with the following Received headers: Received: from nansen.ocean.odu.edu by xanth.cs.odu.edu with SMTP (5.51/odu-gateway) id AA24116; Wed, 14 Oct 87 21:04:25 EDT Received: from laplace.ocean.odu.edu by nansen.ocean.odu.edu with SMTP (5.51/odu-lanleaf) id AA00238; Wed, 14 Oct 87 21:04:07 EDT Received: from ICASE.ARPA by laplace.ocean.odu.edu with SMTP (5.51/odu-lanleaf) id AA03459; Wed, 14 Oct 87 21:03:45 EDT Received: by ICASE.ARPA (4.7/1.2a) id AA27641; Wed, 14 Oct 87 21:00:07 edt Before handing the message to sendmail, a program on megastron could crush thees headers down to: Received: from ICASE.APRA by odu.edu with SMTP id AA03459; Wed, 14 Oct 87 21:08:05 EDT Received: by ICASE.ARPA (4.7/1.2a) id AA27641; Wed, 14 Oct 87 21:00:07 edt This would stamp out the redundant information in the headers tacked on by hosts within the same organization. For such a program to be most effective, hosts would have to use the proper format for Received: headers (some don't). kyle jones <kyle@odu.edu> old dominion university, norfolk, va usa