Xref: utzoo comp.mail.uucp:1583 comp.mail.headers:377
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!oliveb!sun!rose!nowicki
From: nowicki%rose@Sun.COM (Bill Nowicki)
Newsgroups: comp.mail.uucp,comp.mail.headers
Subject: Re: Real data to support my claim that '-d sun' is the way to go.
Message-ID: <63372@sun.uucp>
Date: 9 Aug 88 01:40:12 GMT
References: <3703@palo-alto.DEC.COM> <10139@g.ms.uky.edu> <3721@palo-alto.DEC.COM> <10141@g.ms.uky.edu>
Sender: news@sun.uucp
Lines: 72

In article <10141@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes:
> I am curious why nobody from Sun is here defending their honor.
> Yoo Hoo!  Anybody home at Sun?  Anybody wanna defend their sendmail
> configuration there?

Sure, we are home, but only have time to deal with Usenet flames about
once a week.  Most time is spent supporting paying customers. :-)

I realize that some people will NEVER be satisfied, but please try to
understand the problem from both sides. We rewrite "From:
sitename!user" into "From: sitename!user@Sun.COM" because we want to
comply with the Internet standards for domain names.  "sitename!user"
is NOT a valid domain name, nor is "user@sitename.UUCP".  The primary
standard that we support is the domain name system, and if you use
proper domain names then the From:  line should not normally be
touched.  However, all our internal names are converted into domain
format, and we have several gateways to the outside world to hide
internal complexity, so sometimes even if it LOOKS like a message is
sent from UUCP to UUCP, it often gets converted into domain format and
then back out again.

> I tried a test message to you at vixie!paul@sun.com just to see what
> would happen.  

It is not suprising.  We run standard (now System Vr3) UUCP software,
and do not do any routing of UUCP names.  So any mail to
site!user@Sun.COM will only work if the site is a direct UUCP
neighbor.  I have requested that we be taken out of the "d.Top" file as
a top-level domain router, in case that will help.  We already forward
several thousand mail messages per day between UUCP and the Internet,
so would not mind at all the reduction in traffic.

Unfortunately your claim that "all rewriting of From: lines is wrong"
is not correct unless EVERYONE is doing UUCP routing.  For example,
consider:

	siteA --uucp--> sun --uucp--> siteB

The From: line starts out as "From: siteA!user", and we rewrite it
as "From: siteA!user@Sun.COM", which then gets rewritten going out
as "From: sun!siteA!user".  The flamers are saying this is "RUDE".
But if we did NOT do it, then when the recipient at siteB replied
to the message, it would fail unless siteB were running UUCP routing
software.  Since the standard UUCP software from AT&T (AND BERKELEY!!)
DOES NOT support UUCP routing, this is usually not the case.  Thus we
try to be conservative, so that the recipient can reply if they do
UUCP routing or not. Since almost all of our mail is either directly
to us, or relayed through one hop, or relayed from all machines
that rewrite the header (i.e. standard Sun-issue software), we chose
to have a policy that causes these paths to generate replyable headers.

As you discovered, if you are NOT a direct UUCP neighbor of Sun,
but instead relay through a site that does NOT rewrite, e.g.:

	siteA --uucp--> siteB --uucp--> sun --Internet--> siteC

Then our scheme breaks down.  My response is that "siteB" is at fault,
since it did not rewrite the From: line as "siteB!siteA!user".  If it
did, then replies would work fine.  Another solution would be for siteA
to use a different path to the Internet.  We could just reject mail
relayed through these "non-rewriting" sites, and just do it for
neighbors.  Of course, we could also install the UUCP routing software,
but so far nobody has had the time to test, maintain, and document it.
If you can convince AT&T or Berkeley to put it in their releases, it
might help the situation.

Remember: just because YOU might run UUCP routing software, it does not
imply that everyone else is.

	-- Bill Nowicki
	   Sun Microsystems

(nothing official, of course, just personal opinions)