Hamilton.ES@PARC-MAXC.ARPA (Bruce Hamilton) (02/28/84)
It seems like every few days lately I try to reply to somebody, and the address on their "From" or "Reply-To" is phony. Maybe we have no right to expect usable return addresses from Usenet and CSNet (although I would contest even that premise), but certainly places like Columbia and CMU (to name two places where this has happened to me) ought to be able to munge any headers they fling out onto the Arpanet to reflect a valid Arpanet address, and NOT some bogus internal network address. Xerox's Grapevine software is very clever this way, so that insiders don't have to wade through @PARC-MAXC.ARPA, but outsiders do. Below is an example of the sort of thing I'm talking about: --Bruce ---------------------------------------------------------------- The message sent by Hamilton.ES at 27-Feb-84 14:53:47 PST could not be delivered to the following recipients because they were rejected by the MTP server "Maxc". The reason given was: Sorry, I never heard of an ARPA domain named "cmu-psy-a" shrager@cmu-psy-a.ARPA Original msg header being replied to: Received: from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 27 FEB 84 13:50:19 PST Return-path: <@SUMEX-AIM.ARPA:shrager@cmu-psy-a> Redistributed: Xerox1100UsersGroup^.PA Received: from CMU-CS-PT by SUMEX-AIM.ARPA with TCP; Mon 27 Feb 84 13:26:07-PST Received: from CMU-PSY-A by CMU-CS-PT with CMUFTP; 27 Feb 84 16:20:59 EST Date: Mon, 27 Feb 84 16:15:52 EST From: shrager@cmu-psy-a.ARPA Subject: Touch Screen To: 1100users@sumex.ARPA ----------------------------------------------------------------
reilly@udel-relay.arpa (G B Reilly) (02/28/84)
MMDF does generate a header that is readable on both sides of a bridge. As for CSNet, for example, all messages that travel from a CSNet host to the ARPA have their addresses modified so that they end with "@CSNET-RELAY.ARPA". Hence, according to the RFC 822 standard, those messages can be replied to. Brendan Reilly
MRC@SU-SCORE.ARPA (Mark Crispin) (03/12/84)
Bruce -
The TOPS-20 mailer, by deliberate design, does not perform any
relay services beyond that of a bridge. CMU and Columbia both run
this software (although your example involved CMU-CS-PT, a Unix
system). Unlike the UUCP world, I consider store-and-forward relaying
and relative addressing to be temporary measures pending the adoption
of a universal standard for electronic mail addressing. It's too bad
that so many people confuse "where" the person is with the "way to get
there."
I also have substantial reservations about the entire philsophy
of header-munging. All too often I have seen my message headers
transmogrified into invalid headers by a well-meaning, but incorrect,
header modifier. Several delivery problems, especially in the early
days of SMTP, proved to be undebuggable because a header modifier
succeeded in destroying the information needed to figure out what
happened. Worse is the habit of MMDF and certain other header modifiers
to make a message header "cute" by applying certain rules of case
modification; I'm really tired of seeing crap such as "Mit-Xx", "Su-Ai",
or - the worst insult of all - "Mrc".
I feel that a host using the services of a bridge should be willing
to generate a message header that is valid at the other side of the
bridge. It isn't difficult to do, especially if both sides of the bridge
are willing to recognize Internet addresses.
-- Mark --
-------