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

Reply via email to