🚀 go-pugleaf

From article <.B.+58C@splut.conmicro.com>, by jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard):
> UUPC/Extended shows an excessively narrow attitude about reply
> addresses. Not every system - especially the UUCP systems that
> UUPC/Extended would talk - has an Internet address. A friend has a
> system running UUPC/Extended and cannot reply to mail sent to him from
> another system directly connected to mine - it INSISTS on trying to
> respond to jantor.conmicro.com, which doesn't work. Any attempt to
> reply to a message sent via the bang path gets thrown out, even though
> the bang path is valid and working/ Why does it do this? If it's apolicy
> decision, it maked UUPC/Extended nearly unusable; if it's a bug, it's a
> nasty one. Please fix it.

I think you need an entry in the HOSTPATH file.   This overrides routing
for all but directly connected hosts.  You could probably even load it
with a modified pathalias output if you tried hard.

Please note that the topic addressed in MY case was that I personally
refuse to decipher .sig files to choose an address to reply to mail; I
spent my $35 and got my domain registered and got myself into the maps
so I people can find me.  

I need to know where it gets the bad address from, and where it should
get the good address from.  Given that and the name of the systems, I
can tell you (as a public example) what goes in there.  Send me sample
mail with all the headers intact.  It is not only looking at the RFC-822
address, but also doing short circuit routing on the path if in the from
address; clearly, something is a tad screwed up.  

I love bug reports ... better you find it than me.  Then I can fix it
for both of us ... mail them to help@kendra.kew.com.

Note:	UUPC itself only supported one mail server; given that I wrote 
	the new router from scratch to handle mostly RFC-822 mail and I
	can't test bang paths easily, I'm amazed it works at all.  :-)

Drew