Margulies@SCRC-YUKON.ARPA.UUCP (05/28/86)
Date: Tue 27 May 86 14:59:42-PDT
From: "Joel Goldberger" <JOEL@isi-venera.arpa>
Benson,
I have been asked to help with your question about our mailers rejection
of messages from you. The message you sent to Postmaster claimed a from
address of Margulies@SCRC-YUKON.ARPA, but this host didn't appear
anywhere in the Received lines. The only hosts in that line are:
REDWING.SCRC.Symbolics.com
SAPSUCKER.SCRC.Symbolics.com
MC.LCS.MIT.EDU
Our domain resolvers are unable to find any record for the first two of
these hosts. SCRC-YUKON.ARPA is in both the domain and NIC databases.
Our TOPS-20 mailers will not accept mail from hosts they cannot resolve.
Currently our TOPS-20 systems use the NIC table for all lookups, but in
this case a domain based system would not have helped either.
You should try to get your mailer to supply at least some honest data
concerning the route of outgoing mail.
I think that this is reasonable information. The message says on its
face: Reply to me by sending to SCRC-YUKON.ARPA. YUKON is a legitimate,
visible host.
Using the delivery history is flawed. Just because a given chain of
machines participated in getting a message out, dosen't mean that it is
an appropriate return route.
I can sympathize with wanting to toss mail that can't be replied to.
However, the restriction should be that mail is returned if none of the
return-path, the sender, the reply-to or the from address could be
resolved, not if any of them failed to resolve.
Furthermore, just because you cannot parse it now, dosen't mean you
won't be able to later. Surely you have noticed the rather low
availability of most of the domain servers.
(as an aside: as a user, I often know more about mail topology than
computers, because of the incredibly poor behavior of the domain system
[no zone transfers, etc.] Thus, I would prefer to receive this kind of
mail rather than haveing the SMTP server do me the favor of dropping it
on the ground].
REDWING is my personal machine, which does not offer SMTP, because it
has no file system. SAPSUCKER is an internal mail transfer node, used
to share outgoing mail load. Yukon is the one and only appropriate
place to send me mail, and that's why its in the from line.
I have no control over the delivery history. I can't `put something
reasonable in it', because it is accumulated as the message goes along.
I believe that the protocol states that its purpose is informational,
not prescriptive.
Even if SAPSUCKER and REDWING were in the host databases, using the
return path to return the mail would fail.JOEL@ISI-VENERA.ARPA.UUCP (05/28/86)
The rejection you are getting is from our SMTP receiver, which (like most mailers) does not parse either the headers or the text of the message. It responds only to the SMTP control lines to form both the return-path line and the received: line. It doesn't like the host specification in the MAIL FROM:<...> SMTP control line. It doesn't care what is sent after the DATA SMTP control line (which is where the "Reply-To: " line is). There are no hard rules on this and our implementation chooses to reject mail where the only host specified is unknown. UNIX is not so rigorous, it will accept mail from (or for) any host whether it exists or not, and will then have no way of informing anyone but the mail system maintainer that there is a problem. We like the TOPS-20 system better where the originator has to resolve the problem. - Joel - -------
MRC@SIMTEL20.ARPA.UUCP (05/28/86)
Joel -
ISI's SMTP receiver is, as far as I can tell, unique to ISI. The
standard TOPS-20 SMTP receiver is my MAISER, which does not validate
the host names in MAIL FROM:<...> SMTP commands. The reason it does
not validate the host names in the MAIL FROM is that if it did my
friends at the NIC would not be able to receive HOSTMASTER mail of
the form "Hi, this is FOOBAR, we just got on the net, please add us to
the host table"!!!!
Since the MAIL FROM host names are only used by the mailer to
return failed mail, this isn't a big deal. Failed messages that can't
be returned end up in the dead letter mailbox (typically POSTMASTER but
not necessarily), where a human can decide whether to keep or toss it
out.
I ask you not to confuse the two SMTP servers, and I urge the ISI
system management to give serious consideration towards adopting the
standard SMTP server or at least to implement its willingness to accept
mail in spite of possibly bogus return paths.
-- Mark --
-------sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) (05/28/86)
I would like to second Mark's request to ISI to consider checking out their SMTP mailer software. I don't remember what the exact problem was offhand right now, but I remember we had trouble talking to their mailer, and vice versa. I *think* it had something to do with what I believe was some nonstandard SMTP dialog. /Ken -------
Chase@USC-ISIB (Dale Chase) (05/28/86)
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
Margulies@SCRC-YUKON.ARPA (Benson I. Margulies) (05/28/86)
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.garry@TCGOULD.TN.CORNELL.EDU.UUCP (05/30/86)
Why not send a rejection (actually a warning) AND forward the message?