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!watmath!clyde!cbosgd!ucbvax!SCRC-YUKON.ARPA!Margulies
From: Margulies@SCRC-YUKON.ARPA (Benson I. Margulies)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: {8605.0428} oh mr. postman ...
Message-ID: <860528074328.3.MARGULIES@REDWING.SCRC.Symbolics.COM>
Date: Wed, 28-May-86 07:43:00 EDT
Article-I.D.: REDWING.860528074328.3.MARGULIES
Posted: Wed May 28 07:43:00 1986
Date-Received: Thu, 29-May-86 03:08:23 EDT
References: <[USC-ISIB.ARPA]28-May-86.01:04:26.CHASE>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 43
Approved: tcp-ip@sri-nic.arpa


    Date: 28 May 1986 01:04-PDT
    From: Dale Chase <Chase@USC-ISIB>

    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

1)

As I have pointed out before, the resolvability of an address varies
with time and the domain system.  It is never appropriate to ask the
question: is this a valid address? and reject because it cannot be
domain resolved right now.

2)

In-Reply-To and From are in that SMTP spec for a reason, so that mail
sending agents can tell mail reading agents how to reply.  Mail
transmission agents should just follow orders and stay out of the way.

Having the SMTP server 'validate' MAIL FROM is a confusion in protocol
levels.  Personally, I think that MAIL FROM was a bad idea altogether,
for this reason.