Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!bellcore!ulysses!ucbvax!USC-ISIB!Chase
From: Chase@USC-ISIB (Dale Chase)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: {8605.0428} oh mr. postman ...
Message-ID: <[USC-ISIB.ARPA]28-May-86.01:04:26.CHASE>
Date: Wed, 28-May-86 04:04:00 EDT
Article-I.D.: <[USC-ISIB.ARPA]28-May-86.01:04:26.CHASE>
Posted: Wed May 28 04:04:00 1986
Date-Received: Wed, 28-May-86 19:29:43 EDT
References: <12210165659.6.MRC@SIMTEL20.ARPA>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 22
Approved: tcp-ip@sri-nic.arpa

I think the NIC (and probably domain registries) has a unique need to accept
mail from unknown hosts, which doesn't apply to hosts in general.  The problem
with blithely accepting mail with unknown hostnames in the MAIL FROM:<...>
control line is that the server is accepting responsibility to either deliver
the mail or return a negative acknowledgement.  If such a piece of mail turns
out to be undeliverable, it does indeed go to the dead letter mailbox.

At this point, if the postmaster is good and the phase of the moon is right,
the mail will either be forwarded to the intended recipient or returned to the
originator.  But if the adresses are sufficiently esoteric, the mail just gets
dropped (I can remember pre-SMTP days as a Tenex operator when a periodic task
was flushing the dead letter mailbox to keep it from overflowing.  I wouldn't
be surprised if this still happens in some places).  And the sender is left
wondering why he didn't get an answer to his urgent request.

As Joel said, we prefer the originator be notified of the potential problem
immediately so it can be straightened out.  In this manner, problem resolution
is pushed to the most local point possible relative to problem's source.  In
other words, the user or administrator at site XX is more likely to know that a
piece of mail from mumble@frob should really be mumble%frob@XX.

<>Dale