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 Arpakyle@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