[Top] [All Lists]

Re: [ietf-smtp] Email address maximum length

2019-11-25 08:10:25
On 11/24/2019 6:35 AM, Viruthagiri Thirumavalavan wrote:
I have a query regarding the error code "501 Syntax error in
parameters or arguments"

RFC 821 says,

                S: 250
                F: 552, 451, 452
                E: 500, 501, 421

RFC 2821 says,

                S: 250
                E: 552, 451, 452, 550, 553, 503

RFC 5321 says,


                S: 250
                E: 552, 451, 452, 550, 553, 503, 455, 555

It seem like error code 501 accidentally got removed in 2821.

Odds are very good, it was not accidentally removed.

501 was most likely codified as a common practice reply code as used with among similar client/server protocol engines, such as FTP and NNTP. These protocols also use 501, so as a common practice, if you were going to write a text-based client/server command/response protocol engine, you would most likely consider using 501 for syntax errors. Repeating it in the documentation for each command may have been viewed as redundant. Also 501 is not guaranteed. Just consider this example:

C: MAIL FROM: <user(_at_)example(_dot_)com>
C: MAIL FROM:<user(_at_)example(_dot_)com>

One has the extra space. Some strict servers COULD issue an error for the first one. Against some strict SMTP servers that exist, client could see a 500, 501 or even a 504 or even 555 syntax error response.

While the 500 reply code is generally reserved for an "unknown command" response, it is always a possible response for all commands from an protocol engine standpoint. Yet, it is not shown in any of the updated docs except for commands that could are optional.

5321 seem like fixed that issue by introducing two new error codes.

    455  Server unable to accommodate parameters
    555  MAIL FROM/RCPT TO parameters not recognized or not implemented

How exactly 2821 based servers responds when the parameters are not
recognized by MAIL command?

As it is described RFC5321 section, this will depend on the MAIL command ESMTP extension (RFC).

The protocol extension provides specifics describing how the client should implements the extension. If parameters are incorrect, the protocol COULD use the 5321 guideline for x5z and the compliant SMTP client COULD be ready to use the y5z response. Maybe the protocol will say MUST or SHOULD, but it needs to be ready that a RFC2821 compliant client could support an extension but be also ignorant of the 5321 x5z information. So the extension author needs to consider this -- not all clients are uptopar with RFC5321. It could issue a 500, 501, 502 or even 504 as is described in RFC281 section 4.2.1 for the value of the 3rd digit:

   A refinement of that is the 504 reply for
   a command that is implemented, but that requests an unimplemented

No matter what the 5yz value is, it is a very important concept in a SMTP client design that the 5yz is followed properly. The SMTP XYZ reply codes are designed to drive (direct) the SMTP client state machine. The last thing a server wants is to confuse an automated SMTP client with Y and Z reply code details that keeps it from completing the transaction. So the first digit is the most important:

1yz Positive Preliminary reply, CONTINUE
2yz Positive Completion reply, CONTINUE
3yz Positive Intermediate reply, CONTINUE
4yz Temporary Negative Completion reply, SHOULD|MAY TRY AGAIN LATER
5yz Permanent Negative Completion reply, MUST NOT TRY AGAIN

So it doesn't matter if it is 501 or 555. All RFC821/2821/5321 SMTP compliant SMTP clients are expected to work the same as far as what it does with the transaction when it sees a 5yz response. Issuing any 5yz is going drive the client to do the expected thing - don't try it again. This can drive the SMTP client to begin the DSN (Bounce) process, if necessary, where the specific Y and Z details along with extended reply codes and responses are reported for human consumption, i.e, Tech Support, to help zoom in on fixable issues.


ietf-smtp mailing list