Re: [exim-dev] Help debugging a tls smtp session

On Tue, Mar 28, 2023 at 01:48:25PM +0100, Andrew C Aitchison via Exim-dev wrote: > When I do STARTTLS -> CLIENTID -> NOOP > the CLIENTID gives the correct response code but the next command > fails (it doesn't have to be a NOOP) in a way suggesting that I have > lost synchronization. Sometimes

Re: [exim-dev] [Bug 2954] New: tls_eccurve (>= OpenSSL 3.0.0) dysfunctional

On Mon, Jan 02, 2023 at 03:25:17PM +, Jeremy Harris via Exim-dev wrote: > On 02/01/2023 04:16, Viktor Dukhovni via Exim-dev wrote: > > Mind you, things are a bit complicated with TLS 1.3, where ECDHE groups > > and FFDHE groups are unified and always negotiated, and setting th

Re: [exim-dev] [Bug 2954] New: tls_eccurve (>= OpenSSL 3.0.0) dysfunctional

On Sun, Jan 01, 2023 at 05:48:50AM +, admin--- via Exim-dev wrote: > It is impossible to set a custom tls_eccurve if Exim is compiled against > OpenSSL >= 3.0.0 due to a parenthesis error: The value of SSL_CTX_set1_groups > rather than the comparison against 0 is assigned to rv, which

Re: [exim-dev] [Bug 2911] New: setting dns_again_means_nonexist to a list containing @mx_ lookups causes segfault

On Fri, Aug 19, 2022 at 02:04:06PM +, admin--- via Exim-dev wrote: > https://bugs.exim.org/show_bug.cgi?id=2911 > > Bug ID: 2911 >Summary: setting dns_again_means_nonexist to a list containing > @mx_ lookups causes segfault >Product:

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

On Sun, Apr 07, 2019 at 07:25:38PM +, admin--- via Exim-dev wrote: > > If so, assuming the p for a parameter has been chosen as a "safe prime", > > q is entirely dependent on p - which we have from the PEM representation. > > Why do we care about loading q? > > FWIW: I have no idea. I

Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp

On Fri, Oct 22, 2021 at 10:34:20PM +0100, Simon Arlott via Exim-dev wrote: > It is likely that pipelining the QUIT results in the connection being > closed with outgoing data discarded. It's entirely possible that a > stateful firewall decides not to allow the half-closed connection to > transfer

Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp

On Fri, Oct 22, 2021 at 08:17:03PM -, Jasen Betts via Exim-dev wrote: > >> If this is really an exim bug, it's still worth correcting it, but you > >> should > >> really disable pipelining to yahoo, even when this bug will be resolved. > > > > Why would they bother advertising PIPELINING, if

Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp

> On 22 Oct 2021, at 11:45 am, admin--- via Exim-dev wrote: > > For what it's worth, by experience, you should avoid sending anything to any > yahoo domains using pipelining. They will just retaliate on you if you do it, > they will, for example, greylist the servers using pipelining but will

Re: [exim-dev] [Bug 2822] Issues with DHE ciphers - problems with GnuTLS implementation?

On Wed, Oct 20, 2021 at 12:00:17AM +, admin--- via Exim-dev wrote: > The 4th shows that on 2000+ connections in the logs nothing is actually using > a > DHE cipher suite either. Which makes a bug on the sslscan unlikely - esp. > since > it works as expected against gnutls-serv with the same

Re: [exim-dev] [Bug 2822] Issues with DHE ciphers - problems with GnuTLS implementation?

On Tue, Oct 19, 2021 at 09:21:24PM +, admin--- via Exim-dev wrote: > https://bugs.exim.org/show_bug.cgi?id=2822 > > --- Comment #2 from Jeremy Harris --- > a) you didn't say what version of GnuTLS, nor distribution of Exim > b) working out what you are trying to say in that wall of text is

Re: [exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

On 12 Aug 2021, at 5:05 pm, Jeremy Harris via Exim-dev wrote: > > Perhaps you mean OpenBSD, FreeBSD 12 dropped LibreSSL and went back to > > OpenSSL. > > Nope. There's a buildfarm animal listed as "FreeBSD latest" > showing as building with LibreSSL 3.3.3 Well, sure, LibreSSL is available

Re: [exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

On Thu, Aug 12, 2021 at 08:59:54PM +0100, Jeremy Harris via Exim-dev wrote: > On 12/08/2021 15:30, Viktor Dukhovni via Exim-dev wrote: > > You'd be able to drop the "danessl" library. > > You mean, the three source files. No library involved. Yes, the copy of the l

Re: [exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

On Thu, Aug 12, 2021 at 09:51:53AM +0100, Jeremy Harris via Exim-dev wrote: > > With OpenSSL 1.0.2 long EOL, is there any chance that newer versions > > of Exim could set the floor OpenSSL version to 1.1.1 and migrate to > > use the built-in DANE support? I'd can offer some help to get you > >

[exim-dev] DANE library for Exim + OpenSSL and upcoming OpenSSL 3.0.0 release.

The upcoming OpenSSL 3.0.0 release is now in beta and should ship some time in the next few months. This brings some low level changes to the library, that don't affect most applications, but may require changes in the legacy standalone DANE library I wrote for OpenSSL 1.0.0+. While the

Re: [exim-dev] [Bug 2730] New: EAI trace information doesn't log domains as U-labels

> On May 4, 2021, at 8:47 PM, John R. Levine via Exim-dev > wrote: > >>> https://bugs.exim.org/show_bug.cgi?id=2730 > >> It seems you're referring to: >> >> https://tools.ietf.org/html/rfc6531#section-3.7.3 >> >> When an SMTPUTF8-aware SMTP server adds a trace field to a message >> that

Re: [exim-dev] [Bug 2730] New: EAI trace information doesn't log domains as U-labels

> On May 4, 2021, at 2:48 PM, admin--- via Exim-dev wrote: > > https://bugs.exim.org/show_bug.cgi?id=2730 > > > RFC 6531 says you SHOULD do this. In IETF-ese "SHOULD" means MUST unless > there > is a compelling technical reason not to do it, not do this if you feel like > it. > (That's

Re: [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification

> On Mar 15, 2021, at 6:24 AM, Heiko Schlittermann via Exim-dev > wrote: > > If the next hop's hostname comes from insecure DNS, you're right. If the > next hop's hostname is hard-wired into the configuration (as typically > found in "use-a-smarthost" setups), I believe, it's useful to check

Re: [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification

For the record, the expectation is: - Absent DANE TLSA records, the literal MX hostname, which is of course insecurely obtained from MX records, so validation is mostly an exercise in futility. It would only mean something if MTA-STS were implemented, but Exim does not MTA-STS last I

Re: [exim-dev] [Bug 2704] DANE client-side documentation issues

On Sat, Mar 06, 2021 at 11:04:57PM +, admin--- via Exim-dev wrote: > https://bugs.exim.org/show_bug.cgi?id=2704 > > --- Comment #5 from Simon Arlott --- > I'd want to do DANE for all hosts that are DNSSEC signed but not require it > otherwise. This makes no sense. On what basis would you

Re: [exim-dev] [Bug 2704] DANE client-side documentation issues

On Sun, Feb 28, 2021 at 07:04:58AM +, admin--- via Exim-dev wrote: > This quoting was too selective. - Could you please post a corrected > clomplete pseudocode? I cannot specify exactly what is wrong/unclear > with the documentation (and come up with a patch) unless I have an > understanding

Re: [exim-dev] [Bug 2702] New: XCLIENT ESMTP extension

> On Feb 22, 2021, at 12:23 PM, admin--- via Exim-dev wrote: > > - Proper handling of the proxy address/port details, for logging > - We should consider re-calling the connect ACL, after deciding to accept the > XCLIENT command, to give the chance to re-evaluate connect-time decisions > with

Re: [exim-dev] Default received_headers_max should be increased dramatically

On Wed, Dec 02, 2020 at 12:57:18AM -0500, Phil Pennock via Exim-dev wrote: > I myself have only ever seen 30 reached when there's been a loop, but > raising the default to 100 is reasonable IMO. > > Anyone object? Basis for objection? If objecting, alternative > proposal? FWIW, Postfix

Re: [exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients

> On Aug 17, 2020, at 7:08 PM, admin--- via Exim-dev wrote: > > https://bugs.exim.org/show_bug.cgi?id=2265 > > --- Comment #8 from Jeremy Harris --- > Disabling multi_domain turns out to be Extremely Painful because we don't find > out > that DANE was used until deep in the transport, well

Re: [exim-dev] [Bug 2624] When using manualroute TLS certification is not safe

On Fri, Jul 17, 2020 at 07:26:20PM +, admin--- via Exim-dev wrote: > https://bugs.exim.org/show_bug.cgi?id=2624 Isn't this a duplicate of https://bugs.exim.org/show_bug.cgi?id=2594 > > Exim's manualroute should not replace the secure user provided hostname with > > anything else. > >

Re: [exim-dev] DANE support in Exim with OpenSSL

On Wed, Jul 08, 2020 at 06:54:14PM -0400, Phil Pennock wrote: > On 2020-07-06 at 01:07 -0400, Viktor Dukhovni via Exim-dev wrote: > > I would like recommend that when convenient, Exim should probably do the > > same. The documentation for the OpenSSL DANE API is at: > &

[exim-dev] DANE support in Exim with OpenSSL

openSSL 1.0.2 has passed EOL, and 1.1.1 is the primary LTS (indeed presently only one still supported) OpenSSL release, and OpenSSL 3.0 soon to enter beta. With that in mind, in Postfix I decided to replace the legacy DANE code (essentially the same as, and the original version of what is

Re: [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification

On Tue, Jun 09, 2020 at 04:41:33PM +0100, Jeremy Harris via Exim-dev wrote: > On 08/06/2020 14:51, Viktor Dukhovni via Exim-dev wrote: > > Yes: https://tools.ietf.org/html/rfc6125#appendix-B.4 > > > > The original reported is right. > > No, it's worse. If you

Re: [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification

On Mon, Jun 08, 2020 at 12:48:22PM +, admin--- via Exim-dev wrote: > https://bugs.exim.org/show_bug.cgi?id=2594 > > --- Comment #1 from Jeremy Harris --- > Can you locate a standards document specifying the name that should be checked > against the certificate? Yes:

Re: [exim-dev] [Bug 2298] tls_eccurve does not accept multiple entries

On Sun, Sep 29, 2019 at 07:22:46PM +, admin--- via Exim-dev wrote: > > I'm so far unconvinced that your use-case, for more-than-one but not the > > full > > set, is likely to be needed by enough people to be worth adding the support. > > Well, it can be very convenient to manually add a

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

On Tue, Mar 19, 2019 at 07:37:37AM +, Andrew C Aitchison via Exim-dev wrote: > > FWIW, Postfix 3.4, released a few weeks ago no longer supports OpenSSL > > versions prior to 1.0.2. > > Not sure from that whether Postfix 3.4 supports OpenSSL 1.0.2 ? It supports 1.1.x, 1.0.2, and nothing

Re: [exim-dev] [Bug 1895] Default groups for DH possibly backdoored

On Tue, Mar 19, 2019 at 02:43:04AM +, admin--- via Exim-dev wrote: > --- Comment #9 from Phil Pennock --- > IMO yes we're ready to drop support for older OpenSSL. We set a clear policy, > it's over a year (or two?) after that point, and other projects have adopted > similar policies. FWIW,

Re: [exim-dev] [Bug 2311] New: DANE verify fails with a TA-mode TLSA and a selfsigned sever cert

> On Sep 9, 2018, at 1:04 PM, Jeremy Harris via Exim-dev > wrote: > > https://lists.exim.org/lurker/message/20180904.122640.3cbadefb.en.html > > The subject says "self signed". > If it's not expected to work, perhaps you could explain why (on-list, > to the originator)? The OP is not

Re: [exim-dev] [Bug 2311] New: DANE verify fails with a TA-mode TLSA and a selfsigned sever cert

> On Sep 9, 2018, at 10:50 AM, admin--- via Exim-dev wrote: > > Summary: DANE verify fails with a TA-mode TLSA and a selfsigned >sever cert > Product: Exim > Version: 4.91 > Hardware: x86 >OS: Windows >

Re: [exim-dev] [Bug 2298] tls_eccurve does not accept multiple entries

> On Aug 10, 2018, at 4:24 AM, admin--- via Exim-dev wrote: > > Most uses should leave tls_eccurve at the default "auto". With a modern > version of OpenSSL this will support the full set of curves known to the > library. > > The use of accepting a list for tls_eccurve would be restricted

Re: [exim-dev] DNSSEC / log spam

On Sat, Jun 30, 2018 at 02:45:31AM -0400, Phil Pennock wrote: > On 2018-06-30 at 00:01 -0400, Viktor Dukhovni via Exim-dev wrote: > > So there is a potential solution, if you're > > willing to change how manage _res.options. > > No. Messing

Re: [exim-dev] [Bug 2264] DNS lookups should not chase CNAME chains

> On Jun 9, 2018, at 7:50 PM, Jeremy Harris via Exim-dev > wrote: > >> OK, that's what I'd expect, from this you can conclude >> that "nomx.example" has no MX records. > > With a retry count of one, and the current coding, it failed > when it hit that case. It was far simpler to loop once

Re: [exim-dev] [Bug 2264] DNS lookups should not chase CNAME chains

> On Jun 9, 2018, at 7:17 PM, Jeremy Harris via Exim-dev > wrote: > > It was: > > Zone: >cname.example. IN CNAME nomx.example. >nomx.example. IN A 192.0.2.1 > Query: >cname.example. IN MX ? > Response: >Answers: > cname.example. IN CNAME nomx.example. OK, that's

Re: [exim-dev] [Bug 2264] DNS lookups should not chase CNAME chains

> On Jun 9, 2018, at 5:27 PM, admin--- via Exim-dev wrote: > > > Git Commit changed: > > What|Removed |Added > > CC||g...@exim.org > >

Re: [exim-dev] [Bug 2266] TLS SNI should default set

> On Apr 20, 2018, at 7:41 PM, Phil Pennock wrote: > > Yes: when you define a "smarthost" Router, you use "manualroute" as the > driver, and choose the Transport to go with it. > > It's absolutely reasonable and normal in Exim to: > > 1. Have two similar Transports, referenced

Re: [exim-dev] [Bug 2266] TLS SNI should default set

> On Apr 20, 2018, at 7:07 PM, admin--- via Exim-dev wrote: > > Because unless you have DNSSEC, $host is derived via insecure means, the DNS. > DNSSEC means that DNS becomes secure for our purposes. > > If you have DNSSEC and want $host sent, then publish TLSA records to

Re: [exim-dev] TLS 1.3 *does not* mandate SNI.

> On Apr 17, 2018, at 8:10 PM, Viktor Dukhovni via Exim-dev <exim-dev@exim.org> > wrote: > > If they have a default certificate chain that works with TLS 1.2 > withholding it with TLS 1.3 seems rather rude... I'll chat with > David Benjamin, perhaps he'll have good r

Re: [exim-dev] TLS 1.3 *does not* mandate SNI.

> On Apr 17, 2018, at 8:03 PM, Viktor Dukhovni wrote: > >> This came up because, today, Google's servers are responding to TLS1.3 >> connections which don't send SNI with a self-signed certificate which >> has DN: >> >> OU=No SNI provided; please fix your client.,

Re: [exim-dev] TLS 1.3 *does not* mandate SNI.

> On Apr 17, 2018, at 7:09 PM, Phil Pennock wrote: > > I agree the spec shows we can argue it's not required, but the spec also > allows recipients to argue that it is required. > > This came up because, today, Google's servers are responding to TLS1.3 > connections which don't

[exim-dev] TLS 1.3 *does not* mandate SNI.

The mandatory to implement language in the TLS 1.3 spec does not mean "mandatory to use", in particular, while servers must tolerate the extension, clients are not obligated to sen d it: https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2 - The "server_name" [RFC6066] and

Re: [exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients

> On Apr 17, 2018, at 4:37 PM, admin--- via Exim-dev wrote: > > SNI for a DANE-advertising site has to be different than one that does not? > Sheesh. Does that not implicitly require that _all_ clients be DANE-aware, > or that _all_ DANE-advertising hosts be prepared to be

Re: [exim-dev] [Bug 2264] New: DNS lookups should not chase CNAME loops

> On Apr 17, 2018, at 3:58 PM, admin--- via Exim-dev wrote: > > Per the discussion starting > https://lists.dns-oarc.net/pipermail/dns-operations/2018-April/017449.html > we should trust that the resolver is doing the right thing, following CNAME > chains itself - meaning

Re: [exim-dev] [Bug 2266] New: TLS SNI should default set

> On Apr 17, 2018, at 4:17 PM, admin--- via Exim-dev wrote: > > Handling for DANE should be in issue 2265. DANE should stop using the tls_sni > SMTP Transport option and DANE handling is not in-scope for _this_ tracking > bug. > > IMO tls_sni should default to $domain,

Re: [exim-dev] [Bug 2255] TLS/SSL issue after upgading to 4.90

> On Apr 4, 2018, at 2:35 PM, admin--- via Exim-dev wrote: > > We are ready to attach any dumps of exim debug or wireshark if it's necessary. A "tshark" decode of the TLS handshake (text is better than screenshots) would be most useful, one where the session cache mode is

Re: [exim-dev] Exim 4.91 RC1

> On Mar 17, 2018, at 11:05 PM, Phil Pennock via Exim-dev > wrote: > > Oh: any preferences around OpenSSL 1.1.X for exim.org box? We currently > "drink our own champagne" when it comes to advice around OpenSSL > libraries and deprecation, with 1.0.2n in /opt/openssl/. > >

Re: [exim-dev] [Bug 2255] TLS/SSL issue after upgading to 4.90

> On Mar 13, 2018, at 12:55 PM, admin--- via Exim-dev wrote: > > You would have to set NO_TICKET on the IMAP server, not > Exim. > > What you could try, although I do not know whether it works, > is to set -no_ticket in Exim, thus disabling the disabling of > tickets.

Re: [exim-dev] [Bug 2255] TLS/SSL issue after upgading to 4.90

> On Mar 12, 2018, at 2:03 PM, admin--- via Exim-dev wrote: > > I was found differences between failure and success on 4.90_1 and 4.89. > But I'm absolutely puzzled how to copy readable packet description from > Wireshark to clipboard. There's an example of how to do this