Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!mailrus!tut.cis.ohio-state.edu!cwjcc!pirate!chet
From: chet@pirate.CWRU.EDU (Chet Ramey)
Newsgroups: comp.mail.sendmail
Subject: Re: Overlaying smail and mx-sendmail?
Message-ID: <99@cwjcc.CWRU.Edu>
Date: 30 Sep 88 15:38:51 GMT
References: <8602@shamash.UUCP>
Sender: news@cwjcc.CWRU.Edu
Reply-To: chet@pirate.CWRU.EDU (Chet Ramey)
Organization: CWRU Andrew R. Jennings Computing Center
Lines: 83

In article <8602@shamash.UUCP> jwabik@shamash.UUCP (Jeff Wabik) writes:
>I've heard from a number of people that there is a way to overlay smail
>onto mx-sendmail such that:
>
>	First address resolution happens via MX records;
>	Second address resolution happens via the pathalias database;
>	Third address resolution happens someplace else (like uunet 8^)
>
>Can someone tell me where to find documentation for this procedure?  If
>anyone has done this, what are your experiences with it?

We do something like this here, with sendmail 5.59 and smail 2.5.  We're
about to change the procedure to have IDA sendmail 5.59 do the pathalias
lookup directly, but we haven't gotten that far yet.

Here's basically how we do it (your mailer names may vary, an probably do):

1.  Make sure that the routine sendmail calls to canocicalize names queries
    for a class of T_ANY rather than T_CNAME.  If it gets an answer that is
    not a CNAME for a CNAME query it will use it, but there are name servers
    out there that won't send back an MX record in response to a CNAME query.
    This might require hacking on the sendmail source; the relevant routine
    from sendmail 5.59 is getcanonname() in domain.c.

2.  In ruleset 0 of your sendmail.cf, add a rule like this that asks the
    resolver if a host is in the name server:

	R$+<@$+>$*		$:$1<@[$ $2. $]>$3

    This tells sendmail to canonicalize the host name it's currently focusing
    on, with a dot appended.  If the host is found, the host name is rewritten
    and will lose the dot at the end.  We usually try this rule twice:

	R$+<@$+.>$*		$:$1<@[$ $2. $] >$3

    If the name server timed out, which happens often enough to make this
    worthwhile, we resubmit it to the resolver, again with a dot at the end
    as a sentinel.

    If it comes back from the canonicalization routine again with the dot 
    still at the end, the lookup failed, and we immediately resolve to 
    mailer=smail, ship it off to smail, and let smail resolve the host name
    to a uucp path (or whatever) and resubmit the mail to a `lower fork' of
    sendmail with a rule like this:

	R$+<@$+.>		$#smail$@$2$:$1

    Make sure you have an smail mailer definition somewhere in the sendmail.cf,
    and that smail is configured to send everything to sendmail, not attempt
    uux delivery itself.
    
    If, on the other hand, the hostname came back from the resolver without 
    the sentinel dot at the end, the lookup succeeded, and we know there is 
    an RR somewhere out there for this host, be it a CNAME, MX, A, or 
    whatever.  In this case, we can attempt direct delivery, since sendmail
    does MX lookup in the delivery routine.  A rule like this resolves to the
    `tcp' mailer, which attempts delivery via SMTP:

	R$*<@$+>$*		$#tcp$@$2$:$1@$2$3
				  ^     ^    ^
				  |     |    |
				mailer  |    |
				       host  |
					    user


We only do these two levels of hostname lookup and resolution, and rely on 
smail to send the mail to `smarthost' if it can't resolve the name based on 
pathalias database lookup.  This is where you could have your third level, 
and ship all unresolvable addresses off to UUNET.

This has worked pretty well for us so far, and we have been able to provide a 
mail system that allows our users to send mail virtually anywhere while still
delivering as much mail as we can via our Internet connection.

Chet Ramey
Andrew R. Jennings Computing Center, Case Western Reserve University
chet@cwjcc.CWRU.EDU


| Chet Ramey            chet@cwjcc.CWRU.EDU    chet@alpha.CES.CWRU.EDU
|
|		Just another jerk takin' pride in his work...