🚀 go-pugleaf

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