Re: [ietf-smtp] Email address maximum length

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,
> >
> > MAIL
> >                 S: 250
> >                 F: 552, 451, 452
> >                 E: 500, 501, 421
> >
> >
> > RFC 2821 says,
> >
> > MAIL
> >                 S: 250
> >                 E: 552, 451, 452, 550, 553, 503
> >
> > RFC 5321 says,
> >
> > MAIL
> >
> >                 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 4.1.1.11, 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
>     parameter.
>
> 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.
>
>
> --
> HLS
>
>
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf-smtp

-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp