🚀 go-pugleaf

In article <11-PCNews-124beta@pos.pub.uu.oz.au>, Mark.Purcell@pos.pub.uu.oz.au (Mark Purcell) writes:
> jwt@duke.cs.duke.edu (Jeffrey W. Tannehill @ Duke University Computer Science Dept.; Durham, N.C.) once wrote....
> >
> >	When receiving mail via a uucp connection our mail software modifies 
> >the "Reply-To:" header on the message.  For example, the header 
> >
> >	Reply-To: testuser@testhost.testdomain.test
> >
> >may be modified to be:
> >
> >	Reply-To: hornet!duke!testhost.testdomain.test!testuser
> 
> I find it a real pain in the ass the way some uucp sites will take a FQDN 
> and modify
> it into a mess of UUCP addressing, which may or may not make sense at the
> other end.  Usually they don't make any sense.  So <replying> to mail
> does not work, amongst other problems.
> 
> It's bad enough when sites munge the From: line but there is a saving
> grace which is the Reply-To: header which most will not munge.  But if that
> starts getting changed then there is really no hope for mail getting back.
> 
> I am of the opinion that if an address if a FQDN that it shouldn't be UUCP
> munged as a FQDN should make sense from anywhere :-).


Well, it would be nice if FQDN's worked everywhere.  Unfortunately,
the root servers don't respond very quickly over UUCP links.


A UUCP gateway necessarily must translate from whatever is happening on
the Internet to whatever is right in the connected UUCP world.

That necessarily means rewriting all addresses appropriately.  In some
UUCP worlds, only !-paths work.  In other UUCP worlds, machine
understand FQDN's.  Reasonable Internet-UUCP gateways re-write FQDN's
or not depending on whether the other end understands FQDN's.  Years
ago, I found it necessary to to assume the other end does not do FQDN's
unless told otherwise.  More recently, it has been effective to assume
FQDN's are understood unless bounces are seen.

Sendmail, for example, does not distinguish between Reply-To: and
From:  It sends them through the same re-write rules, and has since
version 5.39, 85/01/05, according to version.c.


Vernon Schryver,  vjs@sgi.com