From owner-freebsd-questions@freebsd.org Mon Jun 22 21:03:59 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 968E433C3C9 for ; Mon, 22 Jun 2020 21:03:59 +0000 (UTC) (envelope-from lysfjord.daniel@smokepit.net) Received: from smtp-out.smokepit.net (smtp-out.smokepit.net [18.200.56.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-out.smokepit.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49rMMy4RwSz4QXr for ; Mon, 22 Jun 2020 21:03:58 +0000 (UTC) (envelope-from lysfjord.daniel@smokepit.net) Received: from cm-84.215.33.184.getinternet.no ([84.215.33.184] helo=smokepit.net) by smtp-out.smokepit.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jnTbf-0002nr-Ub for freebsd-questions@freebsd.org; Mon, 22 Jun 2020 21:03:55 +0000 Received: from yggdrasil.lan.smokepit.net ([10.0.0.200]) by smokepit.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1jnTbd-000P4Y-Iu for freebsd-questions@freebsd.org; Mon, 22 Jun 2020 23:03:55 +0200 Subject: Re: Exim - retry time not reached for any host To: freebsd-questions@freebsd.org References: <2534646.NQNxk83B2J@curlew> <2063278.3V7qYkmoPJ@curlew> <1854884.R0FQcr2YjX@curlew> From: Daniel Lysfjord Message-ID: Date: Mon, 22 Jun 2020 23:03:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1854884.R0FQcr2YjX@curlew> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Report: Action: no action Symbol: ARC_NA(0.00) Symbol: RCVD_VIA_SMTP_AUTH(0.00) Symbol: BAYES_HAM(-2.51) Symbol: FROM_HAS_DN(0.00) Symbol: TO_MATCH_ENVRCPT_ALL(0.00) Symbol: MIME_GOOD(-0.10) Symbol: TO_DN_NONE(0.00) Symbol: RCPT_COUNT_ONE(0.00) Symbol: RCVD_COUNT_ONE(0.00) Symbol: FROM_EQ_ENVFROM(0.00) Symbol: MIME_TRACE(0.00) Symbol: RCVD_TLS_ALL(0.00) Symbol: MID_RHS_MATCH_FROM(0.00) Message-ID: e3aa92c3-28e9-9f3d-68ef-29b62ccf5b41@smokepit.net X-Rspamd-Queue-Id: 49rMMy4RwSz4QXr X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.89 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[smokepit.net:s=loke]; NEURAL_HAM_MEDIUM(-1.01)[-1.010]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.200.56.156]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.026]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.15)[0.148]; DKIM_TRACE(0.00)[smokepit.net:+]; DMARC_POLICY_ALLOW(-0.50)[smokepit.net,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:18.200.0.0/16, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[84.215.33.184:received] 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 21:03:59 -0000 On 22.06.2020 18:13, Mike Clarke wrote: > 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, > > For some reason the service provider quotes mail3.gridhost.co.uk in their email setup instructions > 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 test while monitoring > 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 > 25272 > 465 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1 > TSval=3438884996 TSecr=0 > 2 0.021859743 95.142.156.18 192.168.1.13 TCP 74 > 465 > 25272 [SYN, ACK] Seq=0 Ack=1 Win=43440 Len=0 MSS=1452 SACK_PERM=1 > TSval=4269392837 TSecr=3438884996 WS=2048 > 3 0.021872274 192.168.1.13 95.142.156.18 TCP 54 > 25272 > 465 [RST] Seq=1 Win=0 Len=0 > > And that was all there was, absolutely nothing after the RST packet. Would be interesting to see what the contents of pkg#2 was compared to pkg#2 from the one below. You should reply with an ACK instead of just tossing an RST back at him. This means exim just closes the connection, for some reason. A "truss -ff" on exim would also be interesting, just to see what it's really doing. > > I then tried your earlier suggestion of 'exim -Rf @gmail.com' and much to my surprise the email > was sent > > No. Time Source Destination Protocol Length Info > 1 0.000000000 192.168.1.13 95.142.156.18 TCP 74 > 12424 → 465 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1 > TSval=2845252007 TSecr=0 > 2 0.021910067 95.142.156.18 192.168.1.13 TCP 74 > 465 → 12424 [SYN, ACK] Seq=0 Ack=1 Win=43440 Len=0 MSS=1452 SACK_PERM=1 > TSval=4253626233 TSecr=2845252007 WS=2048 > 3 0.021923963 192.168.1.13 95.142.156.18 TCP 66 > 12424 → 465 [ACK] Seq=1 Ack=1 Win=66752 Len=0 TSval=2845252029 TSecr=4253626233 > 4 0.033580346 192.168.1.13 95.142.156.18 TLSv1.2 364 > Client Hello > 5 0.055654137 95.142.156.18 192.168.1.13 TCP 66 > 465 → 12424 [ACK] Seq=1 Ack=299 Win=45056 Len=0 TSval=4253626267 TSecr=2845252041 > 6 0.064630882 95.142.156.18 192.168.1.13 TLSv1.2 1506 > Server Hello > 7 0.065507499 95.142.156.18 192.168.1.13 TCP 1506 > 465 → 12424 [PSH, ACK] Seq=1441 Ack=299 Win=45056 Len=1440 TSval=4253626276 > TSecr=2845252041 [TCP segment of a reassembled PDU] > 8 0.065515730 192.168.1.13 95.142.156.18 TCP 66 > 12424 → 465 [ACK] Seq=299 Ack=2881 Win=65344 Len=0 TSval=2845252073 > TSecr=4253626276 > 9 0.065646720 95.142.156.18 192.168.1.13 TLSv1.2 823 > Certificate, Server Key Exchange, Server Hello Done > 10 0.066717836 192.168.1.13 95.142.156.18 TLSv1.2 192 > Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message > 11 0.088334588 95.142.156.18 192.168.1.13 TCP 66 > 465 → 12424 [ACK] Seq=3638 Ack=425 Win=45056 Len=0 TSval=4253626299 > TSecr=2845252074 > 12 0.088559696 95.142.156.18 192.168.1.13 TLSv1.2 117 > Change Cipher Spec, Encrypted Handshake Message > 13 0.188244024 192.168.1.13 95.142.156.18 TCP 66 > 12424 → 465 [ACK] Seq=425 Ack=3689 Win=66752 Len=0 TSval=2845252196 > TSecr=4253626300 > 14 0.209855921 95.142.156.18 192.168.1.13 TLSv1.2 132 > Application Data > > ... 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 > again. This time the first 'exim -Rf' failed to release the email but a second attempt worked. > > So it looks as if, for me at least, exim 4.94 has a high probability of failing to set up a SSL > connection, especially on it's first attempt. > > The wireshark output for the successful connection shows the same pattern as I see with 4.93 > which always connects successfully at the first attempt. An intermediate solution would be to put an "exim -Rf" in your crontab, if moving to 4.94 is something you really want to do at this point:) > >> 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). >> >> 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 made with 95.142.156.18, > probably just the luck of the draw that it was that one that came up first that time. There were just > as many failures with that address as with the other three over repeated retries in the test in my > earlier post in this thread. Anyway my latest tests restricted exim to use only 95.142.156.18. > As I said, I was grasping at straws:) >> 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 > assume it will be the standard version in base. > OpenSSL then. As I'm using libreSSL, I've encountered weird bugs like this one before:)