Background: I recently had a problem with mailing list manager
(Mailman 2.1) failing to submit larger chunks of MAIL TO: addresses
to Postfix (port 25), because more that two dozen addresses in a chunk
were returning '450 ... Recipient address rejected: Domain not found',
and finally Postfix gave up with '421 Error: too many errors',
and the MLM just didn't know how to handle it and produced
a traceback/crash.
The problem is now fixed by using non-standard port where
DNS checks are disabled in Postfix smtpd service, so all is fine,
the invalid recipients problem is delegated to Postfix smtp client.
Now what is bothering me: how should (any) SMTP client handle
the situation where some 'MAIL TO:'s return 450 temporary failure.
Should it attempt to go into DATA transfer at all?
Is this problem related to the prescribed handling of
'452 Too many recipients' error?
How does Postfix smtp client handle it?
And how would it handle the '421 Error: too many errors'?
Mark
That is not good. Whatever the SMTP server says, the client should
never crash and burn.
Reply code 421 was defined 20 years ago in RFC 821:
421 <domain> Service not available,
closing transmission channel
[This may be a reply to any command if the service knows it
must shut down]
> The problem is now fixed by using non-standard port where
> DNS checks are disabled in Postfix smtpd service, so all is fine,
> the invalid recipients problem is delegated to Postfix smtp client.
That's one way of solving it. Another one is to exempt local
clients from all the DNS and UCE filtering.
> Now what is bothering me: how should (any) SMTP client handle
> the situation where some 'MAIL TO:'s return 450 temporary failure.
SMTP reply codes were defined 20 years ago in RFC 821.
Theory of Reply Codes
The three digits of the reply each have a special significance.
The first digit denotes whether the response is good, bad or
incomplete. An unsophisticated sender-SMTP will be able to
determine its next action (proceed as planned, redo, retrench,
etc.) by simply examining this first digit. A sender-SMTP that
wants to know approximately what kind of error occurred (e.g.,
mail system error, command syntax error) may examine the second
digit, reserving the third digit for the finest gradation of
information.
There are five values for the first digit of the reply code:
1yz Positive Preliminary reply
The command has been accepted, but the requested action
is being held in abeyance, pending confirmation of the
information in this reply. The sender-SMTP should send
another command specifying whether to continue or abort
the action.
[Note: SMTP does not have any commands that allow this
type of reply, and so does not have the continue or
abort commands.]
2yz Positive Completion reply
The requested action has been successfully completed. A
new request may be initiated.
3yz Positive Intermediate reply
The command has been accepted, but the requested action
is being held in abeyance, pending receipt of further
information. The sender-SMTP should send another command
specifying this information. This reply is used in
command sequence groups.
4yz Transient Negative Completion reply
The command was not accepted and the requested action did
not occur. However, the error condition is temporary and
the action may be requested again. The sender should
[Page 48] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
return to the beginning of the command sequence (if any).
It is difficult to assign a meaning to "transient" when
two different sites (receiver- and sender- SMTPs) must
agree on the interpretation. Each reply in this category
might have a different time value, but the sender-SMTP is
encouraged to try again. A rule of thumb to determine if
a reply fits into the 4yz or the 5yz category (see below)
is that replies are 4yz if they can be repeated without
any change in command form or in properties of the sender
or receiver. (E.g., the command is repeated identically
and the receiver does not put up a new implementation.)
5yz Permanent Negative Completion reply
The command was not accepted and the requested action did
not occur. The sender-SMTP is discouraged from repeating
the exact request (in the same sequence). Even some
"permanent" error conditions can be corrected, so the
human user may want to direct the sender-SMTP to
reinitiate the command sequence by direct action at some
point in the future (e.g., after the spelling has been
changed, or the user has altered the account status).
> Should it attempt to go into DATA transfer at all?
> Is this problem related to the prescribed handling of
> '452 Too many recipients' error?
You really should have a look at RFC 821 (or 2821 if you like).
Wietse