AUTH PLAIN response is malformed

[kylegoetz]

AUTH PLAIN 334

However, the RFC that defines SMTP replies states

Formally, a reply is defined to be the sequence: a three-digit code, <SP>, one line of text, and <CRLF>, or a multiline reply (as defined in the same section). Since, in violation of this specification, the text is sometimes not sent, clients that do not receive it SHOULD be prepared to process the code alone (with or without a trailing space character).

In the specification for AUTH PLAIN, teh RFC itself does deviate from this spec in an example, even the example explicitly states in their deviating example that there is still a space after the reply code:

C: AUTH PLAIN (note: there is a single space following the 334 on the following line) S: 334

[rnwood]

Are you seeing this cause an issue with some client?

As I read the ABFN grammar in RFC5321, the space is part of the textstring which is surrounded by [ ] and so is optional.

   Greeting       = ( "220 " (Domain / address-literal)
                  [ SP textstring ] CRLF ) /
                  ( "220-" (Domain / address-literal)
                  [ SP textstring ] CRLF
                  *( "220-" [ textstring ] CRLF )
                  "220" [ SP textstring ] CRLF )

   textstring     = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII

If there's no textstring, smtp4dev is currently not writing out a space.

This does seem to conflict with the "formal" definition in the text and the other part you quoted about violation.

I guess always printing out a space would comply with both, since textstring can include SP. Is that what you are recommending?

[rnwood]

If there's no textstring, smtp4dev is currently not writing out a space.

Correction: If there's no textstring, smtp4dev IS currently writing out a space.