Re: [exim] 2 hours delay (gnutls_handshake): timed out: deli…

Góra strony
Delete this message
Reply to this message
Autor: Evgeniy Berdnikov
Data:  
Dla: exim-users
Temat: Re: [exim] 2 hours delay (gnutls_handshake): timed out: delivering unencrypted to
On Wed, Mar 30, 2022 at 02:53:45PM +0200, tt-admin via Exim-users wrote:
> Continuation of the strace;
>
> 6649  select(8, [7], NULL, NULL, {tv_sec=60, tv_usec=0} <unfinished ...>
> 6671  <... recvfrom resumed> 0x56352d0bd71b, 324, 0, NULL, NULL) = -1
> ECONNRESET (Connection reset by peer)
> 6671  alarm(0)                          = 0
> 6671  sendmsg(7, {msg_name=NULL, msg_namelen=0,
> msg_iov=[{iov_base="\25\3\3\0\2\2Z", iov_len=7}], msg_iovlen=1,
> msg_controllen=0, msg_flags=0}, 0) = -1 EPIPE (Broken pipe)
> 6671  --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=6671,
> si_uid=111} ---


Diring TLS exchange server sent RST, client got ECONNRESET and tried to
send TLS closing packet (it's my guess what "\25\3\3\0\2\2Z" means),
so client got EPIPE because connection has been deleted by kernel on RST.

The question is why server has dropped connection. Probably this connection
was timed out -- on the server's side, not on the client's one.
Traffic dump from both ends could make this situation clean.

> 6671  openat(AT_FDCWD, "/var/log/exim4/mainlog",
> O_WRONLY|O_CREAT|O_APPEND|O_NONBLOCK, 0640) = 5
> 6671  fcntl(5, F_GETFD)                 = 0
> 6671  fcntl(5, F_SETFD, FD_CLOEXEC)     = 0
> 6671  fcntl(5, F_GETFL)                 = 0x8c01 (flags
> O_WRONLY|O_APPEND|O_NONBLOCK|O_LARGEFILE)
> 6671  fcntl(5, F_SETFL, O_WRONLY|O_APPEND|O_LARGEFILE) = 0
> 6671  fstat(5, {st_mode=S_IFREG|0640, st_size=15402412, ...}) = 0
> 6671  write(5, "2022-03-30 12:25:33.594 [6671] 1"..., 187) = 187


You have better to increase strace display length with -s.., or post
full log line here.

> 6671  socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 7
> 6671  setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> 6671  alarm(300)                        = 0

>
> Then the unencrypted smtp connections starts and the mesage is delivered
> unencrypted.


I could imagine one reason for such server's behaviour: presence of some
statefull firewall behind server, which scans SMTP packets and drops
packets with "suspicious" patterns. If it drop some TLS packet from client,
it would also drop all its copies on retransmissions, so TLS session
become disrupted and tcp connection dies on timeout.

However, in this scenario messages should not wait in queue for hours,
they should be delivered in plain SMTP just after first TLS timeout.
--
Eugene Berdnikov