From xemacs-m  Fri Mar 14 10:42:57 1997
Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id KAA10809
	for <xemacs-beta@xemacs.org>; Fri, 14 Mar 1997 10:42:55 -0600 (CST)
Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1])
	by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA29628;
	Fri, 14 Mar 1997 11:42:45 -0500
Message-Id: <199703141642.LAA29628@black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Kyle Jones <kyle_jones@wonderworks.com>
cc: xemacs-beta@xemacs.org
Subject: Re: [comp.xemacs.xemacs]: forwarded message from Michael Uelschen 
In-reply-to: Your message of "Fri, 14 Mar 1997 10:49:02 EST."
             <QQcgvv19473.199703141549@crystal.WonderWorks.COM> 
From: Valdis.Kletnieks@vt.edu
Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="<Valdis.Kletnieks@vt.edu>"
X-URL: http://black-ice.cc.vt.edu/~valdis/
References: <QQcgvv19473.199703141549@crystal.WonderWorks.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 14 Mar 1997 11:42:45 -0500

On Fri, 14 Mar 1997 10:49:02 EST, you said:
> Xemacs produces
> 
> 	user@host.domain
> 
> It should be
> 
> 	user@domain
> 
> It seems to be a problem of xemacs-20.0. All other mailer I've tested
> (mail,elm,xemacs-19.13) worked correct.

OK.. Here's the quick and dirty executive summary.  What happens is this:

1) Most mailers hand it off to Sendmail with a 'From: userid'

2) The system's sendmail is configured to do "domain masquerading", and
if it sees a raw 'userid', it appends '@our.domain' to it.

3) XEmacs hands it to Sendmail with 'From: `getpwname()`@`gethostname()`
(more or less, you get the idea).

and then we have

4) The Sendmail is too broken to canonalize 'userid@our.FQDN.blat' back
down to 'userid' (usually because it fails to recognize its own hostname)
and therefor doesn't append the '@our.domain'.

Unfortunately, I've seen this same war with Naggum several times.  And
equally unfortunately, Naggum is actually "right" on this point - if I
remember correctly, he refuses to "fix" his code to deal with systems
that are too brain-dead to get their configs totally right, and the
fact that most other mailers are even stupider and therefor happen to
work is immaterial.

I have found that most of the offending systems are old SunOS boxen that
date back to the days when Sun didn't quite understand the concept
of a FQDN, and their stock sendmail.cf did a lot of concatenating
"hostname" to "domainname" and praying it would work.  Often, it did not,
because the Sun "domainname" wasn't exactly the same semantics and value
that /etc/resolv.conf uses....

Perhaps I'm just burnt out, being the postmaster of systems that deliver
about 500K+ messages a day, but I have *VERY* little sympathy for people
who complain "this one package doesn't work" but refuse to upgrade the
piece that's *really* at fault (their broken sendmail).

Try this analogy on the user - it's worked sometimes for me in the past:

Consider the stock broken sendmail as being a car that has a standard
transmission, but only first and second gear don't work.  As long as you
use software that only drives in first and second, you wont notice that
your transmission is shot.  However, installing XEmacs and thereby putting
the transmission in third gear, illustrates the problem.

Fix the transmission, not the driver.

/Valdis

-- 
				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech


