jwabik@shamash.UUCP (Jeff Wabik) (09/30/88)
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?
Thanks in advance ..
-Jeff
--
Jeff A. Wabik INTERNET: jwabik@shamash.cdc.com AT&T: +1 612 853 6811
____ ____ UUCP: {rosevax,umn-cs,bungia,ems}!shamash!jwabik
/ ___||___ \
| |___ ___| | Control Data Corporation - The quality goes in before
\____||____/ the OEM name comes off..
" .. and if by threatening me you think you can get me to be
your slave .. well.. that's where you're right .. "chet@pirate.CWRU.EDU (Chet Ramey) (09/30/88)
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...
parmelee@wayback.cs.cornell.edu (Larry Parmelee) (10/01/88)
Chet, In article <99@cwjcc.CWRU.Edu> you write: > 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. You need to be careful about the above method. In the 4.8 version of BIND (sendmail 5.59), a trailing dot is taken to indicate a rooted name. For example, if I lookup "devvax.tn" here, it changes into "devvax.tn.cornell.edu", but if I lookup "devvax.tn.", it fails, because the trailing dot tells the resolver routines that the name is to be looked up as if "tn" existed at the same level as "edu", "com", or "gov". -Larry Parmelee parmelee@cs.cornell.edu
chet@pirate.CWRU.EDU (Chet Ramey) (10/01/88)
In article <21448@cornell.UUCP> parmelee@wayback.cs.cornell.edu (Larry Parmelee) writes: Commenting on an earlier article of mine about sendmail's name canoncialization: >Chet, In article <99@cwjcc.CWRU.Edu> you write: >> 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. >You need to be careful about the above method. In the 4.8 version >of BIND (sendmail 5.59), a trailing dot is taken to indicate a >rooted name. For example, if I lookup "devvax.tn" here, it >changes into "devvax.tn.cornell.edu", but if I lookup "devvax.tn.", >it fails, because the trailing dot tells the resolver routines that >the name is to be looked up as if "tn" existed at the same level as >"edu", "com", or "gov". That's true, and is probably applicable for some situations that exist out there. However, here are a couple of comments about our situation, which is (obviously) what our sendmail.cf is tailored for: 1. You seem to be using a default domain for non-rooted lookups. We, for various reasons, do not. What we do do is ensure that each host in the CWRU.EDU domain has a globally unique name within that domain, and put in CNAME records as aliases for each of those names (e.g. CNAME cwjcc -> cwjcc.CWRU.EDU, CNAME alpha -> alpha.ces.cwru.edu, and so on). This way our users (most of whom are pretty unsophisticated) can get the benefits of just having to remember user@host for on-campus mail, even if the host is a member of a subdomain. I think this is basically what you are doing, you're just going about it a different way. My feeling is that what we are doing is The Right Way To Go, at least for this campus. 2. I don't think there's an easier way to do name canonicalization at the sendmail.cf (mailer, host, user) resolution level, and it's very important that we send as much mail as we can out via our Internet connection. I also don't think that people should treat subdomains as part of the host name, which is, in essence, what you are doing above. Of course, that's probably just personal preference (it's all or nothing). Chet Ramey chet@cwjcc.CWRU.EDU | Chet Ramey chet@cwjcc.CWRU.EDU chet@alpha.CES.CWRU.EDU | | Just another jerk takin' pride in his work...
ane@hal.UUCP (Aydin "Bif" Edguer) (10/01/88)
In article <104@cwjcc.CWRU.Edu> chet@pirate.UUCP (Chet Ramey) writes: >In article <21448@cornell.UUCP> parmelee@wayback.cs.cornell.edu (Larry Parmelee) writes: >>Chet, In article <99@cwjcc.CWRU.Edu> you write: >>>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. >>You need to be careful about the above method. In the 4.8 version >>of BIND (sendmail 5.59), a trailing dot is taken to indicate a >>rooted name. For example, if I lookup "devvax.tn" here, it >>changes into "devvax.tn.cornell.edu", but if I lookup "devvax.tn.", >>it fails, because the trailing dot tells the resolver routines that >>the name is to be looked up as if "tn" existed at the same level as >>"edu", "com", or "gov". The reason for the dot is to be able to distinguish a successful lookup (which should go via tcp) and a failed lookup (which should be tried by smail). If you must resolve devvax.tn, and if devvax.tn. is not resolved to devvax.tn.cornell.edu then you have a couple of options. 1) Play with sendmail source to have the have the resolver try all host names with cornell.edu appended, if the first lookup fails. (HARDER THAN NECESSARY) 2) Simply resolve all names first before resolving them with a dot appended. This means having two rules: R$+<@$+>$* $:$1<@$[$2$]>$3 R$+<@$+>$* $:$1<@$[$2.$]>$3 (Please note that Chet made a typing error, the correct rule is $[...$] NOT [$...$].) So devvax.tn will be resolved to devvax.tn.cornell.edu in the first step and then devvax.tn.cornell.edu. will be resolved to devvax.tn.cornell.edu in the second step. (EASY) Sendmail is your friend. Always play with your friends first. :-) Aydin Edguer
woods@ncar.ucar.edu (Greg Woods) (10/05/88)
In article <8602@shamash.UUCP> jwabik@shamash.UUCP (Jeff Wabik) writes: > > First address resolution happens via MX records; > Second address resolution happens via the pathalias database; > Third address resolution happens someplace else (like uunet 8^) > ....to which several people responded with the answer that you can tack a dot onto the end of the address, pass it through the resolver via the $[ $] canonical name lookup feature, and check for the presence or absence of the dot afterwards to indicate resolver success or failure. When Paul Vixie first pointed this out to me, I was quite excited about the possibility of having the best of both worlds. However, when I implemented it I discovered a very serious problem with doing this. Namely, if your name server returns a temporary failure, the message will bounce if the domain in the address is not in the UUCP maps (which is happening more and more often these days as Internet-connected sites begin depending more and more on the resolver and less and less on static tables like UUCP maps, as well they should). Yes, you can PARTIALLY alleviate this by repeating the resolve attempt in case the name server times out, but if the timeout is due to some network problem (such as the gateway between your local net and the rest of the Internet is down), then the second attempt will also time out, resulting in addresses that work most of the time but sometimes bounce. Needless to say, this can be very confusing for the users. This is not to say that you absolutely shouldn't do this procedure, but you should be aware of this behavior first. In a user community such as ours, that includes lots of users that are barely computer literate, variable behavior of the mail system will cause too many headaches, so I have had to abandon the idea of implementing this hack here. In an environment with fewer users, or where the average level of mail expertise among the users is higher than it is here, this might work well. But be aware of implementing a mail system that behaves differently with the same address under different network states. --Greg
chet@pirate.CWRU.EDU (Chet Ramey) (10/06/88)
In article <810@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: >In article <8602@shamash.UUCP> jwabik@shamash.UUCP (Jeff Wabik) writes: >> >> First address resolution happens via MX records; >> Second address resolution happens via the pathalias database; >> Third address resolution happens someplace else (like uunet 8^) >> [Discussion about the $[ $] construct in sendmail] >However, when I implemented it I discovered a very >serious problem with doing this. Namely, if your name server returns a >temporary failure, the message will bounce if the domain in the address is >not in the UUCP maps (which is happening more and more often these days as >Internet-connected sites begin depending more and more on the resolver >and less and less on static tables like UUCP maps, as well they should). If the name server is trying to resolve a name on behalf of sendmail, this name (assuming it is not local; I would guess that this is not your problem) should be fully-qualified with a domain. If we go with this basic assumption, then my response below should be valid. >Yes, you can PARTIALLY alleviate this by repeating the resolve attempt >in case the name server times out, but if the timeout is due to some network >problem (such as the gateway between your local net and the rest of the >Internet is down), then the second attempt will also time out, resulting >in addresses that work most of the time but sometimes bounce. When the name server times out, and you send it to smail, smail should resolve it to a path regardless of whether or not it can find that particular machine in the maps. There are published gateways to .EDU, .COM, .GOV, etc. If smail is configured right, it should try, for the host name host.organization.top-level, 1) host.organization.top-level 2) a gateway to .organization.top-level 3) a gateway to .top-level Since the gateways exist to all the top-level domains (or they should), smail should always resolve to some path. Whether this path also goes across the Internet is a matter for the maps. (At least this is the way I remember smail working -- Ed Rynes handles the smail part of our mail system; I handle sendmail). Also, the top-level domain gateways are assumed to handle such mail correctly. Even if smail fails totally on resolution, you can have it set up to punt everything either back to sendmail (preserving the non-smail behavior) or to a smart host like uunet. >Needless to >say, this can be very confusing for the users. This is not to say that you >absolutely shouldn't do this procedure, but you should be aware of this >behavior first. True. It does not affect our users as much as yours; ours seem to be a little more computer literate (which makes my job a little easier than yours, I would think). >In a user community such as ours, that includes lots of users >that are barely computer literate, variable behavior of the mail system will >cause too many headaches, so I have had to abandon the idea of implementing >this hack here. In an environment with fewer users, or where the average >level of mail expertise among the users is higher than it is here, this might >work well. But be aware of implementing a mail system that behaves differently >with the same address under different network states. Well, even a vanilla Internet mail system will behave differently under different network states -- for example, a mail delivery system is supposed to try all possible MX records for a given host, so if the primary MX forwarder for a host is down, the mail will go to the next forwarder in the preference list. (Sendmail does not do this -- at least, I've seen mail in the queue for a site whose primary forwarder is unreachable, but whose secondary forwarders are reachable (I have a program that lists all MX forwarders for a given host, so it's easy to verify).) But then, that's neither here nor there, as long as the mail gets delivered. What system do you use that guarantees delivery? In my opinion, using sendmail and smail this way gives a higher probability of delivery than just using one or the other. >--Greg Chet chet@cwjcc.CWRU.EDU | Chet Ramey chet@cwjcc.CWRU.EDU chet@alpha.CES.CWRU.EDU | | Just another jerk takin' pride in his work...
woods@ncar.ucar.edu (Greg Woods) (10/07/88)
In article <118@cwjcc.CWRU.Edu> chet@cwjcc.CWRU.EDU (Chet Ramey) writes: >Even if smail fails totally on resolution, you can have it set up to punt >everything either back to sendmail (preserving the non-smail behavior) ....and creating an infinite loop, >or to a smart host like uunet. I don't want to do that (although I could). The problem with doing that, from my point of view, is that if our name server fails for temporary reasons, it is normally because we are cut off from the outside world for some reason. In that case, I won't be able to transmit the mail to a smarter host (if there is such a thing; my goal is to be a "smart host" myself) until the net comes back on line anyway. At that point my server query would succeed, but if the mail is already queued for uunet, then we will have to deliver it there (and via the slow NSFnet/ARPA gateways, no less) and as a result the mail will take longer to get to it's destination after the net comes back online than it would have if it had gotten queued due to a host name lookup failure. >Well, even a vanilla Internet mail system will behave differently under >different network states -- for example, a mail delivery system is supposed to >try all possible MX records for a given host, so if the primary MX forwarder >for a host is down, the mail will go to the next forwarder in the preference >list. Well, yes, but this "different" behavior doesn't look any different to the user sending the mail, and THAT is what counts. >What system do you use that guarantees delivery? I do use sendmail and smail both, but not quite in this way. What I have is a small static table of domains that are in the UUCP maps but either do not have name servers that I can find or connect to, or else the UUCP route is better than the MX route (and a third type, actually, which is domains that we *are* the mail exchanger for). Examples of the second type are pyramid.com, whose mail exchanger is sun.com to which we have a notoriously bad connection (I think they are over on the ARPA side of the ARPA/NSFnet gateways), but the UUCP route is ames!pyramid, and we have a direct NASA Science Net link to ames which is a very GOOD connection, or nbi.com whose mail exchanger is uunet but we have a direct local phone call link to nbires, their domain gateway host. If the domain isn't in this table, it gets handed off to the resolver software. I am currently engaged in some research to determine just how many domains (if any) are reachable by UUCP but cannot (for whatever reason) be found in the domain name system. I will post my results to the net when I get done. What I am basically doing is taking every line in the pathalias output database that has a dot in it, stripping off the name (first) field, and handing that to the name server for MX- and A-record lookups. The shell script that did this ran for over 17 wall clock hours on a Sun-4 and produced 375 pages (23000 lines) of hared-copy output. This includes all domains and sub- domains that appear in the UUCP maps. Whether my scheme is a good one or not depends a lot on how many domains there are that are unresolvable that can be reached by UUCP. My guess is, not many, but I will have more definitive numbers soon. --Greg
allbery@ncoast.UUCP (Brandon S. Allbery) (10/13/88)
As quoted from <810@ncar.ucar.edu> by woods@ncar.ucar.edu (Greg Woods): +--------------- | ....to which several people responded with the answer that you can tack a dot | onto the end of the address, pass it through the resolver via the $[ $] | canonical name lookup feature, and check for the presence or absence of the | dot afterwards to indicate resolver success or failure. When Paul Vixie first | pointed this out to me, I was quite excited about the possibility of having | the best of both worlds. However, when I implemented it I discovered a very | serious problem with doing this. Namely, if your name server returns a | temporary failure, the message will bounce if the domain in the address is | not in the UUCP maps (which is happening more and more often these days as | Internet-connected sites begin depending more and more on the resolver | and less and less on static tables like UUCP maps, as well they should). +--------------- It seems to me that if the mailer depends on a network service like a name server, and the name server returns a non-permanent error, sendmail's proper response should be to queue the message and retry until either the server comes back up or the message has waited for some configurable time; i.e. the response to the nameserver being down should be the same as the destination system returning a *temporary* error condition upon actual delivery. Something for the folks working on the IDA pathalias lookup to consider: the same thing should happen if the pathalias database is in the process of being rebuilt. Or am I missing something? ++Brandon -- Brandon S Allbery uunet!hal.cwru.edu!ncoast!allbery allbery%ncoast@hal.cwru.edu (LAST RESORT ONLY: allbery@uunet.uu.net) DELPHI: ALLBERY comp.sources.misc is moving off ncoast -- please do NOT send submissions direct "So many articles, so little time...." -- The Line-Eater
cfe+@andrew.cmu.edu (Craig F. Everhart) (10/14/88)
You're correct in that a temporary-failure result from the resolver should
result in requeueing a piece of mail for a later delivery attempt, and this is
indeed how things work when it's sendmail doing the resolver calls (e.g.
looking for MX records or A records to do the actual connection). The only
silly thing is in the $[ $] interface itself; all that happens is that sendmail
makes an attempt to canonicalize the name. (The as-distributed version of the
underlying C routine doesn't even return a success or failure code.) That is,
there's no way that the person writing the sendmail.cf file (in which the $[ $]
appear) can determine whether the resolver call succeeded or failed, and if it
failed, whether it was a transient or permanent failure. The hack of adding
the ``.'' and seeing if it stayed around is only an attempt to determine if the
resolver call succeeded at all, and confounds the resolver's use of a sequence
of ``default domain suffixes''. Nobody has yet invented a mechanism whereby
the sendmail.cf program can query the result of the resolver call--except for
perhaps the IDA sendmail kit.
You might argue that sendmail should look at the result of the
get-canonical-name routine and handle some of the failures itself; you could
argue that if it were to get a temp failure on any $[ $]-spawned resolver call,
that it should bypass sending to this addressee for now and move on to the
next. Maybe that's reasonable. Is that what the existing sendmail.cf
files/programs expect to happen? Should all $[$] requests be assured of
working before trying the first delivery? (What happens if a
partially-qualified domain name escapes *your* site?) How should sendmail deal
with permanent failures--by rejecting the address as invalid? Hardly. Might
there be an answer to all these questions?
Craig Everhart
Andrew message system