Hi All,
I’m hoping someone on this mailing list could help me with understand a particular behaviour I’m seeing with an upstream mail service and hoping someone has some more in-depth knowledge than me who can look at the below scenario and advise what the expected behaviour should look like. Issue statement: STARTTLS encryption only working in one direction. What I mean by this is illustrated below: Case 1: (Please note that IP addresses are just mock Ips to explain the issue – these are in practice internet facing/public IP addresses) u...@domain1.com originates an email to u...@domain2.com. The outbound SMTP connection looks like this on the wire. I’ve truncated it for brevity. 10.0.0.1 (sending MTA) establishes connection to 10.0.1.1 (Receiving MTA) on TCP 25. 10.0.1.1 (Receiving MTA) sends a “250 STARTTLS” header to 10.0.0.1 (Sending MTA). Note there is no hyphen but a space. Under normal operation, 10.0.0.1 (Sending MTA) should then reply with a STARTTLS header. 10.0.1.1 (Receiving MTA) should then return 220 Ready to Start TLS TLS connection establishes and everything is good. The core of my issue is that the sending MTA receives the 250 STARTTLS from the receiving MTA but never replies with STARTTLS. The sending MTA has smtpd_tls_security_level = may defined. >From review of the postfix package dependencies, it appears that postfix >relies on openssl 1.1.1k but I’m not sure if the STARTTLS function used relies >on s_client.c library or not. The PROTO_SMTP case defined in this library >seems to have some while loops that seems to look for “-“ at the 4th character >position in mbuf but in the case above, the receiving MTA seems to be >returning the header in the format “250 STARTTLS (note* with a space instead >of a “-“)” but as per RFC 3207, the format mentioned seems to be “250-STARTTLS >(note* with the hyphen)”. It seems to me like the response from the recipient >mail server is non-conformant with RFC but not sure if that’s the root of the >issue or how postfix as the client in this case handles such a header in the >response. My key question here is should postfix respond with STARTTLS command if it receives “250 STARTTLS” or will postfix only respond if its formatted as “250-STARTTLS”? I explain a bit more the reverse mail flow which succeeds indicating one direction works but the other doesn’t. Is this a bug in openssl in terms of the buffer? The while loops in s_client.c seem to look for a “-“ so I’m really unsure what the behaviour is if there is a “ “ instead. If I manually run openssl s_connect -connect 10.0.1.1:25 -starttls smtp (which is using openssl 1.1.1k), and look at the packet capture, even though the “250 STARTTLS” header is returned from the server, the TLS connection establishes and I can see in a packet capture that openssl tool is responding with STARTTLS and the encrypted channel is setup. This seems to suggest it isn’t an openssl issue but the handling may be different or I’ve made a wrong assumption and s_client.c isn’t used within postfix – perhaps gone done the bunny hole a little on that one. Testing from a workstation to the sending MTA using thunderbird of windows 10 mail client and I connect to the smtpd daemon running on 10.0.0.1 (sender MTA), I can see clearly that this service is returning “250-STARTTLS” in response to the client request, the mail client itself returns STARTTLS and the secure connection establishes. This to me seemed to suggest that the sending MTA is indeed functioning correctly and that the smtpd_tls_security_level=may option is working (if a connection is initiated towards the server). If email originates from 10.0.1.1 back the other way towards 10.0.0.1 (domain2.com to domain1.com), the traffic is encrypted and STARTTLS negotiates ok. What I don’t get is why its one direction encryption and in the other direction, encryption fails and the SMTP message is in the clear. Is this a bug in openssl, postfix or perhaps a misconfiguration issue on the sending MTA? Does the smtpd_tls_security_level=may only take affect if connections originate inbound to the server where this is defined or does this also specify opportunistic TLS for when a connection is originated outbound from the server and receives the 250 STARTTLS header? Is the sending MTA silently failing to respond with STARTTLS due to not understanding the header? I’m very keen to understand if this is a non-conformant header that is causing this anomalous behaviour postfix handling of this may not be 100% depending on the orientation that the mail flow originates. I’ve been in touch with the recipient MTA administrators and they have raised an engineering ticket to add the hyphen as per the RFC. However, is it likely that this will resolve this issue or is the problem somewhere else? Thanks for any assistance the community can provide on this. It’s an interesting issue but one I can’t put my finger on. Postfix version is the latest available for Centos8-Stream – can provide specifics of the version if that is helpful. Regards, Andrew
