From owner-freebsd-questions@freebsd.org Mon Jun 22 16:15:37 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E019A332489 for ; Mon, 22 Jun 2020 16:15:37 +0000 (UTC) (envelope-from jmc-freebsd2@milibyte.co.uk) Received: from p3plwbeout02-04.prod.phx3.secureserver.net (p3plsmtp02-04-2.prod.phx3.secureserver.net [72.167.218.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wbeout.secureserver.net", Issuer "Starfield Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49rDz92NTLz3gjH for ; Mon, 22 Jun 2020 16:15:32 +0000 (UTC) (envelope-from jmc-freebsd2@milibyte.co.uk) Received: from outmx-028.london.gridhost.co.uk ([95.142.156.253]) by :WBEOUT: with ESMTP id nP61juOXRWLXAnP62j2i6R; Mon, 22 Jun 2020 09:14:59 -0700 X-CMAE-Analysis: v=2.3 cv=TsqYewfh c=1 sm=1 tr=0 a=0sP6G7xXiiOFqQt3g3kR8w==:117 a=aH6JTgnnTGHwN2iBTwNb8w==:17 a=nTHF0DUjJn0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=4-FpMA6rAAAA:8 a=pGLkceISAAAA:8 a=2bJ9UxF96aBEyabTRQIA:9 a=oE2AgNN5QBb14TqB:21 a=IyGR49JxZab0NR1b:21 a=QEXdDO2ut3YA:10 a=Ag8d4eHGcH7vOv5XCNQA:9 a=YBwbQvoeX2L8x-DN:21 a=_W_S_7VecoQA:10 a=oUcH5ZleDwtbiW4PWyS7:22 X-SECURESERVER-ACCT: X-SID: nP61juOXRWLXA Received: from curlew.milibyte.co.uk (unknown [82.71.56.121]) (Authenticated sender: mailpool@milibyte.co.uk) by outmx-028.london.gridhost.co.uk (Postfix) with ESMTPA id 9B07B221B18C5 for ; Mon, 22 Jun 2020 17:14:57 +0100 (BST) Received: from [127.0.0.1] (helo=curlew.localnet) by curlew.milibyte.co.uk with esmtp (Exim 4.94) (envelope-from ) id 1jnP4A-00011K-HR for freebsd-questions@freebsd.org; Mon, 22 Jun 2020 17:13:02 +0100 From: Mike Clarke To: freebsd-questions@freebsd.org Subject: Re: Exim - retry time not reached for any host Date: Mon, 22 Jun 2020 17:13:02 +0100 Message-ID: <1854884.R0FQcr2YjX@curlew> In-Reply-To: References: <2534646.NQNxk83B2J@curlew> <2063278.3V7qYkmoPJ@curlew> MIME-Version: 1.0 X-TSO-Authenticated: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: jmc-freebsd2@milibyte.co.uk X-SA-Exim-Scanned: No (on curlew.milibyte.co.uk); SAEximRunCond expanded to false X-CMAE-Envelope: MS4wfF/2Zu26KOSQnVIVF8kfCXV7gjVvbA9l3rglww3RzBmLxSkIfXc2uS0lDJpipOTWV21Np9EbW4c3KuPryEIrgi7TDvjNXEr8ryqf0L1Z1q4ZrtyoGrdw goxba248wcaPdoNTDIG1VHdOkJ6YHNUUZ8/EsYiJG/DCbK3HRYGV9eb8XlhSajaLjH3ASs/YOjrBPCQ45aGDEUDRzoCscQS8KY7DvhFO1s4srbYHsddHvcWn X-Rspamd-Queue-Id: 49rDz92NTLz3gjH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jmc-freebsd2@milibyte.co.uk designates 72.167.218.97 as permitted sender) smtp.mailfrom=jmc-freebsd2@milibyte.co.uk X-Spamd-Result: default: False [-1.55 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:72.167.218.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.973]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_HAM_SHORT(-0.24)[-0.235]; RCVD_IN_DNSWL_NONE(0.00)[72.167.218.97:from]; NEURAL_HAM_MEDIUM(-1.04)[-1.040]; DMARC_NA(0.00)[milibyte.co.uk]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; CTE_CASE(0.50)[]; ASN(0.00)[asn:26496, ipnet:72.167.216.0/22, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 16:15:38 -0000 On Monday, 22 June 2020 11:27:30 BST Daniel Lysfjord via freebsd-questions = wrote: > In your route_list, you have mail3.gridhost.co.uk, not that it should > matter, =46or some reason the service provider quotes mail3.gridhost.co.uk in their= email setup instructions=20 despite it advertising itself as mail.gridhost.co.uk. > but you could try changing that to mail.gridhost.co.uk (or, > possibly 95.142.156.18). I have replaced mail3.gridhost.co.uk with 95.142.156.18 and tried another t= est while monitoring=20 with wireshark. The output showed only 3 packets being transmitted: No. Time Source Destination Protocol Length Info 1 0 192.168.1.13 95.142.156.18 TCP 74=09 25272 > 465 [SYN] Seq=3D0 Win=3D65535 Len=3D0 MSS=3D1460 WS=3D64 SACK_PER= M=3D1=20 TSval=3D3438884996 TSecr=3D0 2 0.021859743 95.142.156.18 192.168.1.13 TCP 74=09 465 > 25272 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D43440 Len=3D0 MSS=3D1452 SAC= K_PERM=3D1=20 TSval=3D4269392837 TSecr=3D3438884996 WS=3D2048 3 0.021872274 192.168.1.13 95.142.156.18 TCP 54=09 25272 > 465 [RST] Seq=3D1 Win=3D0 Len=3D0 And that was all there was, absolutely nothing after the RST packet. I then tried your earlier suggestion of 'exim -Rf @gmail.com' and much to m= y surprise the email=20 was sent No. Time Source Destination Protocol Length Info 1 0.000000000 192.168.1.13 95.142.156.18 TCP 74=09 12424 =E2=86=92 465 [SYN] Seq=3D0 Win=3D65535 Len=3D0 MSS=3D1460 WS=3D64 SA= CK_PERM=3D1=20 TSval=3D2845252007 TSecr=3D0 2 0.021910067 95.142.156.18 192.168.1.13 TCP 74=09 465 =E2=86=92 12424 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D43440 Len=3D0 MSS=3D14= 52 SACK_PERM=3D1=20 TSval=3D4253626233 TSecr=3D2845252007 WS=3D2048 3 0.021923963 192.168.1.13 95.142.156.18 TCP 66=09 12424 =E2=86=92 465 [ACK] Seq=3D1 Ack=3D1 Win=3D66752 Len=3D0 TSval=3D28452= 52029 TSecr=3D4253626233 4 0.033580346 192.168.1.13 95.142.156.18 TLSv1.2 364=09 Client Hello 5 0.055654137 95.142.156.18 192.168.1.13 TCP 66=09 465 =E2=86=92 12424 [ACK] Seq=3D1 Ack=3D299 Win=3D45056 Len=3D0 TSval=3D425= 3626267 TSecr=3D2845252041 6 0.064630882 95.142.156.18 192.168.1.13 TLSv1.2 1506=09 Server Hello 7 0.065507499 95.142.156.18 192.168.1.13 TCP 1506=09 465 =E2=86=92 12424 [PSH, ACK] Seq=3D1441 Ack=3D299 Win=3D45056 Len=3D1440 = TSval=3D4253626276=20 TSecr=3D2845252041 [TCP segment of a reassembled PDU] 8 0.065515730 192.168.1.13 95.142.156.18 TCP 66=09 12424 =E2=86=92 465 [ACK] Seq=3D299 Ack=3D2881 Win=3D65344 Len=3D0 TSval=3D= 2845252073=20 TSecr=3D4253626276 9 0.065646720 95.142.156.18 192.168.1.13 TLSv1.2 823=09 Certificate, Server Key Exchange, Server Hello Done 10 0.066717836 192.168.1.13 95.142.156.18 TLSv1.2 192=09 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 11 0.088334588 95.142.156.18 192.168.1.13 TCP 66=09 465 =E2=86=92 12424 [ACK] Seq=3D3638 Ack=3D425 Win=3D45056 Len=3D0 TSval=3D= 4253626299=20 TSecr=3D2845252074 12 0.088559696 95.142.156.18 192.168.1.13 TLSv1.2 117=09 Change Cipher Spec, Encrypted Handshake Message 13 0.188244024 192.168.1.13 95.142.156.18 TCP 66=09 12424 =E2=86=92 465 [ACK] Seq=3D425 Ack=3D3689 Win=3D66752 Len=3D0 TSval=3D= 2845252196=20 TSecr=3D4253626300 14 0.209855921 95.142.156.18 192.168.1.13 TLSv1.2 132=09 Application Data =2E.. and continued with more traffic until completion. Just in case I'd got lucky with the random way that retries appear to work = I tried the same process=20 again. This time the first 'exim -Rf' failed to release the email but a sec= ond attempt worked. So it looks as if, for me at least, exim 4.94 has a high probability of fai= ling to set up a SSL=20 connection, especially on it's first attempt. The wireshark output for the successful connection shows the same pattern a= s I see with 4.93=20 which always connects successfully at the first attempt. > It seems like your successful attempt are at > 95.142.156.18(mail.gridhost.co.uk), but fails at > 95.142.156.8(mail-beta.gridhost.co.uk), > 95.142.156.16(mail1-a.eqx.gridhost.co.uk) and > 95.142.156.28(mail4-e.eqx.gridhost.co.uk). >=20 > Could it be that you're finding a corner case in exim, because of that > circular dns resolving? mail.gridhost.co.uk does have multiple A > records, one of those has a PTR back to mail.gridhost.co.uk, where the > rest does not. I don't think there's any significance of the successful connection being m= ade with 95.142.156.18,=20 probably just the luck of the draw that it was that one that came up first = that time. There were just=20 as many failures with that address as with the other three over repeated re= tries in the test in my=20 earlier post in this thread. Anyway my latest tests restricted exim to use = only 95.142.156.18. > What SSL library is your exim compiled with? I installed exim from packages and can't see any obvious reference to which= SSL library it uses but I=20 assume it will be the standard version in base. =2D-=20 Mike Clarke