[comp.mail.sendmail] ucbarpa's sendmail config

dheller@cory.Berkeley.EDU (Dan Heller) (01/10/89)

In article <697@utkcs2.cs.utk.edu> moore@cygnusx1.cs.utk.edu (Keith Moore) writes:
>Moral: throw out that /usr/lib/sendmail that came from your CPU vendor and
>use the one from ucbarpa.berkeley.edu.

I'm curious about something.  This config file is used all over berkeley,
as it is at many other sites.  Sometimes, when mail is sent out or when
mail is routed thru said machine, the name-server might fail and your
hostname is not expanded correctly into the fully qualified domain.

The result is the recipient gets mail that says something like:
    From: dheller@cory
As opposed to
    From: dheller@cory.Berkeley.EDU

Many times, I mail to people and they can't reply because "cory" doesn't
make sense (cuz it's not qualified).

The same problem happens when I mail to people at Santa Cruz Operation.
"sco" talks to ucscc.ucsc.edu, so I address the mail:
    To: sco!user@ucscc.ucsc.edu
but when ucsc gets the message, sometimes (when the name server fails to
get info about "ucscc") it rejects the mail with the error:
    ucscc.ucsc.edu: I refuse to talk to myself.

So,  the bottom line is, is it possible to configure a sendmail.cf file
so that if a hostname lookup or a name server lookup fails, it can be
replaced by a known/preset value so that mail can continue to work as
it should.
Dan Heller	<island!argv@sun.com>

karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (01/11/89)

dheller@cory.Berkeley.EDU (Dan Heller) writes:
   [ucbarpa's sendmail.cf can sometimes cause From: not to be
   fully-qualified.]
   So, the bottom line is, is it possible to configure a sendmail.cf file
   so that if a hostname lookup or a name server lookup fails, it can be
   replaced by a known/preset value so that mail can continue to work as
   it should.

Yes, it's easy, a piece o' cake, no problem.  I have never seen
ucbarpa's sendmail.cf, but I have seen Sun's and Ultrix' and a few
others, and I gagged in horror at all of them.  We abandoned the
vendor-supplied .cf files ages and ages ago, and I maintain ours by
hand.  (Now other people gag in horror at mine. :-)

A few months ago, I went stark, raving mad in S3 and S0, and induced
our .cf to be extremely aggressive in its beliefs about the proper
nature of domains and all sorts of related things.  Any piece of mail
coming through here which could possibly give the impression of being
within our domain is forcibly rewritten as such.  This has had a few
negative effects; I've gotten several pieces of mail from sites which
advertise only From: user@OneWordHostName, without a FQDN.  When such
a thing hits my .cf, it is rewritten as user@$D, justified by the fact
that, within my domain, any OneWordHostName must necessarily exist
within $D in order to be reachable as such.  Therefore, in line with
my desire to hide individual hostnames entirely, I obliterate it,
replacing it with $D.

Ultimately, an address gets near the end of S3 with the potential for
not having been taken care of by the above sorts of rules.  So my S3
ends like this (after some intervening stuff taking care of a lot of
deeply weird special cases):

# Final cleanup: Make sure it's bracketed and @ified.
R$+<$*>$*		$@$1<$2>$3		already <>'d; leave be
R$+@$*			$@$1<@$[$2$]>		already @ified; add <>
R$+			$@$1<@$D>		u => u@domain

The final line is what makes sure that outbound mail always has the
Right Thing.  $D in my case is cis.ohio-state.edu, so it's guaranteed
to leave a reasonable FQDN in the right places.  If I weren't hiding
hostnames, I would probably use $w or $w.$D or somesuch.

Now, all this mucking about in .cf is a good time (it leaves you with
just the right twisted outlook on life :-), but the very need to do
such things is evil personified.  Smail 3.x removes these sorts of
problems, and it will do Good Things for the world.

--Karl

PS- FQDN == fully-qualified domain name.