Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.mail.misc
Subject: Re: Which headers may Sendmail re-write?
Message-ID: <1990Dec18.182210.12980@Think.COM>
Date: 18 Dec 90 18:22:10 GMT
References: <1990Dec14.064837.8996@Latour.Sandelman.OCUnix.On.Ca> <1990Dec14.174541.14252@Think.COM> <276D13B4.6732@tct.uucp>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 47

In article <276D13B4.6732@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to barmar@think.com (Barry Margolin):
>> To: foo!bar!baz!user1, user2@quux.dom.ain
>>Further, assume the baz system is on the UUCP network, so only understands
>>UUCP bang-paths ...
>The primary fallacy in this line of reasoning is the assumption that a
>site reachable via UUCP cannot deal with RFC822 addresses.

Sorry, I should have said "and" instead of "so".  Many UUCP sites only
recognize bang paths.

>>Sendmail is an application-level protocol-translating gateway.  There
>>wouldn't be much controversy over an SMTP<->X.400 gateway munging headers;
>>it's an obvious part of the job.  Why do you expect less of a UUCP<->SMTP
>>gateway?
>
>Because UUCP is just a transport.  It doesn't have its own address
>format.  Common implementations of mail over UUCP use the bang path as
>an envelope format, but the From:, To:, etc. lines can all be
>RFC822-compliant without any tribble -- er, trouble -- at all.

UUCP is the name of a protocol *suite* (the transport layer protocols have
names like "UUCP g-protocol").  Yes, RFC822-compliant messages are included
in that suite, but there's no requirement that hosts using the UUCP mail
transfer protocol recognize such addresses.  They are expected to recognize
almost-RFC822 messages that use bang paths, and to transform such headers
en route (removing the current host from the beginning of destination
paths, and adding it to the beginning of other paths).

Part of the problem, of course, is that there is no precise specification
of the requirements of UUCP hosts.  The UUCP network is anarchistic, and
that's what allowed it to grow so rapidly.  But it also means that there is
an enormous variety of implementations and versions out there, and it is
frequently necessary to cater to common denominators.

A gateway with only a few UUCP neighbors could probably have a database
indicating which neighbors can handle RFC822 messages, and not mung the
headers when forwarding there.  But maintaining such a database for
backbone sites with many neighbors is probably more work than most system
administrators are willing to put up with (at many sites, support of the
UUCP gateway is not a high priority, and is only tolerated by management so
long as it doesn't impact the regular job).
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar