On Thu, Jul 19, 2018 at 10:22:38AM -0400, James B. Byrne wrote:
> After changing the client certificate request to 'no' we get a little
> further in the negotiation but it still fails:
No, you get 100% of the way through the TLS handshake, the problem
is with SMTP inside the now encrypted channel. Perhaps MTU issues
in the client->server direction.
> Jul 19 09:31:37 mx32 postfix-p25/smtpd[44981]: NOQUEUE:
> client=mail.rosedale.ca[66.135.118.147]
> Jul 19 09:31:37 mx32 postfix-p25/smtpd[44981]:
> lost connection after DATA (0 bytes)
> from mail.rosedale.ca[66.135.118.147]
> Jul 19 09:31:37 mx32 postfix-p25/smtpd[44981]:
> disconnect from mail.rosedale.ca[66.135.118.147]
> ehlo=1 mail=1 rcpt=1 data=0/1 commands=3/4
This delivery attempt did not even do TLS at all.
The connection is lost, at the beginning of what would be the data
transfer phase. Perhaps a path MTU issue in the client -> server
direction.
> They are reporting a timeout error when trying to transmit to our
> Postfix-3.3.1 MX.
What I find a bit surprising is the combination of "NOQUEUE" and
"rcpt=1", which would normally mean an accepted recipient and the
assignment of a queue-id. Do you have a pre-queue proxy-filter?
In that case the queue id is assigned only after the full message
body is received.
> Their DSN says:
>
> . . . conversation with mx32.harte-lyne.ca[216.185.71.32]:25 timed out
> while sending MAIL FROM . . .
That's odd, they actually sent "MAIL FROM", "RCPT TO" and "DATA"
pipelined together. But somehow never saw the replies? Perhaps
buggy pipelining support?
> We have only seen this type of problem (client disconnect with 0 data
> transferred) with a very few of our correspondents. As it coincides
> with moving from Postfix-2.11 to 3.3 we are concerned that we have
> introduced some sort of compatibility issue.
The Postfix version is likely irrelevant. Get a PCAP file and
see what's happening at the TCP layer.
--
Viktor.
