ietf-svn-bot
commented
3 years ago @alexey.melnikov@isode.com commented
Also:
4.3.1. Sequencing Overview
The table below lists alternative success and failure replies for each command. These SHOULD be strictly adhered to. A receiver MAY substitute text in the replies, but the meanings and actions implied by the code numbers and by the specific command reply sequence MUST be preserved. However, in order to provide robustness as SMTP is extended and evolves, the discussion in Section 4.2.1 still applies: all SMTP clients MUST be prepared to accept any code that conforms to the discussion in that section and MUST be prepared to interpret it on the basis of its first digit only.
Above sentence is new text based on yet another round of discussions about "invalid codes".
keyword_SMTPowner:alexey.melnikov@isode.comresolution_fixedtype_defect| by alexey.melnikov@isode.com4.2. SMTP Replies
An SMTP server SHOULD send only the reply codes listed in this document or additions to the list as discussed below. An SMTP server SHOULD use the text shown in the examples whenever appropriate.
An SMTP client MUST determine its actions only by the reply code, not by the text (except for the "change of address" 251 and 551 and, if necessary, 220, 221, and 421 replies); in the general case, any text, including no text at all (although senders SHOULD NOT send bare codes), MUST be acceptable. The space (blank) following the reply code is considered part of the text. Whenever possible, a sender- SMTP SHOULD test the first digit (severity indication) of a reply code it receives.
What is that sentence supposed to be tell us? Test the first digit and examine the others only if necessary? Note the interaction between this and various flaps about adding new codes.
The list of codes that appears below MUST NOT be construed as permanent. While the addition of new codes should be a rare and significant activity, with supplemental information in the textual part of the response (including enhanced status codes [34] and the successors to that specification)
Issue migrated from trac:13 at 2022-01-31 12:34:13 +0000