[Top] [All Lists]

Re: [ietf-smtp] Email address maximum length

2019-11-25 11:20:16
Very informative.
Thanks Hector.

On Mon, Nov 25, 2019 at 7:40 PM Hector Santos <hsantos=
40isdg(_dot_)net(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:

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

Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.
ietf-smtp mailing list