Interactive 2.2 problems

Jack F. Vogel jackv at turnkey.tcc.com
Thu Jul 5 04:53:56 AEST 1990


In article <382 at denwa.uucp> jimmy at denwa.info.com (Jim Gottlieb) writes:
>* I told mailmgmt that we have both TCP/IP and UUCP connections and
>  that I want to use smail, but only if an address ends in .UUCP does
>  it send it to smail.  Otherwise, it fails with a name look-up error.
>  Did someone at Interactive think that all UUCP addresses end in
>  .UUCP?  I'm not a sendmail guru so I don't know how to fix this.
 
Sendmail internally takes any uucp-style "bang" address and converts it
to  a .UUCP in ruleset 3 so I don't think this is the problem. I should
say that I am not using the new Interactive sendmail or smail since I
have the pathalias patches to sendmail such that it does the lookup
itself, thus eliminating the need for smail. However I have looked over
the cf files that they supplied and the problem is in how they have
integrated smail usage. The rules in ruleset 0 that resolve to the uucp
mailer look as follows:

	R<@$=V.UUCP>:$+		$#uucp$@$1$:$2		@host.UUCP:...
	R$+<@$=V.UUCP>		$#uucp$@$2$:$1		user at host.UUCP

The problem with this is that the token $=V means that only hosts in class
V will match and if you look elsewhere you will find that this is those
sites listed in your Systems file. Therefore if you use smail as your
uucp mailer its whole purpose in life is shortcircuited, only sites you
already know about are ever passed to smail! One possible way to remedy
this is to change the rules to look as follows:

	R<@$+.UUCP>:$+		$#uucp$@$1$:$2		@host.UUCP:...
	R$+<@$+.UUCP>		$#uucp$@$2$:$1		user at host.UUCP

Now any host.UUCP will be passed to smail and let it do its job. Of course,
in my opinion, putting pathalias lookup direct into sendmail is far cleaner,
maybe if enough customers clammor for this we can get ISC to put in the
patches and distribute an update :-}.

On the matter of the name-lookup failure keep in mind that 5.61 sendmail
to its core is designed to work with the nameserver, if you are running
a network I would strongly suggest considering running named. Of course,
the problem then is you need both a sendmail guru AND a nameserver guru :-}.

>*  When local mail is sent, 'rmail -i username' is invoked.  The mail
>   is properly delivered but the process never dies, so ps shows tons
>   of 'rmail's lying around.
 
Sounds to me like someone screwed with your cf file since the ones that I
pulled off the distribution disks don't call rmail for local delivery, they
call lmail. rmail should never be used for such a purpose it is the uucp
mail delivery agent, also since supposedly the new rmail is just the BSD
code I have no idea what the '-i' is, the Berkeley code recognizes no 
such flag. Change your local mailer definition as follows:

	Mlocal, P=/bin/lmail, F=lsDFMhumS, S=10, R=20, A=lmail -s $u

>As far as mail is concerned, I can't figure out why vendors never seem
>to be able to get it right.  It's the one facility that almost every
>Unix system user uses and yet it is screwed up more often than not.  It
>must be given a real low priority.
 
Sorry, but I have to take issue with this sentiment. If one delivers a
simple-minded mail package, say like what SCO used to provide with Xenix
then it might make sense, but then we know what everybody does with that
mailer, right :-}. When you provide something as flexible and sophisticated
as sendmail there just is no way that it can be configured "out of the box"
correctly for everyone. It is like uucp, it just has to be configured for
the local site requirements and that will inevitably take some amount of
knowledge on the administrators part. ISC has at least attempted to make
things easier by providing 3 different prototype cf files, and BTW these
are very close to what Berkeley distributes so its not like they went and
broke something.

Well, anyway, if I can be of further assistance on your problems send me
some email and I will see what I can do.

Disclaimer: These sendmail meanderings are my responsiblity, not my employer's

-- 
Jack F. Vogel			jackv at locus.com
AIX370 Technical Support	       - or -
Locus Computing Corp.		jackv at turnkey.TCC.COM



More information about the Comp.unix.i386 mailing list