Well, seems like the remote site managed to install an update for their
Symantec E-Mail Gateways and since then - the error disappeared. We still
run on Exim v4.90.
-----Ursprüngliche Nachricht-----
Von: Exim-users [
mailto:exim-users-bounces+tt-admin=intranett.de@exim.org]
Im Auftrag von Andrew C Aitchison via Exim-users
Gesendet: Sonntag, 24. April 2022 11:37
An: tt-admin
Cc: exim-users@???
Betreff: Re: [exim] 2 hours delay (gnutls_handshake): timed out: delivering
unencrypted to
On Tue, 19 Apr 2022, tt-admin via Exim-users wrote:
> Just finished testing - the problem still occurs when we use Ubuntu 20.04
> with Exim version 4.93 #5 (built 28-Apr-2021 13:19:17) (our older machine
> where the problem was first monitored is v4.90 and Ubuntu 18.04).
Exim v4.93 was released in 2019, so still not very new.
Ubuntu 21.10 has exim 4.94.2 and 22.04 (released this week) has exim 4.95.
Any chance of seeing whether a newer exim, perhaps locally built, helps ?
> -----Ursprüngliche Nachricht-----
> Von: Exim-users [mailto:exim-users-bounces+tt-admin=intranett.de@exim.org]
> Im Auftrag von Andrew C Aitchison via Exim-users
> Gesendet: Donnerstag, 31. März 2022 12:35
> An: tt-admin
> Cc: exim-users@???
> Betreff: Re: [exim] 2 hours delay (gnutls_handshake): timed out:
delivering
> unencrypted to
>
> On Thu, 31 Mar 2022, tt-admin via Exim-users wrote:
>
>> exiwhat says: waiting for a remote delivery subprocess to finish
>>
>> started a new strace with longer lines (-s 256) and date column.
>>
>> I will try to contact the remote administrator, but my hopes for a trace
>> from their side are low (Symantec Messaging Gateway, i suppose without
> root
>> access).
>
> Ah. If it is a mail gateway, the question might be whether their gateway
> starts to send the message on to their mail server (cut-through delivery)
> or not.
>
> Does the Symantec Messaging Gateway advertise PIPELINING and do you use it
?
>
>> --
>> Marc
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Exim-users
[
mailto:exim-users-bounces+tt-admin=intranett.de@exim.org]
>> Im Auftrag von Evgeniy Berdnikov via Exim-users
>> Gesendet: Mittwoch, 30. März 2022 19:56
>> An: exim-users@???
>> Betreff: 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
>>
>> --
>> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
>> ## Exim details at http://www.exim.org/
>> ## Please use the Wiki with this list - http://wiki.exim.org/
>>
>>
>> --
>> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
>> ## Exim details at http://www.exim.org/
>> ## Please use the Wiki with this list - http://wiki.exim.org/
>>
>
> --
> Andrew C. Aitchison Kendal, UK
> andrew@???
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>
--
Andrew C. Aitchison Kendal, UK
andrew@???
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
