On Thu, July 19, 2018 10:42, Viktor Dukhovni wrote: > 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.
Yes we do: smtp inet n - n - - smtpd -o smtpd_tls_security_level=may -o smtpd_proxy_filter=127.0.0.1:10024 -o smtpd_client_connection_count_limit=10 -o smtpd_proxy_options=speed_adjust -o syslog_name=postfix-p25 Which is for amavisd. /usr/local/etc/amavisd.conf:$inet_socket_port = 10024; Our system load averages are not excessive: MX host: 12:18PM up 8 days, 19 mins, 1 users, load averages: 0.39, 0.34, 0.29 Stand-alone Desktop workstation: 2:19PM up 13 days, 16:39, 1 users, load averages: 0.35, 0.29, 0.26 Both systems running FreeBSD-11.1 > >> 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? In the particular case under consideration I discovered this reference to the Barracuda firewall: What are potential causes of "Sender Timeout" on the Barracuda Spam Firewall? https://campus.barracuda.com/product/emailsecuritygateway/knowledgebase/50160000000GTxtAAG/what-are-potential-causes-of-sender-timeout-on-the-barracuda-spam-firewall/ Which contains the following notes: . . . Sender timeouts can be caused by any the following: Firewall with proxying or some type of packet filtering enabled for port 25 (sender or receiver's firewall) . . . Any type of relay device between the firewall and Barracuda not configured properly or with additional scanning enabled (receiver's side) . . . Here are some references for additional information: ESMTP TLS Configuration Note: If you use Transport Layer Security (TLS) encryption for e-mail communication then the ESMTP inspection feature (enabled by default) in the PIX drops the packets. In order to allow the e-mails with TLS enabled, disable the ESMTP inspection feature as this output shows. Refer to Cisco bug ID CSCtn08326 (registered customers only) for more information. pix(config)#policy-map global_policy pix(config-pmap)#class inspection_default pix(config-pmap-c)#no inspect esmtp pix(config-pmap-c)#exit pix(config-pmap)#exit . . . -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
