Did anybody get sendmail to work outside thier local domain?

[Vernon Schryver]

In article <910329220904 at wraith.netops.contel.com>, powell at wraith.netops.contel.com (Mike Powell "CFS Net Ops") writes:
>
> Subject: Re: Did anybody get sendmail to work outside thier local domain?
>...

Consider sgi.com, a 4D220 without graphics.  MX-forwards for several
domains, including **.sgi.com and some UUCP sites with no other business or
other relationship with Silicon Graphics.

> ...
> I undertand this is the way SGI operates because of there necessity to
> operate in an isolated environment....

There are thousands of machines within the sgi.com domain with many
subdomains around the world.  They are do not have direct IP links the
greater Internet, and most use special hostnames ("relay.blah.sgi.com") to
forward instead of MX.  Most people here type "user at do.main" to send mail
to BITNET, CSNET, DNS-Internet, UUCP, and other places.  Do you consider a
machine "isolated" in such a soup?

It is possible to take the standard sendmail.cf from the tape, change the
lines you are directed to in the comments, and have the result talk to
random SMTP and UUCP machines.  The sendmail.cf on sgi.com as well as many
of the thousands of internal machines is very similar to that on the tapes.
That similarity is an advantage to customers of having the SGI engineering
organization run sgi.com instead of the corporate MIS organization.

NOTE: failing to set the F and D macros as directed in the first 33 lines
of the shipped sendmail.cf probably caused the problems in contel.com.

There is also an MX version of sendmail on sgi.com available for FTP.
Sendmail in the next release does MX.


Engineers here rarely say anything about sendmail problems, because
sendmail.cf is a complete programing language.  When someone writes "what
has to be changed to make sendmail work?", they are asking the equivalent
"how do you write hello world if you don't like page 7 in K&R?"  Debugging
other people's sendmail.cf is even less fun than debugging their C.

The classic way to debug sendmail problems is mentioned in Eric Allman's
"SENDMAIL Installation and Operation Guide," which is (or has been) shipped
within the SGI "Mail Referencec Manual", doc. 007-0880-010.  
Condensed:
    1. start `/usr/lib/sendmail -C/usr/lib/sendmail.cf -bt`
	and type "0 user at foo.bar.com" (or 3,0 user at foo.bar.com" in newer
	versions) to send the address thru ruleset 0.

	Note the -C is needed unless you refreeze after every trail change
	and you change the running sendmail.cf.  Not recommended.

	Notice the first "ruleset 0 returns", and note the string after "$#".
	That will be the "mailer".  "Local" means deliverly will be
	attempted to a local user of that name.  Find the line in
	sendmail.cf that starts "Mmailer" and note the "S=xx" and "R=yy"
	lines.

	If sendmail continuing babblering rewrite stuff forever, you have
	written an infinite loop.  (Remember that sendmail.cf is a full
	programming language.)

	If it is not obvious why it went from one rule set to another, add
	lines in interesting places to send the current string to a
	non-existent rule set.  In other words, copy the line containing
	">27" in the SGI standard sendmail.cf to interesting places.  (Of
	course, remove the comment character.)  Then re-run your test and
	watch what is sent to 27.

    2. After the right mailer is being choosen, run the contents of
	sample To: and From: lines thru the Sender and Receipient rules,
	by typing something like "3,1,xx,4 foob at bar" or "3,2,xx,4 foob at bar"
	to `sendmail -bt`, where "xx" or "yy" were noted above..

    3. after repeating the preceding steps until blood stops coming out
	of your ears, try a test message by running 
	`/usr/lib/sendmail -v user at foo.bar.com` as a mail user agent.

    4. use other techniques as required, including `telnet hostname 25`
	followed by "help"


Vernon Schryver,   vjs at sgi.com