Hello again, On 2021-08-09, at 09:39 (UTC-0400), Wietse Venema had the following to say:
: There was a Postfix-users thread that led to this. : https://marc.info/?t=110122895800001&r=1&w=2 Uh, oh. The example conversation is noteworthy for two reasons. First, upon receiving input consisting of the three tokens "POST", "/", and "HTTP/1.0", the server should have recognised that such a token sequence does not constitute a valid SMTP command line. Second, when replying with code 502, the server suggests that in fact there exists in the standard SMTP protocol definition or the local interpretation of it an action named "POST", and the server recognised it as such, but it is not (yet) implemented. This differs semantically from "I do not recognise this token sequence as a command line at all". The semantics for 502 are made very clear in RFC 5321 [1,2], where 504 (command implemented, but one of its parameters isn't) for example, is considered a refinement of 502. The server hanging on to a connection is the expected behaviour when replying with 502, because in such a case, there was no violation of SMTP proper. The server, merely unable to fulfill the request, understood it and is giving the client the choice to try and keep going with both sides still speaking SMTP. However, upon receiving the token "POST", the server should have instead replied with code 500 (Syntax error, command unrecognized) [3], where, on the server's side, the choice to keep going is much harder to justify, since the client obviously isn't even willing to speak SMTP and it is likely that this will not change. : The current implementation is based on this contribution: : https://marc.info/?t=110131553500006&r=1&w=2 I remember coming across the documentation for smtpd_forbidden_commands and wondered what that was for. Now I understand that it is a consequence of the interpretation of the example conversation. Perhaps a more suitable name would have been smtpd_forbidden_command_line_tokens , lest people start thinking "POST" is actually an SMTP command. Are there plans to revisit the SMTP command parsing and handling logic in the server in one form or another? Are people making active use of the smtpd_forbidden_commands parameter? Thanks, Mono [1] https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.1 [2] https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.4 [3] https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.2
signature.asc
Description: PGP signature
