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]cfe+@andrew.cmu.edu (Craig F. Everhart) (12/13/88)
I like [a] better (give an SMTP error rather than accept a piece of mail for
later rejection). If you're most interested in tolerating a system that doesn't
interpret your error codes, maybe you can narrow how you read the specification
so that the error code you generate will be one that the remote system will
interpret the way you want (as a permanent error). If the system in question
won't interpret anything as a permanent error, this mechanism won't help much.
One of the good reasons for preferring [a] when possible is that it gives faster
error turnaround to the user, not to mention causing less overhead for your
system because it doesn't have to handle composition, enqueueing, and delivery
of the error message piece of mail. The significant reason for preferring [b],
other than the reason you give of confused SMTP-user ends, is that if you always
accept mail for later delivery, the SMTP-user end doesn't have to wait around
while you check for the permanent-failure condition in question.
Craig Everhart