Hello I'm experiencing the above problem on a customer's system while trying to send mail to the domain i-sec.tuv.com -- I've replaced the HELO/EHLO of our customer with mail.customer. The logs say:
Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: < mail01.i-sec.tuv.com[193.24.224.9]:25: 220 mail01.i-sec.tuv.com ESMTP Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: > mail01.i-sec.tuv.com[193.24.224.9]:25: EHLO mail.customer Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: < mail01.i-sec.tuv.com[193.24.224.9]:25: 250-mail01.i-sec.tuv.com Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: < mail01.i-sec.tuv.com[193.24.224.9]:25: 250-8BITMIME Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: < mail01.i-sec.tuv.com[193.24.224.9]:25: 250-SIZE 104857600 Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: < mail01.i-sec.tuv.com[193.24.224.9]:25: 250 STARTTLS Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: server features: 0x101b size 104857600 Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: > mail01.i-sec.tuv.com[193.24.224.9]:25: STARTTLS Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: < mail01.i-sec.tuv.com[193.24.224.9]:25: 220 Go ahead with TLS Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: setting up TLS connection to mail01.i-sec.tuv.com[193.24.224.9]:25 Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: mail01.i-sec.tuv.com[193.24.224.9]:25: TLS cipher list "ALL:+RC4:@STRENGTH" Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: looking for session smtp:193.24.224.9:25:mail01.i-sec.tuv.com&p=1&c=ALL:+RC4:@STRENGTH in smtp cache [...] Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: Trusted TLS connection established to mail01.i-sec.tuv.com[193.24.224.9]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: > mail01.i-sec.tuv.com[193.24.224.9]:25: EHLO mail.customer Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: smtp_get: EOF Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: connect to subsystem private/defer [...] Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: send attr action = delayed Nov 5 12:36:45 pxmail1 postfix/smtp[8378]: send attr reason = lost connection with mail01.i-sec.tuv.com[193.24.224.9] while performing the EHLO handshake It looks as though mail01.i-sec.tuv.com dropped the connection, though I see no indication of the reason. Strangely, though, in a tcpdump I recorded it appears that our customer's system is sending a [RST, ACK] packet directly after sending "TLSv1 Application Data", which very probably is its EHLO. Any ideas? Cheers, Tobias