lear@NET.BIO.NET (Eliot Lear) (12/12/88)
I have always believed that the general rule for implementations is
that they should expect the least from other implementations, and
be as robust as possible, as far as conformance to a given RFC is
concerned. With that thought in mind, I have a question for TCP-IP
implementors who have done SMTP implementations.
Given a permanent error condition and that you control SMTP server
code, which do you believe to be the better action?
[a] Immediately have a server respond with an error to the SMTP client
leave the client to report the error.
[b] Receive the message and report the error directly to the sender.
Solution [a] is the straight forward method which programs such as
most incarnations of sendmail use. I know of at least one
implementation that has used solution [b] in the past. The reason for
using solution [b] is that I would not have to rely on any other
implementation to properly dispose of the error. I have heard of at
least one implementation that considered a particular permanent error
response as temporary, and the fact that it was blatantly wrong didn't
stop it from continually retrying our host. Using solution [b]
eliminates such bizarre cases, but places honus of error handling on
the server.
What's your opinion?
--
Eliot Lear
[lear@net.bio.net]Ata@RADC-MULTICS.ARPA ("John G. Ata") (12/12/88)
From: apple!bionet!lear at BLOOM-BEACON.MIT.EDU (Eliot Lear)
Subject: implementation question
Given a permanent error condition and that you control SMTP server
code, which do you believe to be the better action?
[a] Immediately have a server respond with an error to the SMTP client
leave the client to report the error.
[b] Receive the message and report the error directly to the sender.
I believe that [a] is the more efficient way to go. This is because if
a SMTP server KNOWS that it cannot deliver the message to the intended
recipient, it is taking up network bandwidth needlessly by accepting the
message. It would seem that the proper thing to do is to reject the
message at that point, so that the SMTP user can then return the mail
item to sender.
John G. Atabarns@GATEWAY.MITRE.ORG (Bill Barns) (12/13/88)
I once wrote an SMTP which got fairly heavy use, though lately I am out of the business of maintaining it. I have the feeling you are looking for someone to tell you it is fine to use method [b] (accept the mail and then mail a rejection). I sympathize with the problems of dealing with brain-damaged mailers at other sites, but I think that method [b] is too extreme for general use, notwithstanding your clever and, uh, innovative application of "...be liberal in what you accept..." This would have been more convincing if it didn't impose a constraint on other people's mailers. They may feel that they can do a better job writing an error message than you can. Suppose a message is sent to a long list of addresses and several of the deliveries immediately fail for whatever reasons. A clever SMTP-sender (like mine) would avoid a lot of mailbox clutter by handing the originator one error notification listing the failures and the reasons, if it were given the opportunity to do so - and method [b] takes away that opportunity. Or, a sending SMTP might want to generate the error text in some language other than the one your SMTP speaks. Insofar as the Host Requirements RFC (yes, it's still a-comin') says anything on this topic, it pushes toward returning SMTP error codes at the first appropriate moment, and minimizing after-the-fact failure messages. I think this is generally the right thing to do. However, no rule prohibits you from adopting unusual measures to defend yourself when necessary. I hope you can go with method [a] at least for the most part, and find some practical criterion for restricting [b] to actual evildoers - perhaps a configuration file listing the nasty hosts, or heuristics to recognize the retry that ought not to be. Bill Barns / MITRE-Washington / barns@gateway.mitre.org
root@ETN-WLV.EATON.COM (System Root) (12/13/88)
From: "John G. Ata" <Ata@RADC-MULTICS.ARPA>
Subject: Re: implementation question
From: apple!bionet!lear at BLOOM-BEACON.MIT.EDU (Eliot Lear)
Subject: implementation question
Given a permanent error condition and that you control SMTP server
code, which do you believe to be the better action?
[a] Immediately have a server respond with an error to the SMTP client
leave the client to report the error.
[b] Receive the message and report the error directly to the sender.
I believe that [a] is the more efficient way to go. This is because if
a SMTP server KNOWS that it cannot deliver the message to the intended
recipient, it is taking up network bandwidth needlessly by accepting the
message. It would seem that the proper thing to do is to reject the
message at that point, so that the SMTP user can then return the mail
item to sender.
John, Eliot, et al:
The correct answer is it depends. There is a tacit assumption in the query
that the recipient exists or that the transmitting station is persistent in
attempting to deliver a message to a non-existent recipient. In the latter
case, [b] is the correct answer as it will limit the impact on the network
with the response being sent to the "Re-sent from:", "Sender:", or "From:".
In the former case, either [a] or [b] can be the correct answer. If the
problem is resource related, the answer is [a] if there is a reasonable
expectation that the user can or will free the necessary reources in a
reasonable period of time. (Unlike AFIS/IND ;-)) If the problem is a brain
damaged mailer, [b] is the correct answer--the neat trick is figuring out
whether or not you've seen the message several times before and that you've
seen the same errors that preclude successful delivery of the message. The
Internet doesn't have an equivalent of an AUTODIN Switching Center which
you an ring up and request that the message be "scrubbed".
MertonRudy.Nedved@RUDY.FAC.CS.CMU.EDU (12/14/88)
The problem (that may not be applicable to this issue any more) occured about 5 to 8 years ago that if you generated an error message at the SMTP level to a client about a piece of mail being incorrect in some sense (bad address, ambiguous user name, space quota exceeded for mailbox, etc) then the client because of poor mail delivery system in use would not generate a message back to the user or worst yet would simply say the mail could not be delivered. The classic case was when SMTP would generate a multiline error response to a RCPT TO:<> command indicating the name was ambiguous and what is was ambiguous with. Many systems just blew it off or did not understand it. This may not be the case any more but it is something to worry about. When users send mail from a technological old and somewhat busted system to one that is on the cutting edge and they don't understand what happned...they tend to blame the site that listens to them....like the site that has the better mail software. -Rudy