🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.mail.sendmail
2 messages
2 total messages Started by Eliot Lear Mon, 12 Dec 1988 07:44
implementation question
#3016
Author: Eliot Lear
Date: Mon, 12 Dec 1988 07:44
30 lines
1700 bytes
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]
Re: implementation question
#3017
Author: Craig F. Everhart
Date: Mon, 12 Dec 1988 18:56
16 lines
1525 bytes
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
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads