On Wed, Jun 18, 2025 at 10:59:37PM +1200, Nick Tait via Postfix-users wrote:
> On 18/06/2025 22:33, Nick Tait via Postfix-users wrote:
> > Prior to making the configuration change, the response to the STARTTLS
> > was "454 4.7.0 TLS not available due to local problem", and the SMTP
> > session remained operational, meaning if the client then sent another
> > command (e.g. QUIT), it was processed as expected. However after setting
> > "postscreen_tls_security_level = none", when I now send a STARTTLS, I
> > get a "502 5.5.1 Error: command not implemented", and then Postscreen
> > stops responding to any subsequent commands. Am I correct in thinking
> > that this isn't the expected behaviour?
>
> Sorry I realised that I worded that poorly. Let me describe the last bit
> again:
>
> After setting "postscreen_tls_security_level = none", when I now send a
> STARTTLS, I get a "502 5.5.1 Error: command not implemented", and then /the
> SMTP session/ stops responding to any subsequent commands, /until the client
> disconnects or the postscreen_command_time_limit is reached/. /(Postscreen
> itself remains operational for processing other connections.)/
That does seem unexpected to me, when STARTTLS is rejected, the server
has not turned on the TLS state machine, and has communicated as much to
the client, therefore the connection is still in cleartext mode, and
should be able to continue. If the goal is to terminate the connection,
the response could be "521" + connection close.
On Wed, Jun 18, 2025 at 09:29:55AM -0400, Bill Cole via Postfix-users wrote:
> > After setting "postscreen_tls_security_level = none", when I now send a
> > STARTTLS, I get a "502 5.5.1 Error: command not implemented",
>
> That is precisely what I'd expect. None means none: TLS is disabled.
> Presumably STARTTLS is not in the EHLO response, so nothing will try
> STARTTLS.
The question is about the state of the SMTP connection for clients that
do try STARTTLS despite the missing offer in the EHLO reply.
> > and then /the SMTP session/ stops responding to any subsequent commands,
>
> Not what I'd expect, but likely harmless. Nothing legitimate tries STARTTLS
> if it's not advertised.
Yes, but should non-legitimate clients encounter a hung connection, or
should the connection be allowed to continue or promptly terminate?
> Sending a STARTTLS command to a server that is configured to not support it
> is not going to work. It should not work. The particular style of not
> working is not really very important but I think the behavior you describe
> is not the worst choice.
What's expected is that cleartext SMTP is still in effect when STARTTLS
is rejected, and, e.g., QUIT<CRLF> should still work.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
