Re: [exim] Routing failed deliveries through an ESP

[Viktor Dukhovni via Exim-users]

On Mon, Apr 17, 2023 at 08:54:37AM +0100, Graeme Fowler via Exim-users wrote:

> > How might I configure my routers to ignore an initial 5xx response from the
> > first router and attempt another (and maybe future) deliveries through an
> > alternate router?
> 
> If you get a 5xx error from the receiver's MX, you do the right thing and 
> abide by it. They're telling you they didn't want your message.

A mail transaction (transmission of a particular message), begins at the
MAIL command and ends at DOT.  Any errors outside that context are not
message specific.  In particular, they might simply reflect the
unwillingness of the host in question to accept any mail, which may not
be the case with other MX hosts.

In decades past, when now popular MTAs (Exim and Postfix) were new and
evolving their basic SMTP protocol features, it was not uncommon for for
some (IIRC Microsoft Exchange) receiving systems to intermittently
return 5XX when their load was too high.

Consequently, at least Postfix was then, and is still by default now
"tolerant" of 5XX greetings:

smtp_skip_5xx_greeting = yes

This is limited to just the initial banner, not EHLO or later, so
apparently transient misguided 5XX responses to EHLO are not a common
problem.  Therefore, I'd be inclined to consider also 5XX in response
to EHLO as a reason to abandom delivery and bounce the envelope.

-- 
Viktor.

-- 
## 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/

Re: [exim] Something like "domains_require_tls"

[Viktor Dukhovni via Exim-users]

On Wed, Mar 29, 2023 at 06:59:42PM +, Slavko via Exim-users wrote:

> Verifying name in case of SMTP has another problem -- which
> name to verify? Recipient's domain name? Name from MX? Or
> frpm PTR? You know they often differs, at least in that that MX
> is subdomain or even totally different domain. Anyway, how to
> know that PTR/MX's name, obtained via DNS, is not forged?

FWIW, DANE SMTP (rfc7672) answers that question.  The name to verify
(when validation is via DANE-TA(2) TLSA records) is any of:

- The TLSA base domain, or (typically same as),
- The MX hostname or
- The nexthop domain

> And finally, it seems that you expect, that cert will match
> name of MTA. OK, we can use name from MX, but what
> with systems which provides MTAs for thousands domains?

Makes little difference, one.com uses a modest pool of (tens of) MX
hosts for 1.2 million hosted domains.  Other hosting providers use
per-domain MX hosts, but the same underlying public key and matching
"3 1 1" TLSA record.  TLSA records can also be CNAMEs.

> Do you expect that all these domains have to use
> the same name in MX? Or do you expect thousands certs
> on that MTA?

Either will work, but a single MX hostname is simpler to operate.

> Or one cert with thousands names in SAN?

That's what SNI is for, but once again a shared MX hostname is better.

> Slavko
> https://www.slavino.sk/

-- 
Viktor.

P.S. By the way, your domain is DNSSEC-signed, you could with very modest
effort deploy DANE:

https://stats.dnssec-tools.org/explore/?slavino.sk

But, if so, make it robust.  First implement monitoring, and a cert/key
rollover process that avoids intermittent outages during key changes
by pre-publishing overlapping TLSA records that match both the old
and new key for a few TTLs before the new cert is deployed:

https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html

-- 
## 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/

Re: [exim] Something like "domains_require_tls"

[Viktor Dukhovni via Exim-users]

On Wed, Mar 29, 2023 at 12:24:22PM -0400, Bill Cole via Exim-users wrote:

> On 2023-03-29 at 04:46:17 UTC-0400 (Wed, 29 Mar 2023 10:46:17 +0200)
> Kirill Miazine via Exim-users  is rumored to have said:
> 
> > Exactly. The former preventing passive data collection, the later --
> > active. Still, if *I* were to state a legal requirement that certain
> > domains use TLS, I'd also ask for verification either via TLS or
> > DANE, because just TLS is a very small win.
> 
> You also need to understand that requiring verification as a 
> prerequisite for encryption has unintended consequences. If you only 
> allow encryption with verification, you will either break deliverability 
> entirely for some mail OR fall back to transport in the clear, *to the 
> same unverifiable host* which cannot be anything but less safe.

Sure, when doing ordinary opportunistic TLS, it is silly to fall back to
cleartext when/if authentication fails.

However, if TLS is *mandatory* as a matter of local policy (with no
cleartext fallback) to a *specific* set of destination domains, then it
may well make sense to also require authentication if expected to work
for the destinations in question.  This of course doesn't scale, it is
only something one might configure for a small set of "special" peers.

Opportunistic DANE TLS is a scalable alternative, in which the remote
domain's MX hosts signal the expectation of support for authenticated
transport in a downgrade-resistant manner (via DNSSEC TLSA records).
This makes it possible to get "zero-conf" authentication, to a large set
of generic destinations (currently ~3.75 million domains), which may or
may not include the "special" peer domains one really cares about.

It is (at least in Postfix) also possible to configure some of one's
"special" peer domains for required DANE authentication, rather than
required trusted X.509 CA authentication.  Also supported are local
"fingerprint" pins or per-destination trust-anchor CA certs or public
keys.  Once local policy enters the fray, there's a large spectrum of
possibilies.

-- 
Viktor.

-- 
## 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/

Re: [exim] Exim, OAUTH2 and gnutls problem

[Viktor Dukhovni via Exim-users]

On Sun, Mar 05, 2023 at 08:50:24PM +, ael via Exim-users wrote:

> > Your debug shows SMTP-leve success responses for both the data
> > phase for the message and the SMTP QUIT after it.
> 
> Thank you for confirming what I had suspected: the messages are
> essentially spurious, although perhaps revealing that some SMTP
> servers don't close properly: the usual suspects.. :-)

Because SMTP has application layer protocol message framing (SMTP
commands and responses), there is no need to lean on TLS to defend
against message truncation.  Since process and connection slots are a
finite resource, many SMTP do not bother with SSL shutdown, and just
tear down the TCP connection immediately after sending the "QUIT"
command or response.

Exim would ideally not log TLS errors related to connection tear down,
they have no relevance to SMTP.

-- 
Viktor.

-- 
## 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/

Re: [exim] renewing the SSL certificate doesn't work

[Viktor Dukhovni via Exim-users]

On Mon, Feb 27, 2023 at 10:21:56AM +, Gary Stainburn via Exim-users wrote:

>    generated-private-key.txt
> 
>    inflating: 27eff7f9e735cb3f.crt
>    inflating: 27eff7f9e735cb3f.pem

> The exim.conf file includes
> 
>    tls_privatekey  = /etc/pki/tls/certs/ringways.co.uk.key
>    tls_certificate = /etc/pki/tls/certs/exim.pem
> 
> I copied generated-private-key.txt to /etc/pki/tls/certs/ringways.co.uk.key

Correct.

> I copied 27eff7f9e735cb3f.crt to /etc/pki/tls/certs/exim.pem

I rather expect you should have copied the "27eff7f9e735cb3f.pem" file,
not the ".crt" file, which is likely a binary "DER" file.

To test whether the key is well-formed and matches the certificate:

pkeyfile=/some/where/generated-private-key.txt
certfile=/some/where/27eff7f9e735cb3f.pem

openssl pkey -in "$pkeyfile" -pubout -outform DER |
  openssl dgst -sha256 -binary | xxd -p -c32

openssl x509 -in "$certfile" -noout -pubkey |
  openssl pkey -pubin -pubout -outform DER |
  openssl dgst -sha256 -binary | xxd -p -c32

Neither command should output any error messages, and the output of both
should be the same (SHA256 fingerprint of the DER public key).

-- 
Viktor.

-- 
## 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/

Re: [exim] Is there a way to forcably disconnect remote session using tempfail 4xx code

[Viktor Dukhovni via Exim-users]

On Tue, Feb 21, 2023 at 09:30:41AM +, Jeremy Harris via Exim-users wrote:

> On 21/02/2023 03:14, Matt Bryant via Exim-users wrote:
> > Is there anyway in exim to force a disconnect but with a temporary
> > 4xx failure rather than a hard deny and 5xx error ???. I can see
> > 'drop' does the latter case but there seem no equivalent action/verb
> > or command to issue a tempfail and then disconnect.
> 
> No; that's a further departure from standards than Exim is coded to
> do.  You could raise an RFE if you have a convincing case for it.

FWIW, Postfix does drop connectiosn when the user-specified reject code
is 421 or 521.  Yes, server-initiated connection termination was not
part of the original design of SMTP ~50 years back when the Internet
was a kinder/gentler place.

-- 
Viktor.

-- 
## 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/

Re: [exim] Is there a way to forcably disconnect remote session using tempfail 4xx code

[Viktor Dukhovni via Exim-users]

On Tue, Feb 21, 2023 at 01:14:55PM +1000, Matt Bryant via Exim-users wrote:

> Is there anyway in exim to force a disconnect but with a temporary 4xx 
> failure rather than a hard deny and 5xx error ???. I can see 'drop' does 
> the latter case but there seem no equivalent action/verb or command to 
> issue a tempfail and then disconnect.

Have you tried configuring the reject code to "421".  The Exim SMTP
server should ideally take note of that and also disconnect.

-- 
Viktor.

-- 
## 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/

Re: [exim] suspected mail loop - Not

[Viktor Dukhovni via Exim-users]

On Thu, Feb 16, 2023 at 01:54:23PM +, graeme vetterlein via Exim-users 
wrote:

> However, tracking the original message down, it was from IBM and contains e.g.
> 
>   *29 matches for "Received" in buffer: 
> 1670514307.H745399P3100673.ybox.xxx *
> 
> and they all appear legitimate** , it really did pass through 29 servers !

An impressive hop count, did it go through mailing lists and then get
forwarded from a user's portable email address (an alumni alias or
similar) to their current actual mailbox?

On Fri, Feb 17, 2023 at 10:13:28AM +0100, Heiko Schlichting via Exim-users 
wrote:

> That's hard to answer. The following is set on our servers:
> 
> $ exim -bP received_headers_max
> received_headers_max = 50

FWIW, this (50) matches the Postfix default:

http://www.postfix.org/postconf.5.html#hopcount_limit

-- 
Viktor.

-- 
## 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/

Re: [exim] TLS authentication

[Viktor Dukhovni via Exim-users]

On Thu, Feb 16, 2023 at 08:18:46PM -0800, Ian Zimmerman via Exim-users wrote:

> An excellent suggestion, thanks. I think I got stuck in this unproductive
> (it seems) rut of authentication by verification because of two things:
> 
> - not immediately obvious how to *compute* the checksum to match in
>   the first place.  I don't expect it's just the checksum over the pem
>   file, is it?

No, PEM is not suitably canonical, for that you'd want the ASN.1 DER
form of the public key (or full certificate, whichever you prefer).

> - the documentation for the md5 (and sha1) expansion operators is cryptic:
> 
> If the string is a single variable of type certificate, returns the
> MD5 hash fingerprint of the certificate.

MD5 is deprecated, ideally Exim also support sha256 in the same role.
The hash should be computed over the DER form.

> what is a "variable of type certificate" in exim's proudly unityped
> macro language?

I am a Postfix maintainer, mostly lurking on this list, except when it
comes to TLS-related or especially DANE-related issues.  So can't answer
anything about Exim variables.  On the command-line, to extract the public
key and/or certificate digests:

# key digest
$ openssl x509 -in cert.pem -pubkey -noout |
openssl pkey -pubin -outform DER |
openssl dgst -sha256 -binary |
xxd -p -c32

# cert digest
$ openssl x509 -in cert.pem -outform DER |
openssl dgst -sha256 -binary |
xxd -p -c32

-- 
VIktor.

-- 
## 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/

Re: [exim] TLS authentication

[Viktor Dukhovni via Exim-users]

On Thu, Feb 16, 2023 at 09:17:51PM +, Jeremy Harris via Exim-users wrote:

> On 16/02/2023 21:09, Viktor Dukhovni via Exim-users wrote:
> > Some applications (want to) only accept client certificates issued by a
> > dedicated non-public CA, which amounts to an authorisation server
> 
> In exim usage that's a test on a certextract of the issuer of
> $tls_in_peercert, either just in ACL or as part of the
> serer_condition for an authenticator using the tls driver.
> 
> For either, the TLS session has to have been accepted first.

The problem is that any root CA can issue a subCA with any subject DN it
wants.  So just checking issuer names, and expecting these to uniquely
identify a private dedicated CA is not "safe".

There is no global X.500 namespace that ensures uniqueness of CA
"distinguished names", they're just made up.

So, if I can't bypass the system trust store, I would be more inclined
to check the issuer public key, not the issuer DN.  That said, an
OpenSSL application can just set the environemt and get a non-default
trust store location:


https://www.openssl.org/docs/manmaster/man3/X509_get_default_cert_dir_env.html

const char *X509_get_default_cert_dir_env(void);
const char *X509_get_default_cert_file_env(void);

Just set those enviroment variables (just between us friends, those
are "SSL_CERT_DIR" and "SSL_CERT_FILE") to a directory and file that
hold only the application-specific trust anchors, and the system
trust store would no longer be loaded by default.  This works
for OpenSSL, can't speak to GnuTLS...

-- 
Viktor.

-- 
## 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/

Re: [exim] TLS authentication

[Viktor Dukhovni via Exim-users]

On Thu, Feb 16, 2023 at 09:44:55PM +0100, Heiko Schlittermann via Exim-users 
wrote:

> > Is it at all possible with OpenSSL to stop the "system" location from
> > being checked? If not, that seems to make the use of TLS for client
> > authentication impossible because any certificate presented by
> > e.g. Google will pass verification. Am I reading this correctly?
> 
> IMHO it shouldn't be sufficient accept any client that just has a
> verified certificate ("authenticated"). You should check, if the client
> is "authorized", by checking required certificate attributes (issuer,
> subject, …)
> 

Some applications (want to) only accept client certificates issued by a
dedicated non-public CA, which amounts to an authorisation server.  If
the CA gave you a cert, you're an authorised user of the application
until the cert expires (or is revoked, if the server application has
access to timely CRLs, ...)

They drank the PKI coolaid.  I don't recommend this design.  Often
simpler to just use a list of authorised public keys instead.

-- 
Viktor.

-- 
## 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/

Re: [exim] TLS authentication

[Viktor Dukhovni via Exim-users]

On Mon, Feb 13, 2023 at 04:40:52PM -0800, Ian Zimmerman via Exim-users wrote:

>   With OpenSSL the certificates specified explicitly either by file or
>   directory are added to those given by the system default location.
> 
> Is it at all possible with OpenSSL to stop the "system" location from
> being checked? If not, that seems to make the use of TLS for client
> authentication impossible because any certificate presented by
> e.g. Google will pass verification. Am I reading this correctly?

In principle, yes, it just requires not loading the default certificate
store by not calling SSL_CTX_set_default_verify_paths(3).

So if you want to permit only clients with trusted certificates signed
by just your own CA, indeed you need to avoid loading the default cert
store.

On the other hand, much better to simply maintain an explicit table of
trusted client public keys and match these (by SHA256 fingerprint
perhaps).  Use a lookup table to check whether the client is authorised
or not.

-- 
Viktor.

-- 
## 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/

Re: [exim] Cutthrough Delivery to LMTP--Will it Work?

[Viktor Dukhovni via Exim-users]

On Sun, Feb 12, 2023 at 06:35:35PM +, Sabahattin Gucukoglu via Exim-users 
wrote:

> If I were to configure an SMTP transport in LMTP mode, can I
> cutthrough-deliver to it with an RCPT ACL? And what will happen if I
> have multiple recipients that have different post-data outcomes?

This breaks if one of the LMTP recipients of a multi-recipient message
is over-quota, or more generally in any situation where the LMTP
response after "dot" (end-of-message) accepts at least one, but all the
recipients.

So SMTP-to-LMTP cut-through should not be used with multi-recipient
envelopes.

-- 
Viktor.

-- 
## 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/

Re: [exim] got this garbage from HP

[Viktor Dukhovni via Exim-users]

On Wed, Jan 11, 2023 at 03:41:39AM -, Jasen Betts via Exim-users wrote:

> Exim seems to translate the lone LF into a space which breaks the
> message,

I'm somewhat surprised if Exim doesn't already treat LF in SMTP as
equivalent to CRLF, but perhaps that's the case.

> OTOH Gmail seems to convert it into a line break which fixes it.

FWIW, Postfix also tolerates LF-terminated lines in SMTP, they're
converted to CRLF if/when the message is relayed onward via SMTP.  So
tolerating them in Exim would not be unprecedented.

-- 
Viktor.

-- 
## 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/

Re: [exim] if you use openssl v3+ with exim

[Viktor Dukhovni via Exim-users]

On Fri, Dec 09, 2022 at 07:55:42PM +0100, Cyborg via Exim-users wrote:

> Guys, it was just a FYI without the FYI mark. I will add it next time :)

Yeah, that could have been helpful.

> There is nothing exim can do or should do. It's 100% caused by
> outdated legacy servers, ignoring the year 2009 CVE.
> 
> The issue is reproduceable with openssl s_client directly:
> 
> openssl s_client -connect 82.218.176.66:25 -starttls smtp

Indeed, and also with Postfix (built against OpenSSL 3.0):

$ posttls-finger -c -Lsummary -lmay  "[82.218.176.66]"
posttls-finger: SSL_connect error to 82.218.176.66[82.218.176.66]:25: -1
posttls-finger: warning: TLS library problem: error:0A000152:SSL 
routines::unsafe legacy renegotiation disabled:ssl/statem/extensions.c:879:

With OpenSSL 1.1.1:

$ posttls-finger -c -Lsummary -lmay  "[82.218.176.66]"
posttls-finger: Anonymous TLS connection established to 
82.218.176.66[82.218.176.66]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
posttls-finger: Server is anonymous

Interestingly, that server support anon-DH ciphers, which is not that
common.  Postfix is one of the few MTAs that enables ADH/AECDHE opportunistic
TLS, and indeed the server in question appears to be a very old Postfix
build:

220 circuit.inbus.at ESMTP Postfix

-- 
Viktor.

-- 
## 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/

Re: [exim] if you use openssl v3+ with exim

[Viktor Dukhovni via Exim-users]

On Fri, Dec 09, 2022 at 05:51:17PM +0100, Cyborg via Exim-users wrote:

> If a TLS connect is done to an outdated server using the old
> renegotiation methode, openssl 3 ends the connection with that error
> message.

> so, if you use openssl 3 and see this error message:
> 
> 2022-12-09 10:23:22 1p3ZbF-003Bdo-2L ==   R=dnslookup 
> T=remote_smtp defer (-37) H=mailin2.Z.z.z [a.b.c.d]: TLS session: 
> (SSL_connect): error:0A000152:SSL routines::unsafe legacy renegotiation 
> disabled
> 
> you need to contact the receiver and inform it , that hes using an 
> outdated mailserver software with MITM enabling ageold security holes.

Are there any destination domains or MX hostnames you're willing and
able to share which exhibit this issue?  If this is reproducible also
with e.g. Postfix and other MTAs, then there's nothing here for Exim
to do.  The remote server does not have an interoperable STARTTLS
implementation: something is broken on the Internet...

-- 
Viktor.

-- 
## 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/

Re: [exim] debugging tls handshake failure

[Viktor Dukhovni via Exim-users]

On Wed, Nov 23, 2022 at 06:25:29PM +, Julian Bradfield via Exim-users wrote:

> >If the server in question is "london.jcbradfield.org", then another
> >potential issue is a missing intermediate issuer certificate.  Your
> >certificate chain has only the leaf server certificate without the
> >required "R3" intermediate issuer certificate.  If using certbot, use
> >"fullchain.pem" not "cert.pem" (or the equivalent for a different
> >setup).
> 
> Indeed. That's only been the case recently. For the last 20 years,
> I've been presenting a self-signed certificate and had never noticed
> any problems. A few days ago I happened to notice my bank getting
> these TLS fatal alerts and then *not* falling through to plain text,
> which most others do.  So I started experimenting, but hadn't yet got
> as far as giving the full chain (largely, I admit, because I don't
> have certification internalized, and just follow recipes).

So, have you tried configuring a complete certificate chain (ideally
without the Android compatibility crutch).  Did that make any
difference?

If you disable TLS 1.3, the alerts will be unencrypted in a packet
capture, which you could then decode with "tshark" or wireshark without
needing to resort to TLS key export.

-- 
Viktor.

-- 
## 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/

Re: [exim] debugging tls handshake failure

[Viktor Dukhovni via Exim-users]

On Mon, Nov 21, 2022 at 09:41:12PM +, Julian Bradfield via Exim-users wrote:

> I should like to know what's happening here:
> 
> 2022-11-21 21:10:42 TLS error on connection from r218.notifications.rbs.co.uk 
> [130.248.154.218] (gnutls_handshake): A TLS fatal alert has been received.

OpenSSL would usually log the alert number (and associated text string),
from which one could infer more information about what the remote client
is unhappy about.  I'd hope that GnuTLS could also log this (or make the
alert info available to Exim to optionally log).

That said, the most common issues that remote clients are unhappy about
are untrusted certificates and expired certificates.  Perhaps you have a
Let's Encrypt certificate chain that includes a cross cert to the now
expired DST Root CA (for Android compatibility).  You can configure
certbot et. al. to build a chain that skips the cross cert, expecting
clients to support the ISRG root.

https://www.mail-archive.com/postfix-users@postfix.org/msg94314.html

-- 
Viktor.

-- 
## 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/

Re: [exim] debugging tls handshake failure

[Viktor Dukhovni via Exim-users]

On Mon, Nov 21, 2022 at 09:41:12PM +, Julian Bradfield via Exim-users wrote:

> I should like to know what's happening here:
> 
> 2022-11-21 21:10:42 TLS error on connection from r218.notifications.rbs.co.uk 
> [130.248.154.218] (gnutls_handshake): A TLS fatal alert has been received.
> 

If the server in question is "london.jcbradfield.org", then another
potential issue is a missing intermediate issuer certificate.  Your
certificate chain has only the leaf server certificate without the
required "R3" intermediate issuer certificate.  If using certbot, use
"fullchain.pem" not "cert.pem" (or the equivalent for a different
setup).

-- 
Viktor.

-- 
## 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/

Re: [exim] OpenSSL IOT woes

[Viktor Dukhovni via Exim-users]

On Mon, Oct 03, 2022 at 07:22:29PM +0100, Jeremy Harris via Exim-users wrote:

> On 03/10/2022 18:08, Jeremy Harris via Exim-users wrote:
> > Could the min/max protocol stuff mentioned in
> > https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html
> > be affecting it?
> > Exim has no SSL_CONF_* calls currently; probably never has in it's
> > history.
> 
> Bingo.  The value given by SSL_CTX_get_max_proto_version()
> is TLS1_2_VERSION.
> 
> If I slam a SSL_CTX_set_max_proto_version() call for SSL_v3
> in right before twiddling the option bits, all is good.

You probably meant "min", rather than "max".

> I conclude:
> 
> - the limit value is kept separate from the bitfield
> setting the same essential information, in the library

The bit fields are a legacy interface.  The preferred interface is the
new min/max range, which caps the protocol version range above and
below. You can still use the bit fields to create "holes" in that
range, though this is generally a bad idea.

> - this is a poor choice

I disagree.

> - any application written before those limit value APIs
>were introduced and which did it's own bit-setting
>(as documented) configuration for TLS versions,
>will be broken in the same way.  Back-compatibility?
>What does that mean?

Not broken, just constrained by the range settings in the system-wide
openssl.cnf, which is the whole purpose of that file.

> - the *lack* of documentation that the limit value
>overrides the bitfield, having made the choice
>to keep them separate is... words fail me.

There is no override, both sets of restrictions are enforced.  The
documentation of SSL_CTX_new(3) reads in part:

If you want to limit the supported protocols for the version
flexible methods you can use SSL_CTX_set_min_proto_version(3),
SSL_set_min_proto_version(3), SSL_CTX_set_max_proto_version(3) and
SSL_set_max_proto_version(3) functions. Using these functions it is
possible to choose e.g. TLS_server_method() and be able to negotiate
with all possible clients, but to only allow newer protocols like
TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3.

The list of protocols available can also be limited using the
SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1,
SSL_OP_NO_TLSv1_3, SSL_OP_NO_TLSv1_2 and SSL_OP_NO_TLSv1_3 options
of the SSL_CTX_set_options(3) or SSL_set_options(3) functions, but
this approach is not recommended. Clients should avoid creating
"holes" in the set of protocols they support. When disabling a
protocol, make sure that you also disable either all previous or all
subsequent protocol versions. In clients, when a protocol version is
disabled without disabling all previous protocol versions, the
effect is to also disable all subsequent protocol versions.

-- 
Viktor.

-- 
## 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/

Re: [exim] OpenSSL IOT woes

[Viktor Dukhovni via Exim-users]

On Mon, Oct 03, 2022 at 06:08:58PM +0100, Jeremy Harris via Exim-users wrote:

> > Presumably it'll work for you if you connect to:
> > 
> >  [dnssec-stats.ant.isi.edu]:25
> 
> It does.

Ok, so the client side is not the problem...

> > So the barrier is some interaction between Exim and OpenSSL that makes
> > TLS 1.0 and 1.1 unavailable.
> 
> Yes, or the system my test server is running on forcing no TLSv1.1 support
> (do/can they do that?)

Yes, in the "openssl.cnf" file located in the directory reported by

$ openssl version -d
OPENSSLDIR: "/etc/pki/tls"

On my Fedora 36 system this has:

[ ssl_module ]
system_default = crypto_policy

[ crypto_policy ]
.include = /etc/crypto-policies/back-ends/opensslcnf.config

Which in turn has:

CipherString = 
@SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
Ciphersuites = 
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256
TLS.MinProtocol = TLSv1.2
TLS.MaxProtocol = TLSv1.3
DTLS.MinProtocol = DTLSv1.2
DTLS.MaxProtocol = DTLSv1.2
SignatureAlgorithms = 
ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224

[openssl_init]
alg_section = evp_properties

[evp_properties]
rh-allow-sha1-signatures = yes

The default configuration of Postfix 3.6 explicitly overrides the TLS minimum
version:

$ postconf -d smtpd_tls_protocols
smtpd_tls_protocols = >=TLSv1

Perhaps Exim has no such facility, or does not use it by default.


https://github.com/vdukhovni/postfix/blob/ae9d7a6a631f4b164702a55c7674c50afc610f75/postfix/src/tls/tls_server.c#L572-L577

https://github.com/vdukhovni/postfix/blob/ae9d7a6a631f4b164702a55c7674c50afc610f75/postfix/src/tls/tls_server.c#L422-L428

> Could the min/max protocol stuff mentioned in
> https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html
> be affecting it?

Yes.

> Exim has no SSL_CONF_* calls currently; probably never has in it's
> history.

Right, but the openssl.cnf file does set various parameters.  You don't
have to support the "stringy" SSL_CONF API, you can set the min/max
protocol versions directly if that's preferred.

One option is to allow the administrator to specify a non-default
configuration file, and perform explicit library initialisation early,
before doing anything with OpenSSL.  That config file can be more
liberal than what's found in the default system-wide file.

> I'm not sure how to debug.  Does OpenSSL offer detailed internal
> debug the way that GnuTLS does?

You can enable protocol message debugging, but support for debugging
internal configuration actions is mostly not there.  In particular,
SSL_CONF command processing is silent.

-- 
Viktor.

-- 
## 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/

Re: [exim] OpenSSL IOT woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 30, 2022 at 09:18:08PM +0100, Jeremy Harris via Exim-users wrote:

> On 30/09/2022 20:28, Viktor Dukhovni via Exim-users wrote:
> > Does "s_client -tls1_1 -cipher ALL:@SECLEVEL=0" work?  Let's first
> > sort that out.
> 
> It does not.  The same Fatal Alert.

Presumably it'll work for you if you connect to:

[dnssec-stats.ant.isi.edu]:25

The relevant software versions are:

$ rpm -q postfix openssl
postfix-3.6.4-1.fc36.x86_64
openssl-3.0.5-1.fc36.x86_64

And indeed Postfix is linked against OpenSSL 3.x:

$ ldd /usr/libexec/postfix/smtpd
...
libssl.so.3 => /lib64/libssl.so.3 (0x7fdc3588f000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x7fdc35467000)
...

So the barrier is some interaction between Exim and OpenSSL that makes
TLS 1.0 and 1.1 unavailable.  Clients that don't support TLS 1.2 are of
course increasingly rare, but pockets of holdouts still linger on...

-- 
Viktor.

-- 
## 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/

Re: [exim] OpenSSL IOT woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 30, 2022 at 08:14:20PM +0100, Jeremy Harris via Exim-users wrote:

> >  Does its cipherlist end with ":@SECLEVEL=0" (or does it explicitly
> >  set the security level via the OpenSSL API).
> 
> The latter.
> 
> I can add calls to read out bit of setup just before SSL_accept, if you
> can suggest one.

I'm out of ideas.  All I can say with certainty is that underlying
OpenSSL library (Fedora36 OpenSSL 3.0.5, same as yours I think) is
perfectly happy to do TLS 1.1 when SECLEVEL=0.  Why that's not
happening with Exim is outside my area of expertise.

> If it matters: I'm using the OP's very minimal Client Hello,
> not s_client.

Does "s_client -tls1_1 -cipher ALL:@SECLEVEL=0" work?  Let's first
sort that out.

-- 
Viktor.

-- 
## 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/

Re: [exim] OpenSSL IOT woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 30, 2022 at 07:05:52PM +0100, Jeremy Harris via Exim-users wrote:
> On 30/09/2022 18:34, Viktor Dukhovni via Exim-users wrote:
> > Do you also have a TLS version floor?  "protocol version" sure sounds
> > like it.
> 
> Not as far as I know, and
>openssl_options = -no_sslv3 -no_tlsv1_1 -no_tlsv1
> doesn't change the result.

That sets a floor, rather than clearing it.  You're explicitly
turning off SSL 3.0, TLS 1.0 and TLS 1.1.

> There is indeed a "protocol version" fatal alert sent according to
> wireshark.

That's what it looks like.

> > Anyway, this is perhaps a distraction from the GnuTLS issue,
> > which you've identifies IIRC (SSL 3.0-compatible handshake with no TLS
> > extensions fails against Exim + GnuTLS as reported).
> 
> While it's true the Exim bug with GnuTLS is now fixed, having the
> regression test passing for both the TLS libraries we claim to support
> would be good.  $subject changed to reflect that.

Do you have a test server reachable from the Internet that's running the
version of Exim in question over OpenSSL?  Does its cipherlist end with
":@SECLEVEL=0" (or does it explicitly set the security level via the
OpenSSL API).

The Postfix server on the DANE survey host linked with OpenSSL 3.0.5
(Fedora 36) completes a TLS 1.1 handshake just fine:

$ openssl s_client -quiet -starttls smtp -tls1_1 -cipher "ALL:@SECLEVEL=0" 
-connect $(uname -n):25
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = dnssec-stats.ant.isi.edu
verify return:1
250 CHUNKING
quit
221 2.0.0 Bye

An Exim server linked with OpenSSL 3.0.5 should be able to do likewise,
barring protocol version floors, cipherlists that exclude SHA1, ...

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 30, 2022 at 06:02:35PM +0100, Jeremy Harris via Exim-users wrote:
> On 30/09/2022 16:46, Viktor Dukhovni via Exim-users wrote:
> >>  00C0C6000800:error:0A0C0103:SSL 
> >> routines:tls_process_key_exchange:internal 
> >> error:ssl/statem/statem_clnt.c:2254:
> >>
> >> I'll try to find some time to file a bug.  Feel free to beat me to it.
>
> > Actually, this is expected behaviour:
> > 
> >  https://github.com/openssl/openssl/issues/15335#issuecomment-843843617
> 
> Including that error line?
> 
> 
> No obvious difference with that "ciphers"   :-
> 
> 17:39:23 59777 SMTP>> 220 TLS go ahead
> 17:39:23 59777 Calling SSL_accept
> 17:39:23 59777 SSL hshake_start: before SSL initialization
> 17:39:23 59777 SSL SSL_accept,state_chg: before SSL initialization
> 17:39:23 59777 SSL SSL_accept,state_chg: before SSL initialization
> 17:39:23 59777 SSL write,alert fatal:protocol version
> 17:39:23 59777 SSL SSL_accept,hshake_exit: error in error
> 17:39:23 59777 TLS error '(SSL_accept): error:100C0102:BIO routines::passed a 
> null parameter'

Do you also have a TLS version floor?  "protocol version" sure sounds
like it.  Anyway, this is perhaps a distraction from the GnuTLS issue,
which you've identifies IIRC (SSL 3.0-compatible handshake with no TLS
extensions fails against Exim + GnuTLS as reported).

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 30, 2022 at 11:23:47AM -0400, Viktor Dukhovni via Exim-users wrote:

> I just reproduced the problem with a fresh build of 3.0.6-dev from
> github (built on FreeBSD 12.3):
> 
> $ LD_LIBRARY_PATH=/var/tmp/openssl/lib /var/tmp/openssl/bin/openssl 
> s_client -starttls smtp -tls1_1 -quiet -connect localhost:25
> Can't use SSL_get_servername
> depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=1 C = US, O = Let's Encrypt, CN = R3
> verify return:1
> depth=0 CN = <...>
> verify return:1
> 00C0C6000800:error:0A0C0103:SSL 
> routines:tls_process_key_exchange:internal 
> error:ssl/statem/statem_clnt.c:2254:
> 
> I'll try to find some time to file a bug.  Feel free to beat me to it.

Actually, this is expected behaviour:

https://github.com/openssl/openssl/issues/15335#issuecomment-843843617

To get SHA1 ciphers to work, one needs to set the security level to 0.

$ openssl s_client -quiet -starttls smtp -tls1_1 -cipher "ALL:@SECLEVEL=0" 
-connect $(uname -n):25
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = <...>
verify return:1
250 CHUNKING
quit
221 2.0.0 Bye

Jeremy, if you retry with "@SECLEVEL=0", you should see OpenSSL work as
expected.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 30, 2022 at 11:05:57AM -0400, Viktor Dukhovni via Exim-users wrote:

> > Clearing either no_tlsv1_1 or no_sslv3 has no effect.
> 
> Of course, if there's no support, the CLI flags don't matter.  TLS 1.1 does
> not work with OpenSSL 3.0.5, Though it looks more like a bug to me:
> 
> $ openssl s_client -quiet -starttls smtp -tls1_1 -connect $(uname -n):25
> depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
> verify return:1
> depth=1 C = US, O = Let's Encrypt, CN = R3
> verify return:1
> depth=0 CN = dnssec-stats.ant.isi.edu
> verify return:1
> C0A1EBA5F27F:error:0A0C0103:SSL 
> routines:tls_process_key_exchange:internal 
> error:ssl/statem/statem_clnt.c:2252:

I just reproduced the problem with a fresh build of 3.0.6-dev from
github (built on FreeBSD 12.3):

$ LD_LIBRARY_PATH=/var/tmp/openssl/lib /var/tmp/openssl/bin/openssl 
s_client -starttls smtp -tls1_1 -quiet -connect localhost:25
Can't use SSL_get_servername
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = <...>
verify return:1
00C0C6000800:error:0A0C0103:SSL 
routines:tls_process_key_exchange:internal error:ssl/statem/statem_clnt.c:2254:

I'll try to find some time to file a bug.  Feel free to beat me to it.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 30, 2022 at 03:48:18PM +0100, Jeremy Harris via Exim-users wrote:

> OpenSSL 3.0.5 5 Jul 2022running on Fedora 36
> 
> I think using the distro standard package
> openssl-1:3.0.2-4.fc36.x86_64
> (though I note the numbers don't exactly line up)
>
> The failure mode is a TLS Alert complaining about version
> (I forget the precise wording, sorry)
> and followed by what looks like a library internal bug-triggered
> error for a BIO operation error.
> 
> Clearing either no_tlsv1_1 or no_sslv3 has no effect.

Of course, if there's no support, the CLI flags don't matter.  TLS 1.1 does
not work with OpenSSL 3.0.5, Though it looks more like a bug to me:

$ openssl s_client -quiet -starttls smtp -tls1_1 -connect $(uname -n):25
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = dnssec-stats.ant.isi.edu
verify return:1
C0A1EBA5F27F:error:0A0C0103:SSL 
routines:tls_process_key_exchange:internal error:ssl/statem/statem_clnt.c:2252:

Things work better with TLS 1.2:

$ openssl s_client -quiet -starttls smtp -tls1_2 -connect $(uname -n):25
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = dnssec-stats.ant.isi.edu
verify return:1
250 CHUNKING
QUIT
221 2.0.0 Bye

If this is still broken in 3.0.6-dev, a bug report may be appropriate.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 30, 2022 at 02:09:19PM +0200, Cyborg via Exim-users wrote:

> My POV here: "why waiting".  Encryption doesn't slow down todays cpus 
> anymore as it has 15 years ago, same for a smartphone soc.

Mobile devices have batteries, and large RSA keys have a real packet
size and latency cost.  Keys larger than 2048-bits are largely futile.
No plausible classical attack can brute-force them.  Various OS packages
are typically signed with 2048-bit keys, transmitted via TLS connections
authenticated with 2048-bit RSA, ...

My take is that 3072-bit RSA and especially 4096-bit RSA is for most
users a fashion statement, rather than a technically sound choice.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 30, 2022 at 02:04:51PM +0100, Jeremy Harris via Exim-users wrote:

> Ah, the difference is the total lack of TLS extensions
> in the Client Hello.
> 
> Commit ece23f05d6 pushed.
> 
> Note that this client won't work against current OpenSSL
> default builds.

When you say "current" you mean 3.1-dev?  What is the observed failure
mode?  It "works" against the latest OpenSSL 1.1.1 (the server responds
with server hello, certificate, ..., server hello done).

Perhaps TLS 1.1 is not enabled in your build?

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 30, 2022 at 01:21:21AM -, Jasen Betts via Exim-users wrote:

> > With the older Exim, GnuTLS appears to consider six cipher suites before
> > finding a suitable choice (after skipping all the DHE candidates).
> 
> I can disable DHE_RSA by saying
> 
> tls_require_ciphers = NORMAL:%COMPAT:!DHE-RSA
> 
> and now it chooses the same suite that 4.94 was choosing 
> but there is still an error after the suite is chosen.

You could keep debugging GnuTLS, or just use a version of Exim with TLS
support via OpenSSL, which will likely just work.  Your call.

Some resource that GnuTLS expects to use is not available when it is
initialised by the problem version of Exim.  If not a DHE group,
likely something else related cryptography.  To debug, you'd need
to figure out where that error is raised.  Lack of help from strace
is not unexpected.

-- 
Viktor.

-- 
## 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/

Re: [exim] Setting Exim to always remove DKIM signatures

[Viktor Dukhovni via Exim-users]

On Thu, Sep 29, 2022 at 04:11:35PM +, Slavko via Exim-users wrote:

> RFC 6376, section 4.2:
> 
> Signers SHOULD NOT remove any DKIM-Signature header fields from
> messages they are signing, even if they know that the signatures
> cannot be verified.

SHOULD NOT is not "MUST NOT".  Especially if the signatures are one's
own from a prior internal SMTP relay hop.  And there is RFC policy,
there are times even good reasons to ignore "MUST NOT".

The imperative terms in RFCs are about what is necessary to be sure
to interoperate.  If one is willing to occasionally risk not being
able to interoperate, one can freely ignore all RFC requirements,
at one's own risk.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Thu, Sep 29, 2022 at 10:36:55AM +0200, Cyborg via Exim-users wrote:

> There is a BSI ( the german cybersecurity agency ) guideline for
> german corps and gov entities, which states, that 2048 bit RSA keys,
> for any purpose, should not be used anymore in 2022.

The BSI stance is unreasonable for almost all users and threat models.
Perhaps there are some sensitive military or diplomatic applications in
which RSA is used in key transport mode, and where it is anticipated
that classical brute-force attacks with 2^112 cost (~10^12 times the
cost of the largest scale attacks demonstrated to date) are somehow
possible and economically justified, and 2^128 saves the day.

> Can you state, why you think, that this 2048 bit key is only used for 
> authentication, rather than for TLS encryption? I think, it is used, as 
> it's presented on port 25.

Other than with outdated RSA key transport, almost all TLS clients
prefer DHE or ECDHE, where RSA just signs (authenticates) the key
exchange, rather than encrypts or decrypts the key.

Clients old enough to not support DHE or ECDHE generally have more
severe problems than vulnerability to 2^112 attacks.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Thu, Sep 29, 2022 at 03:31:59AM -, Jasen Betts via Exim-users wrote:

> This client called itself "Paradox" in the SMTP ehlo, I think it's
> probably an alarm system. I have an example TLS hello packet now:
> 
> 160343013f0302923e9988d02b8fc276bdcf02ccb6fc3900
> d052828c650ccd8c020040180033003900450088001600350084002f0041
> 000a000500040100

The "tshark" decode for this Client Hello is:

Transport Layer Security
SSLv3 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: SSL 3.0 (0x0300)
Length: 67
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 63
Version: TLS 1.1 (0x0302)
Random: 
923e9988d02b8fc276bdcf02ccb6fc3900d052828c650ccd8c020040
GMT Unix Time: Feb  7, 2106 01:28:15.0 EST
Random Bytes: 
923e9988d02b8fc276bdcf02ccb6fc3900d052828c650ccd8c020040
Session ID Length: 0
Cipher Suites Length: 24
Cipher Suites (12 suites)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)

So this client seems to support SSL 3.0 through TLS 1.1, with RSA and
mostly SHA1.  The TLS Client HELLO includes no TLS 1.0 extensions.

> tls_require_ciphers expands to "NORMAL:%COMPAT"
> 433834 TLS: preloading cipher list for server: NORMAL:%COMPAT
> 433834 GnuTLS<2>: added 6 protocols, 29 ciphersuites, 19 sig algos and 10 
> groups into priority list
> 433838 Initialising GnuTLS server params
> 433838 GnuTLS<2>: checking 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1) for 
> compatibility

First client cipher chosen.  But does the server support TLS 1.1 and
below?  Perhaps Exim (or GnuTLS) defaults to TLS 1.2 or higher?

> 433838 GnuTLS<2>: Selected (RSA) cert based on ciphersuite 0.33: 
> GNUTLS_DHE_RSA_AES_128_CBC_SHA1
> 433838  error -56 from gnutls_handshake: The requested data were not 
> available.

Here, the first ciphersuite is chosen, but perhaps then fails for lack
of appropriate DHE parameters?  There may be some adverse interaction
between DHE group selection and TLS 1.1 and below in the newer Exim.

> 435388 TLS: no SNI presented in handshake.
> 435388 GnuTLS<2>: checking 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1) for 
> compatibility
> 435388 GnuTLS<2>: checking 00.39 (GNUTLS_DHE_RSA_AES_256_CBC_SHA1) for 
> compatibility
> 435388 GnuTLS<2>: checking 00.45 (GNUTLS_DHE_RSA_CAMELLIA_128_CBC_SHA1) for 
> compatibility
> 435388 GnuTLS<2>: checking 00.88 (GNUTLS_DHE_RSA_CAMELLIA_256_CBC_SHA1) for 
> compatibility
> 435388 GnuTLS<2>: checking 00.16 (GNUTLS_DHE_RSA_3DES_EDE_CBC_SHA1) for 
> compatibility
> 435388 GnuTLS<2>: checking 00.35 (GNUTLS_RSA_AES_256_CBC_SHA1) for 
> compatibility
> 435388 GnuTLS<3>: ASSERT: 
> ../../../lib/ext/server_name.c[gnutls_server_name_get]:239
> 435388 GnuTLS<2>: Selected (RSA) cert based on ciphersuite 0.35: 
> GNUTLS_RSA_AES_256_CBC_SHA1

With the older Exim, GnuTLS appears to consider six cipher suites before
finding a suitable choice (after skipping all the DHE candidates).

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Wed, Sep 28, 2022 at 07:58:27PM -, Jasen Betts via Exim-users wrote:

> > You said that ECDHE ciphers are not available, but a default connection
> > with "posttls-finger" gives TLS 1.3 with an ECDHE cipher:
> 
> I did say that, I was working from scraped web pages of a third-party
> analysis at the time... I've since found testssl.sh (which is easier to
> use) and by tweaking the priority string have turned on the same
> cyphers.
> 
> accordingto testssl.sh The only feature currently missing is
> maximum_fragment_size,  (and the ability to support several client platforms)
> I think I may have to run a bisection search on the source code to figure out
> where that fell off.

That particular extension is hardly likely to be particularly important.
I think you're barking up the wrong tree.  Whatever the problem is, it
is likely somewhere entirely different.

You need to analyse some failed handshake full-packet captures  with
"tshark", and collected detailed logs from the clients that are having
problems.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Wed, Sep 28, 2022 at 05:08:37PM +0200, Cyborg via Exim-users wrote:

> But your key is a bit short. I suggest to upgrade it to at least 4096 bits.

I strongly disagree.  There's no need to be a crypto
exhibitionist/maximalist.  The vast majority of issuing CA RSA keys are
2048-bits.  The use of 4096-bit keys is pointless waste of CPU,
especially given that these are *authentication* keys, not encryption
keys, so don't need to remain secure after they're replaced.

And keep in mind tht SMTP clients mostly still ignore the server
certificate entirely.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Wed, Sep 28, 2022 at 09:39:43AM -0400, Viktor Dukhovni via Exim-users wrote:
> On Tue, Sep 27, 2022 at 02:39:19AM -, Jasen Betts via Exim-users wrote:
> 
> > it's reachable here:  eximtest.duckdns.org
> > 
> > eg: $  testssl eximtest.duckdns.org:465
> > 
> 
> You said that ECDHE ciphers are not available, but a default connection
> with "posttls-finger" gives TLS 1.3 with an ECDHE cipher:
> 
> posttls-finger: Untrusted TLS connection established
> to eximtest.duckdns.org[2400:8907::f03c:93ff:fe2d:f557]:25:
> TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
> key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits)
> server-digest SHA256
> 
> If I force TLS 1.2, I get (slightly less detailed cipher breakdown for
> TLS 1.2 in Postfix):
> 
> posttls-finger: Untrusted TLS connection established
> to eximtest.duckdns.org[2400:8907::f03c:93ff:fe2d:f557]:25:
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 
> Either this is not the server in question, or ECDHE is working just
> fine...

Ditto on port 465 and with IPv4:

$ posttls-finger -c -lmay -Lsummary -w -o inet_protocols=ipv4 -p TLSv1.2 
"[eximtest.duckdns.org]:465"
posttls-finger: Untrusted TLS connection established
to eximtest.duckdns.org[172.105.179.7]:465:
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Tue, Sep 27, 2022 at 02:39:19AM -, Jasen Betts via Exim-users wrote:

> it's reachable here:  eximtest.duckdns.org
> 
> eg: $  testssl eximtest.duckdns.org:465
> 

You said that ECDHE ciphers are not available, but a default connection
with "posttls-finger" gives TLS 1.3 with an ECDHE cipher:

posttls-finger: Untrusted TLS connection established
to eximtest.duckdns.org[2400:8907::f03c:93ff:fe2d:f557]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits)
server-digest SHA256

If I force TLS 1.2, I get (slightly less detailed cipher breakdown for
TLS 1.2 in Postfix):

posttls-finger: Untrusted TLS connection established
to eximtest.duckdns.org[2400:8907::f03c:93ff:fe2d:f557]:25:
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Either this is not the server in question, or ECDHE is working just
fine...

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTTS woes

[Viktor Dukhovni via Exim-users]

On Fri, Sep 23, 2022 at 05:50:29AM -, Jasen Betts via Exim-users wrote:

> My testing mainly involves telling exim to listen on poert 443 with
> implicit SSL and then hitting it with www.sslcheck.com 
> 
>   tls_on_connect_ports = 465:443
>   daemon_smtp_ports = 25:465:587:443
> 
> and this testing also shows a change in the availalbe suites.
> 
> It mainly seems to be ECDH suites that are no longer avaialable.

There's a big difference between "ECDH" and "ECDHE", the "fixed" DH/ECDH
ciphers are deprecated, rarely used, and should not be used.  While DHE
and ECDHE ciphers are preferred.  If GnuTLS disabled these, no harm done.

If you post the name of the server, it would be possible for others to
confirm your observations and perhaps offer more detailed help.

-- 
Viktor.

-- 
## 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/

Re: [exim] SSL_renegotiate:wrong ssl version

[Viktor Dukhovni via Exim-users]

On Sat, Sep 10, 2022 at 01:59:50PM +0200, Cyborg via Exim-users wrote:

> 250 HELP
> HELO smtp.example.com
> 250 smtp.target.de Hello smtp.example.com [83.246.32.110]
> MAIL FROM:
> 250 OK
> RCPT TO:
> RENEGOTIATING
> 140149325708800:error:1420410A:SSL routines:SSL_renegotiate:wrong ssl 
> version:ssl/ssl_lib.c:2143:

Your mistake is to expect a default invocation of s_client(1) to provide
a "transparent" channel.  This is not the case, instead s_client(1)
interprets certain input lines specially (from 1.1.1 manpage):

CONNECTED COMMANDS
   If a connection is established with an SSL server then any data
   received from the server is displayed and any key presses will be sent   
   to the server. If 
end of file is reached then the connection will be
   closed down. When used interactively (which means neither -quiet nor
   -ign_eof have been given), then certain commands are also recognized 
   which perform 
special operations. These commands are a letter which
   must appear at the start of a line. They are listed below.   


   Q   End the current SSL connection and exit.

   R   Renegotiate the SSL session (TLSv1.2 and below only).

   B   Send a heartbeat message to the server (DTLS only)

   k   Send a key update message to the server (TLSv1.3 only)

   K   Send a key update message to the server and request one back
   (TLSv1.3 only)

speaking of "case", one simple way to work around these is to issue all
SMTP commands in lower case.

rcpt to:
...
quit

rather than:

RCPT TO:
...
QUIT

Or use the "ign_eof" and/or the "-quiet" option.

-- 
Viktor.

-- 
## 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/

Re: [exim] Some Emails to gmail now hang

[Viktor Dukhovni via Exim-users]

On Fri, Aug 12, 2022 at 12:31:16PM -0400, Viktor Dukhovni via Exim-users wrote:

> If the problem persists with as much as possible of the hardware assist
> disabled, then it sure looks like Linux TCP is the culprit.

Unsurprisingly, this is indeed a Linux bug.  Neal Cardwell from Google
shared the below:

I strongly suspect this is a known issue with interactions between
Exim and TFO causing machines to ignore packets, which was reported
in this thread:

https://lore.kernel.org/lkml/E1nZMdl-0006nG-0J@plastiekpoot/

I tracked it down to a conntrack bug and suggested a fix, and the
conntrack maintainers checked in an expanded fix here: c7aab4f17021b
netfilter: nf_conntrack_tcp: re-init for syn packets only


https://lore.kernel.org/netdev/17c87824-7d04-c34e-bf6a-d8b874242...@tmb.nu/t/#mab1f2792ba24e98e3f41468c9781747a77c87ac9

Can you please advise folks who run into this to upgrade to Linux v5.18
or later (since it has the fix) or to cherry-pick in that fix?

I see this patch was only backported to 5.17, and not to older stable
releases. I will try to get it backported to other stable releases so
more users pick up the fix automatically from their distributions...

It seems that with TFO the Linux TCP client is prone to losing track of
the window scale, and eventually the SMTP client runs out of TCP window,
matching Jeremy's observation that the client did not get far past the
initial window.

So either get a later (or patched) kernel, or disable TFO.

-- 
Viktor.

-- 
## 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/

Re: [exim] Some Emails to gmail now hang

[Viktor Dukhovni via Exim-users]

On Fri, Aug 12, 2022 at 08:31:37AM +0100, Graeme Coates via Exim-users wrote:

> I repeated the test with tso off in the NIC. Process as follows:
> 
> 1. Stop Exim, remove fastopen exclusion in transport conf.
> 2. ethtool -K eth0 tso off; ethtool -K eth0 tx off
> 3. Restart exim, retest.
> 
> Still experiencing timeouts in a similar fashion much as before - tshark
> summary:
> https://www.chromosphere.co.uk/wp-content/blogs.dir/1/files/2022/08/tfo_nic.txt

The numbers look very similar to the previous case:

ACKSEQ   WARP
150400 69004 81396
156097 71845 84252

Both cases see the server ACK ~150k of data with the client then
retransmitting back from ~70k, going back ~80k for no obvious reason.

> Of note, here's the output from ethtool --show-offload when I ran the test:
> 
>  # ethtool --show-offload eth0
> Features for eth0:
> rx-checksumming: on [fixed]
> tx-checksumming: off
> tx-checksum-ipv4: off [fixed]
> tx-checksum-ip-generic: off
> tx-checksum-ipv6: off [fixed]
> tx-checksum-fcoe-crc: off [fixed]
> tx-checksum-sctp: off [fixed]
> scatter-gather: on
> tx-scatter-gather: on
> tx-scatter-gather-fraglist: off [fixed]

I would like to suggest also disabling "sg".

> generic-segmentation-offload: on
> generic-receive-offload: on

Perhaps these too.  The idea is to try and see whether it is Linux or
the NIC.  Why on earth TFO would have such a delayed effect far down the
TCP stream is rather a mystery. Once the 3WHS is complete, with or
without 0-RTT data, the rest of the TCP session should proceed
identically.

If the problem persists with as much as possible of the hardware assist
disabled, then it sure looks like Linux TCP is the culprit.

-- 
Viktor.

-- 
## 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/

Re: [exim] Some Emails to gmail now hang

[Viktor Dukhovni via Exim-users]

On Fri, Aug 12, 2022 at 06:30:21AM +0100, Andrew C Aitchison via Exim-users 
wrote:

> > It looks *strongly* like an interoperability problem between the Linux
> > kernel TCP implementation and the Google TCP/TLS termination front-ends,
> > unless all the Exim users who lately somewhat regularly show up to
> > report this issue are behind some as yet unidentified set of
> > middle-boxes that break TCP state.
> >
> > It would perhaps be useful to also see any reports of success sending
> > sufficiently large messages to Gmail from the reported Exim builds and
> > Linux versions.  If some users are not seeing any issues, then it would
> > be good to know how their situation is differs.
> 
> Might be good to know who is using openssl and who is using gnu-tls,
> so that we can rule in or out the tls implementation.

Surely irrelevant, this is a *TCP-layer* problem.  If not in the Linux
kernel, perhaps in the TCP offload in the network card.

-- 
Viktor.

-- 
## 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/

Re: [exim] Some Emails to gmail now hang

[Viktor Dukhovni via Exim-users]

On Thu, Aug 11, 2022 at 10:23:47PM +0100, Graeme Coates via Exim-users wrote:

> > At this point it would be useful to see the full PCAP file for just the
> > traffic involving client port "44884".
> >
> > $ tcpdump -s0 -r /some/file.pcap -w /tmp/tfo.pcap tcp port 44884
> >
> > The tshark summary decode elides some details...
>
> No problem - here's a link to the pcap file filtered down by port 44884.
> 
> https://www.chromosphere.co.uk/wp-content/blogs.dir/1/files/2022/08/tfo.zip

It still very much looks like client-side misbehaviour.  One
complication is that you also have client-side TCP offload, but since
after STARTTLS the server only sends small ACK packets, its checksums
verify correctly, and essentially only the client packets carry
"incorrect" (to be computed in the NIC) checksums.

It may be worth trying to disable TCP offload in the NIC, and see
whether then TFO remains problematic.  In other words, does it
somehow confuse the kernel or the NIC?

Still very odd that the problem would show up so late (~69k) into the
stream.

-- 
Viktor.

-- 
## 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/

Re: [exim] Some Emails to gmail now hang

[Viktor Dukhovni via Exim-users]

On Thu, Aug 11, 2022 at 09:06:28PM +0100, Mike Tubby via Exim-users wrote:

> I have experienced the same... seems to happen one every 2-3 weeks and I 
> think it depends on which actual server in Google's cluster you get 
> connected to.
> 
> Google's implementation of SMTP seems to be very poor at reporting 
> actual problems, rather it either accepts delivery (and presumably 
> discards it) or hangs like you have experienced.

The evidence from the posted decodeed packet capture so far suggests
otherwise.  The problem is at the TCP layer, completely unrelated to
Google's "SMTP implementation", and to first approximation, pending
further more detailed analysis of packet captures, looks like a Linux
TCP bug, more than a Google bug...

-- 
Viktor.

-- 
## 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/

Re: [exim] Some Emails to gmail now hang

[Viktor Dukhovni via Exim-users]

On Thu, Aug 11, 2022 at 02:55:51PM +0100, Graeme Coates via Exim-users wrote:

> > Can you post a "tshark" decode of a full capture of a failed delivery?
> >
> > # tcpdump -s0 -w /some/file.pcap ...
> > # tshark -nr /some/file
> >
> > [ Keep the PCAP file, more questions may arise once the basic decode is
> >   posted. ]
> >
> >
> I have a full capture run through tshark as per above at the following URL:
> 
> https://www.chromosphere.co.uk/wp-content/blogs.dir/1/files/2022/08/tshark_gmail.txt
> 
> (NB: I added a capture filter to tcpdump of the form: "port 25 || port 587
> || port 465 || port 2525" to filter down to SMTP traffic - if I need to
> repeat using an alternate packet filter, please let me know - it's fairly
> easy for me to do). Note that this was for an ~5.6MB attachment - the
> initial delivery was via ipv6 which failed, and it then flicked back to v4
> and worked. However, I have seen failures on both ipv6 and ipv4 prior to
> implementing the workaround).

Among the decoded sessions, only one used TFO to eliminate a round-trip
delay:

   65.309846 2a00:1098:0:86:1000:45:0:1 → 2a00:1450:400c:c07::1b TCP 106 44884 
→ 25 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM=1 TSval=2327966919 TSecr=0 
WS=128 TFO=C
   65.318623 2a00:1450:400c:c07::1b → 2a00:1098:0:86:1000:45:0:1 TCP 94 25 → 
44884 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 SACK_PERM=1 
TSval=3698060567 TSecr=2327966919 WS=256
   65.319958 2a00:1450:400c:c07::1b → 2a00:1098:0:86:1000:45:0:1 SMTP 173 S: 
220 mx.google.com ESMTP n12-20020a5d660c00b0021eed663c94si12775572wru.912 - 
gsmtp
   65.319991 2a00:1098:0:86:1000:45:0:1 → 2a00:1450:400c:c07::1b TCP 86 44884 → 
25 [ACK] Seq=1 Ack=88 Win=64768 Len=0 TSval=2327966929 TSecr=3698060569

Here the server's greeting appears to be sent before the client's ACK,
suggesting that the client's TFO cookie was accepted.

This somewhat hits an edge case in the TFO specification, because with
the server talking first, the client's initial data length is zero, and
so the server's signal that TFO is not accepted (by ACKING only the SYN
and not the initial data) is indistinguishable from the signal that it
was (by ACKing also the initial data).

In any case many packets later, and with data successfully delivered in
both directions, things start to go wrong:

65.584402 2a00:1450:400c:c07::1b → 2a00:1098:0:86:1000:45:0:1 TCP 86 25 → 
44884 [ACK] Seq=6247 Ack=147544 Win=321792 Len=0 TSval=3698060833 
TSecr=2327967185
65.584402 2a00:1450:400c:c07::1b → 2a00:1098:0:86:1000:45:0:1 TCP 86 25 → 
44884 [ACK] Seq=6247 Ack=148972 Win=324608 Len=0 TSval=3698060833 
TSecr=2327967185
65.605640 2a00:1098:0:86:1000:45:0:1 → 2a00:1450:400c:c07::1b TCP 1514 
44884 → 25 [ACK] Seq=148972 Ack=6247 Win=64128 Len=1428 TSval=2327967214 
TSecr=3698060823 [TCP segment of a reassembled PDU]
65.614445 2a00:1450:400c:c07::1b → 2a00:1098:0:86:1000:45:0:1 TCP 86 25 → 
44884 [ACK] Seq=6247 Ack=150400 Win=327424 Len=0 TSval=3698060863 
TSecr=2327967214
65.821663 2a00:1098:0:86:1000:45:0:1 → 2a00:1450:400c:c07::1b TCP 1514 [TCP 
Spurious Retransmission] 44884 → 25 [ACK] Seq=69004 Ack=6247 Win=64128 Len=1428 
TSval=2327967430 TSecr=3698060823[Reassembly error, protocol TCP: New fragment 
overlaps old data (retransmission?)]
65.830763 2a00:1450:400c:c07::1b → 2a00:1098:0:86:1000:45:0:1 TCP 98 [TCP 
Dup ACK 2064#1] 25 → 44884 [ACK] Seq=6247 Ack=150400 Win=327424 Len=0 
TSval=3698061079 TSecr=2327967214 SLE=69004 SRE=70432
66.261594 2a00:1098:0:86:1000:45:0:1 → 2a00:1450:400c:c07::1b TCP 1514 [TCP 
Spurious Retransmission] 44884 → 25 [ACK] Seq=69004 Ack=6247 Win=64128 Len=1428 
TSval=2327967870 TSecr=3698060823[Reassembly error, protocol TCP: New fragment 
overlaps old data (retransmission?)]
66.271116 2a00:1450:400c:c07::1b → 2a00:1098:0:86:1000:45:0:1 TCP 98 [TCP 
Dup ACK 2064#2] 25 → 44884 [ACK] Seq=6247 Ack=150400 Win=327424 Len=0 
TSval=3698061519 TSecr=2327967214 SLE=69004 SRE=70432
67.125602 2a00:1098:0:86:1000:45:0:1 → 2a00:1450:400c:c07::1b TCP 1514 [TCP 
Spurious Retransmission] 44884 → 25 [ACK] Seq=69004 Ack=6247 Win=64128 Len=1428 
TSval=2327968734 TSecr=3698060823[Reassembly error, protocol TCP: New fragment 
overlaps old data (retransmission?)]
...

The client seems rather intent to retransmit packets long ago ACKed by
the server!  How/why TFO comes into play here, so late in the TCP stream
is unclear.  Naively, looks more like a Linux bug, unless the server did
something wrong along the way I missed on first inspection.

At this point it would be useful to see the full PCAP file for just the
traffic involving client port "44884".

$ tcpdump -s0 -r /some/file.pcap -w /tmp/tfo.pcap tcp port 44884

The tshark summary decode elides some details...

-- 
Viktor.

-- 
## 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/

Re: [exim] Some Emails to gmail now hang

[Viktor Dukhovni via Exim-users]

On Wed, Aug 10, 2022 at 04:00:51PM -0700, Marc MERLIN wrote:

> > I've also reached out to the Gmail team.  They're aware.  Which is not
> > to say that there's a quick fix in the works, the front-end connection
> > termination devices are both non-trivial and critical, so changes will
> > happen cautiously and likely slowly, and may be delayed by other
> > priorities...
> 
> Thanks.
> 
> Whose fault is it? debian/exim, or gmail?

It looks *strongly* like an interoperability problem between the Linux
kernel TCP implementation and the Google TCP/TLS termination front-ends,
unless all the Exim users who lately somewhat regularly show up to
report this issue are behind some as yet unidentified set of
middle-boxes that break TCP state.

It would perhaps be useful to also see any reports of success sending
sufficiently large messages to Gmail from the reported Exim builds and
Linux versions.  If some users are not seeing any issues, then it would
be good to know how their situation is differs.

If you have Exim on a Linux laptop and are able to connect it the office
WiFi network, can you still see the problem with default Exim settings?

Can you post a "tshark" decode of a full capture of a failed delivery?

# tcpdump -s0 -w /some/file.pcap ...
# tshark -nr /some/file

[ Keep the PCAP file, more questions may arise once the basic decode is
  posted. ]

-- 
Viktor.

-- 
## 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/

Re: [exim] Some Emails to gmail now hang

[Viktor Dukhovni via Exim-users]

On Wed, Aug 10, 2022 at 11:17:43PM +0100, Andrew C Aitchison via Exim-users 
wrote:

> On Wed, 10 Aug 2022, Marc MERLIN via Exim-users wrote:
> 
> > On Wed, Aug 10, 2022 at 06:29:47PM +0100, Jeremy Harris via Exim-users 
> > wrote:
> >> That's extremwly weird. I can't see a logical connection between the
> >> TCP startup detail and a problem that late in the SMTP conversation.
> >
> > That was my thought too, I don't get it.
> >
> >> I'd love to hear from someone at Google on this point.
> >
> > I work at google (not in gmail), and have asked internally if they can
> > look into it.
> > They are very busy so I'm not sure when I'll hear back.
> 
> Might be worth posting on the mai...@mailop.org list

I've also reached out to the Gmail team.  They're aware.  Which is not
to say that there's a quick fix in the works, the front-end connection
termination devices are both non-trivial and critical, so changes will
happen cautiously and likely slowly, and may be delayed by other
priorities...

-- 
Viktor.

-- 
## 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/

Re: [exim] heimdal_gssapi authenticator

[Viktor Dukhovni via Exim-users]

On Tue, Aug 02, 2022 at 11:17:47PM +0100, Jeremy Harris via Exim-users wrote:

> Does anyone out there use the above?  Build with it?

I don't build Exim, so, can't say whether there are Heimdal + Exim
users, but I had been known until recently to be a Heimdal
co-maintainer.

Heimdal is likely still the default Kerberos version on NetBSD, and also
available in FreeBSD ports.  Debian did have a Heimdal package last I
looked.

> My initial attempts to build (having not found an obvious fedora
> library package for heimdall, yet) are tripping over a possibly
> incompatible /usr/include/krb5.h

If you have "krb5.h" from MIT Kerberos, that would not be the right
header.  You need the Heimdal "krb5.h" to compile and link against
Heimdal.

-- 
Viktor.

-- 
## 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/

Re: [exim] Closing off Port to non-SSL traffic

[Viktor Dukhovni via Exim-users]

On Sun, Jun 26, 2022 at 04:30:14PM +0200, Slavko via Exim-users wrote:

> > it seems 
> > there is confusion over the use of this port. I've always assumed
> > that some MTA clients may use port 465 - rather than using port 25.
> 
> Not MAY, they SHOULD (if they support it), the 587 is as fallback for
> old clients only, the 25/tcp is deprecated for MUAs for years...

Read carefully, the question (as stated) was about SMTP relay client
*MTAs*, not client submission MUAs.

> > Users should then set SSL/TLS encryption on port 465? (which means me 
> > talking to all of them)
> 
> Sure, send email them, phone them, meet them... And then wait some time
> (weeks, months, ...), then close 587... As i noted elsewhere, i
> don't allow clients connections to 25 nor 587 at least for two years...

There is not much to be gained by insisting users reconfigure their
systems.  Sure document 465 as the preferred configuration, but then let
the users decide.  The sky is not falling.

Gradually as they update their MUA software, they'll likely end up on
465.

-- 
Viktor.

-- 
## 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/

Re: [exim] Closing off Port to non-SSL traffic

[Viktor Dukhovni via Exim-users]

On Sun, Jun 26, 2022 at 03:52:56PM +0200, Mark Elkins via Exim-users wrote:

> > I am curious. Why do you not allow your users to user port 465 ?
> > RFC 8314 https://datatracker.ietf.org/doc/html/rfc8314#section-7.3
> > repurposed this as a mail *submission* port with Implicit TLS.
> 
> Reading RFC 8314 
> https://datatracker.ietf.org/doc/html/rfc8314#section-7.3 - it seems 
> there is confusion over the use of this port. I've always assumed that 
> some MTA clients may use port 465 - rather than using port 25.

No.  

* MTA-to-MTA SMTP relay is always over port 25.
* Port 465 was always MUA-to-MTA submission.

This is because MX records don't signal port numbers, only
host names, so the port number MUST be a prior fixed value.

This of course does not prevent "private" arrangements where some
particular MTAs relay some mail via port 465 to some other *specific*
MTAs under suitable conditions (particular envelope or content
features).  Such arrangements would always be local policy exceptions to
how email is routed over the public Internet (as specified in RFC5321).

> Port 587 has always been the mail submission port - friends confirmed 
> this to me.

Friends make mistakes.  The authoritative sources are:

https://www.rfc-editor.org/rfc/rfc2476
https://www.rfc-editor.org/rfc/rfc4409
https://www.rfc-editor.org/rfc/rfc6409
https://www.rfc-editor.org/rfc/rfc5068

The use of 465 for submission over TLS was a non-standard Microsoft
Exchange/Outlook feature for many years, only recently elevated to
standard in https://www.rfc-editor.org/rfc/rfc8314

> Reading the above - looks like I'm wrong and should also (or rather) run 
> port 465 on my incoming (SMTP-Relay) mail servers.

No. SMTP relay servers are MTA-to-MTA SMTP, and so unavoidable on port 25.

Only submission is on ports 687 and 465.

> I assume that just means enabling that port?

Well, it has to be configured correctly, with TLS wrapping the use of
the SMTP protocol, rather that the SMTP protocol facilitating TLS via
STARTTLS.

> Users should then set SSL/TLS encryption on port 465? (which means me
> talking to all of them)

Or just let them choose.  Gradually, more of them will organically move
to 465, and you (or who ever you saddle with the burden) can "talk" to
the long-tail users in 10 years or so.

> Would also love to know why then can we still run STARTTLS on port 587
> - if it is so insecure?

It isn't.  And the risks are not to SMTP servers and clients, but rather
to web browsers and the like that can be convinced to misinterpret
reflected text in error messages.

The basic issue of injection of buffered pre-TLS cleartext into a post
STARTTLS session was resolved in Postfix and IIRC also Exim quite some
time ago.  So there's little reason to avoid port 587 with these MTAs.

Various other STARTTLS implementations (in IMAP servers, and less
mainstream SMTP servers) might not have gotten the memo, but you
should be fine.

-- 
Viktor.

-- 
## 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/

Re: [exim] TLS "certificate expired" warnings on inbound connections

[Viktor Dukhovni via Exim-users]

On Tue, May 31, 2022 at 09:55:22PM +0200, Tim Jackson via Exim-users wrote:

> Thanks for the clarification. So the issue is the client verification of the 
> server cert, not a client cert.

Yes, unless I've grossly misread your description of the symptoms.

> > The DST Root CA is expired.  You can configure LE to build a
> > "fullchain.pem" using the ISRG root instead.  The only downside is that
> > old Android systems may no longer be able to verify your chain.
> 
> OK, so my original theory was right (and, if I understand rightly, this is an 
> outdated client implementation).

Yes.

> Is the solution 'certbot --preferred-chain 
> "ISRG Root X1"' then? (As I mentioned, I currently use acme-tiny rather than 
> certbot, which unfortunately doesn't seem to support choosing the chain [1], 
> so I guess I have to switch)

Something like that.  One way or another avoid the DST root.

-- 
Viktor.

-- 
## 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/

Re: [exim] TLS "certificate expired" warnings on inbound connections

[Viktor Dukhovni via Exim-users]

On Tue, May 31, 2022 at 09:20:25PM +0200, Tim Jackson via Exim-users wrote:

> > Is there any chance that the client tries to present you a certificate,
> > even if you do not request it?

No.  The TLS protocol precludes the presentation of unsolicited client
certificates.  If the server does not send the certificate request
message, the protocol state machine does not support any way for the
client to send one anyway.  If it tries, that would be a protocol
error, and the server would drop the connection with a suitable
alert to the client.

-- 
VIktor.

-- 
## 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/

Re: [exim] TLS "certificate expired" warnings on inbound connections

[Viktor Dukhovni via Exim-users]

On Tue, May 31, 2022 at 08:33:19PM +0200, Tim Jackson via Exim-users wrote:

> [130.248.154.209]:44104 I=[167.235.252.255]:25 (SSL_accept): 
> error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired

TLS alerts report error conditions from the remote peer.  If your server
logs a TLS alert, that alert was generated on the remote end.  So if
this is a connection from a client to your server, then the "certificate
expired" condition is something that the client believes to be the case.

Perhaps your Let's Encrypt certificate chain includes the expired DST
root CA certificate, you can configure certbot to not send it.

> Certificate chain
>   0 s:CN = mx1.firecluster.net
> i:C = US, O = Let's Encrypt, CN = R3
>   1 s:C = US, O = Let's Encrypt, CN = R3
> i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
>   2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
> i:O = Digital Signature Trust Co., CN = DST Root CA X3

The DST Root CA is expired.  You can configure LE to build a
"fullchain.pem" using the ISRG root instead.  The only downside is that
old Android systems may no longer be able to verify your chain.

You can use a different cert chain for submission than for port 25
(where you're unlikely to need Android support).

-- 
VIktor.

-- 
## 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/

Re: [exim] Failing for DNSSEC lookup

[Viktor Dukhovni via Exim-users]

On Sun, Mar 20, 2022 at 08:35:48PM +0100, Christian Eyrich via Exim-users wrote:

> my exim installation is failing when I try forcing DNSSEC for DANE using 
> "dnssec_require_domains" for any domain.
> 
> dnslookup_secure router: defer for dnssecte...@mailbox.org
>message: host lookup done insecurely

> chris@momos:~$ unbound-host -vDr mailbox.org
> mailbox.org has address 80.241.60.194 (secure)
> [...]

Even if the local (unbound) resolver performs DNSSEC validation and
signals a secure result via the "AD" bit in the DNS reply, a
sufficiently recent "glibc" will suppress the AD bit unless
/etc/resolv.conf sets "trust-ad" resolver option:

https://github.com/NLnetLabs/dnssec-trigger/issues/5#issuecomment-799847737

The most likely problem is that this is not set in your
/etc/resolv.conf file.

Note that you should not trust the "AD" bit from *remote* nameservers
whose replies to your libc stub resolver traverse insecure networks.
In practice this means that /etc/resolv.conf MUST ONLY contain the
127.0.0.1 and/or ::1 nameserver addresses.

-- 
Viktor.

-- 
## 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/

[exim] Microsoft's DANE rollout for Exchange Online

[Viktor Dukhovni via Exim-users]

Starting this month through May 2022, Microsoft will incrementally
roll out outbound DANE support (*enabled by default*) for all hosted
Exchange Online domains:


https://m365admin.handsontek.net/upcoming-release-outbound-smtp-dane-and-dnssec-in-microsoft-365-exchange-online/

> As previously announced in the blog post Support of DANE and DNSSEC in Office 
> 365 Exchange Online, we will be adding support for SMTP DANE and DNSSEC to 
> Exchange Online (EXO). DANE combined with DNSSEC is the state-of-the-art for 
> securing email, and to optimize its effectiveness both standards will be 
> enabled by default at the system level for all EXO customers.

If your cert rollover practices are sloppy, with transient certificate
chain validation failures after each key/cert rollover, as stale TLSA
records age out from caches or are only updated after problem reports,
then this is a good time to either up your game, or stop publishing TLSA
records.  Having stale TLSA records that delay or break email delivery
does neither you nor the people sending you email any good.

Please follow best-practice and pre-publish matching TLSA records for
the upcoming certs a few TTLs before certificate deployment.  If that's
too hard, disable DANE until you can implement a more robust rollover
process.

-- 
Viktor.
-- 
## 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/

Re: [exim] Certificate validation failed

[Viktor Dukhovni via Exim-users]

On Sat, Oct 30, 2021 at 02:09:21PM +0200, Slavko via Exim-users wrote:

> It is useless to use TLS for moving messages eg. between LXC hosts (not
> VPS) or for delegating delivery to other MDA, when it stays on the same
> machine. If someone can gain root access to inspect/intercept them,
> then it can get keys to decrypt them too or even do more harm...

Nobody is proposing that TLS policy be inflexibly uniform for all
destinations.  My observation is merely that the options to choose
from should as much as possible make sense.  If it is too easy to
to accidentally configure footgun behaviour, then the design could
be reconsidered.

My suggestion would be that if someone configures mandatory verification
to some destination, then cleartext fallback should not happen.  Only
"try" verification should support optional cleartext fallback.

> I agree, that more options leads to more mistakes, but on the other
> side, more options allows to more customization and are not forcing
> some behavior for all.

I am not arguing for fewer options, I'm arguing for a rational UI
to the available behaviours that does not expose inexperienced
users to footgun choices.

-- 
Viktor.

-- 
## 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/

Re: [exim] Certificate validation failed

[Viktor Dukhovni via Exim-users]

On Sat, Oct 30, 2021 at 11:58:56AM +0200, Slavko via Exim-users wrote:

> > smtp_tls_security_level = none | may | encrypt | fingerprint | dane | 
> > secure
> 
> I think, that ideal MTA must have option:
> 
> guess_tls_verify = no | user | admin
>
> That "guess" part points to deciding what hosts are trusted and/or
> which are bad.

No.  Rather than random ad-hoc policies, we implement and evolve
standards.  Thus we have:

* Base opportunistic TLS: RFC3207
* DANE SMTP: RFC7672
* REQUIRETLS: RFC8689
* MTA-STS (sigh)
...

> I am happy, that exim is not ideal MTA and leaves this "guess" for
> admins to set it explicitly/manually in mentioned options, which has
> usable defaults.

Actually, Exim supports DANE, which (when enabled) honours published
TLSA records, rather than "guessing".  And both Exim and Postfix support
different local policies by destination domains.

> Anyway, if Exim aborts outgoing connection at failed cert verification
> (or any other TLS error) in STARTTLS, it is (IMO) RFC violation
> (missing clean QUIT), but i do not know if it happens.

No, it is not an RFC violation to abort the handshake, and send a
suitable TLS alert message, but this tends to clutter remote server logs
with low-level error messages their administrator is likely to not
understand.

The main point is to not fall back to cleartext when there was a
perfectly good TLS handshake the MTA could simply choose to not
abort, because the cleartext fallback is definitely not better.

-- 
Viktor.

-- 
## 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/

Re: [exim] Certificate validation failed

[Viktor Dukhovni via Exim-users]

On Sat, Oct 30, 2021 at 11:56:21AM +0100, Dominik Vogt via Exim-users wrote:

> > * Use a certiticate that verifyable without client-side changes., e.g. setup
> >   DANE on the server and/or use e.g. a letsencrypt cert.
> 
> It's not my server, but the colleague says it supports DANE.  I
> may look into that later.

Note, it is important to be clear about what "supports DANE" means,
becaue the inbound and outbound capabilities are independent of
each other.

For a receiving server to "support DANE", its hostname needs to be
in a DNSSEC-signed zone, and there must be TLSA records for the
port in questoin (25, or one of the submission ports).  And these
TLSA records needs to consistently match the certificate chain:

* Which means proper service monitoring, including regular
  (daily or more frequent) certificate checks against the
  TLSA records.

* Well thought out and executed key/cert rollovers that
  don't cause transient outages due to mismatch between
  the fresh cert and current or cached DNS data.

See the DANE resources links at (e.g.):

https://stats.dnssec-tools.org/explore/?exim.org

[ The secondary MX for exim.org is not yet in a
  DNSSEC-signed zone, so DANE to exim.org is
  subject to MiTM downgrades. ]

-- 
Viktor.

-- 
## 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/

Re: [exim] Certificate validation failed

[Viktor Dukhovni via Exim-users]

On Sat, Oct 30, 2021 at 10:46:24AM +0300, Evgeniy Berdnikov via Exim-users 
wrote:

> > This seems like a footgun combination of configuration options. [...]
> 
>  How Exim is doing TLS fallback is described here:
> 
>  
> https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECTclientTLS
> 
>  As I understand, peer's certificate validation failure is one variant of
>  general TLS negotiation failure, resulting in fallback to plain text if
>  tls_tempfail_tryclear option of SMTP transport is "true" (default).

Yes, but this is an "opt-in" failure mode.  You don't have to try to
verify, and even if you try to verify you don't have to choose to abort
the handshake when verification fails.

Note that X.509 certificate verification lies outside of TLS, and is in
an entirely separate library in some TLS stacks.  Certificate
verification failure is only a TLS handshake failure if one chooses it
to be.

The only reason to abort the handshake on verification failure is if you
insist on a secure connection, and then you'd better not fall back to
cleartext which would be just absurd.  Either require a secure
connection, or don't, ... the combination of behaviours makes no sense.

Yes, Exim currently makes it possible, but that such booby traps for the
user are design errors, when they're not (as in this case) just
implementation bugs.

-- 
Viktor.

P.S.  In Postfix we never abort a TLS handshake due to verification
failure even when authentication is required.  Instead we let the
handshake complete, and then, if verification was required, but did not
succeed, politely terminate the connection (by sending QUIT) without
sending the message.

Some day I may define an SMTP extension for in-band signalling of
authentication failures, that servers can offer if they want near
real-time notification that clients are seeing problems with the
server certificates.

-- 
## 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/

Re: [exim] Certificate validation failed

[Viktor Dukhovni via Exim-users]

On Sat, Oct 30, 2021 at 08:07:02AM +0200, Andreas Metzler via Exim-users wrote:

> > Is it really true that for lack of valid certificate there's a way to
> > get Exim to fall back to cleartext instead???
> 
> If a host is in tls_verify_hosts and hosts_try_tls but not in
> hosts_require_tls exim will fall back to cleartext. (That is for the
> non-DANE case.)

This seems like a footgun combination of configuration options.  Either
tls_verify_hosts should be preëmpted by lack of a corresponding listing
in hosts_require_tls, or else with tls_verify_hosts, verification
failure should preëpt fallback to cleartext.

As it stands, enabling tls_verify_hosts can in may cases reduce, rather
than increase security.

In Postfix we like to shy away from combinatorial interations of
overlapping boolean settings, and strive to construct a single
multi-valued (non-boolean) setting that rationalises the available
options.

Thus:

smtp_tls_security_level = none | may | encrypt | fingerprint | dane | secure

If you want opportunistic TLS, you choose "may", and certificates are
not verified.  If you want mandatory TLS, you choose "encrypt" or
better, and there's no cleartext fallback.

The one nit that's not been addressed yet is a policy for domains that
don't publish TLSA records.  It isn't currently possible to do "dane"
else "encrypt".  Need a dane-fallback level (default "may").
 
--
Viktor.

-- 
## 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/

Re: [exim] Certificate validation failed

[Viktor Dukhovni via Exim-users]

On Sat, Oct 30, 2021 at 12:01:39AM +0100, Dominik Vogt via Exim-users wrote:

> The local Exim is set up to relay outgoing mail that is sent by
> user X to server B and all other outgoing mail to server A.  Both
> servers require TLS for outgoing mail.  But Exim does not use TLS
> for server B and generates this log message:
> 
>   ... TLS session: (certificate verification failed): certificate
>   invalid: delivering unencrypted to H= []
>   (not in hosts_require_tls)

Is it really true that for lack of valid certificate there's a way to
get Exim to fall back to cleartext instead???

Either certificate validation is required, and in which delivery must be
deferred when validation fails, or else validation is *not* required,
in which case Exim should proceed despite certificate verification
failure.

The reported behaviour should be impossible, or at least very difficult
to configure without ignoring warnings that it makes no sense.

-- 
Viktor.

-- 
## 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/

Re: [exim] Exim 4.95 released

[Viktor Dukhovni via Exim-users]

On Fri, Oct 01, 2021 at 01:00:09PM -0400, Viktor Dukhovni via Exim-users wrote:

> > > I'd like to ask, if I may, how TLS resumption interacts with DANE or
> > > other authenticated TLS policy, [...]
> > 
> > If enabled for a target host (default being no) then the session
> > cache lookup key is the unadorned IP.

Meanwhile, if haven't misuderstood your response, or failed to grasp the
complete picture, I think that Exim 4.95 users who want to support
outbound DANE should not enable TLS resumption, and likely the
documentation should advise them of the potential negative interactions.

When a session was cached for resumption (based on policy to cache
sessions for a particular destination), what determines whether that
cached session would later be used?

Does the current destination (would that be a domain, a host, an IP
address... ?) need to explicitly opt-in for resumption, or is presence
of the matching IP address in the cache sufficient to trigger session
reuse?

-- 
Viktor.

-- 
## 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/

Re: [exim] Exim 4.95 released

[Viktor Dukhovni via Exim-users]

On Fri, Oct 01, 2021 at 02:15:05PM +0100, Jeremy Harris via Exim-users wrote:

> On 28/09/2021 23:41, Viktor Dukhovni via Exim-users wrote:
> >>- fast-ramp queue run
> >>- native SRS
> >>- TLS resumption
> > 
> > I'd like to ask, if I may, how TLS resumption interacts with DANE or
> > other authenticated TLS policy, assuming potential earlier
> > unauthenticated TLS connections to the same IP:port or name:port on
> > behalf of some other domain (or via an alternate "router") which did not
> > require an authenticated connection, or otherwise had a different set of
> > TLS requirements.
> 
> If enabled for a target host (default being no)
> then the session cache lookup key is the unadorned IP.

I guess you won't be surprised if I suggest you should consider a more
security-aware design, that takes the extant security policy parameters
into account when constructing the lookup key.

Otherwise, when a e.g. a connection to a DANE-enabled destination
follows a connection to an unauthenticated opportunistic TLS connection
with the same underlying host IP, the DANE connection is subject to MiTM
if the original connection was successfully compromised.

Security aside, we also found it useful to salt the lookup key with the
remote "EHLO" response name, in order to work better with Microsoft's
SMTP servers which have split caches:

S: 220 ...
C: EHLO amnesiac
S: 250- [ junk]
S  ...
S: 250 STARTTLS

We include the  in the cache lookup key, so that we can find
the "right" session for split caches behind a load balancer.  The Google
SMTP servers have a shared session ticket key and respond with a common 
.

If you're curious how Postfix computes the lookup key, I can point you
at the code.  Basically it computes a SHA256 digest of all relevant
destination and security parameters and uses that in the key...

> >>- faster TLS startup
> > 
> > May I ask what this means?
> 
> Caching of the CA bundle, and similar setup, by loading it in the
> daemon process (which forks for receive processes).

Makes sense, thanks.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTLS vs OpenSSL

[Viktor Dukhovni via Exim-users]

> On 30 Sep 2021, at 6:32 pm, Sabahattin Gucukoglu via Exim-users 
>  wrote:
> 
> Courier Mail Server fetches MTA-STS policy documents. I’d consider this a 
> good reason to do MTA-STS as well as DANE, even though I suspect the base of 
> Courier users will be small. Interesting too is that Debian compiles their 
> couriertls against GnuTLS (but I won’t be using that).

The primary use-case for MTA-STS at present is gmail.com, otherwise
it is basically unused.  I am not a fan of propping up Google's walled
garden, so generally discourage its adoption.  Below is a response to
the USG's call for public comment on an architecture that includes MTA-STS:

  https://www.isi.edu/~hardaker/news/2021-09-20-DANE-vs-STS.html

-- 
Viktor.


-- 
## 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/

[exim] Please drop TLSA records matching retired Let's Encrypt CAs

[Viktor Dukhovni via Exim-users]

The DANE survey continues to observe a "long tail" of MX hosts with TLSA 
records that match the retired "X3" and/or "X4" Let's Encrypt issuer Cas.

If you're publishing TLSA records with Let's Encrypt issuer CA hashes,
the "X3" and "X4" CAs should no longer appear in your TLSA RRset.  Also
be sure to use "2 1 1" and not "2 0 1" or "2 0 2" TLSA parameters.
For details see:

http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html

The MX host counts for the various LE CAs are:

  #   | CA 
--+
  538 | X3
  248 | X4
 1133 | R3
  436 | R4
  483 | E1
  396 | E2

* The counts for X3 and X4 should by now be 0.
* Every MX host that publishes R3 should also publish R4.
* Every MX host publishing E1 should also publish E2.
* The simplest strategy is to publish all four of R3,R4,E1 and E2

-- 
Viktor.

Also posted to dane-us...@sys4.de and postfix-us...@postfix.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/

Re: [exim] Exim 4.95 released

[Viktor Dukhovni via Exim-users]

On Tue, Sep 28, 2021 at 11:19:34PM +0200, Heiko Schlittermann via Exim-users 
wrote:

> New stuff we've added since 4.94:
> 
> - From previous experimental support:
>   - fast-ramp queue run
>   - native SRS
>   - TLS resumption

I'd like to ask, if I may, how TLS resumption interacts with DANE or
other authenticated TLS policy, assuming potential earlier
unauthenticated TLS connections to the same IP:port or name:port on
behalf of some other domain (or via an alternate "router") which did not
require an authenticated connection, or otherwise had a different set of
TLS requirements.

In Postfix, Wietse and I had to take care in the session cache design to
avoid resumption across distinct client TLS "policies" (PKI type,
authentication, cipher list, allowed protocol versions, sorted DANE TLS
RRset, ...).  Does Exim also partition the session cache by a security
policy fingerprint?

>   - faster TLS startup

May I ask what this means?

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTLS vs OpenSSL

[Viktor Dukhovni via Exim-users]

On Mon, Sep 20, 2021 at 09:13:11PM +0200, exim-users--- via Exim-users wrote:

> > This is where our priorities differ.  Barring a practical downgrade
> > attack on SMTP STARTTLS made possible by keeping TLS 1.0 enabled, I
> > see little reason yet to force the remaining TLS 1.0 to use cleartext.
> > (Yes I'm aware of past cross-protocol attacks, see the author list of
> > DROWN: )
> 
> Kudos, real nice paper.

For the record, my contribution was small, I observed that the
RC4 part of the attack was substantially more effective in the
presence of another bug, that was fixed less than a year back
at the time, and likely not universally deployed.

The real hard work was by Nimrod Aviram and others.  So not claim
credit, so much as note that I'm familiar with the existence of
potential cross-protocol issues.

> Anyway, as you wrote in another mail, main attack would be stripping STARTTLS
> before the connection is encrypted. I currently see no real widely used 
> extension
> to address that. TLSA records and DANE are not implemented widely, MTA-STS
> probably even less wide.

DANE is yet at "widely used" but adoption of both DNSSEC and DANE is
growing steadily.

https://stats.dnssec-tools.org/

MTA-STS is pretty much just Google.  Well also mail.ru and comcast.net
(who also do DANE).

If you care about SMTP transport security, do DANE, but make sure you
implement monitoring and a robust key rollover process.  Just turning
DANE on and neglecting it does nobody any good.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTLS vs OpenSSL

[Viktor Dukhovni via Exim-users]

> On 20 Sep 2021, at 12:24 pm, Andrew C Aitchison via Exim-users 
>  wrote:
> 
> DROWN makes me think it would be sensible not to use the same certificate for 
> SMTP with TLS 1.0 or 1.1
> and any non-SMTP service
> - particularly webmail.

Actually, don't share mail certificates with web certificates, regardless of the
TLS version (even 1.3).  There are also application-layer cross protocol attacks
that can cause grief when an HTTP client is talking to an IMAP server, ...

But once you have a dedicated SMTP certificate, there's cause for concern only 
if
you ignore all the details, and draw the most conservative (dare I say paranoid)
conclusions.

The details matter.  TLS 1.0 is not SSL2.  It shares the same message structure
and version negotiation mechanisms with TLS 1.2.  TLS 1.2 introduces negotiable
signature algorithms (both better and worse!) and a few other minor mostly
positive tweaks, but fundamentally the protocol remains unchanged from 1.0.

The fact that we're talking about opportunistic unauthenticated STARTTLS in
MTA-to-MTA SMTP means that active attacks are out of scope anyway.  So TLS
1.0 is harmless, and you can leave it enabled and continue to receive encrypted
email form ~1% of long-tail systems.  When that falls below 0.01%, I'll turn it
off.   The current TLS 1.0 server population is not yet "negligible" for me, and
supporting these presents no known risk in SMTP.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTLS vs OpenSSL

[Viktor Dukhovni via Exim-users]

On Mon, Sep 20, 2021 at 12:12:02PM +0200, exim-users--- via Exim-users wrote:

> > There's little to nothing particularly wrong with TLS 1.0 for SMTP,
> > and certainly nothing that's fixed in TLS 1.1, so if the floor isn't
> > TLS 1.2 it should be 1.0 (I still recommend leaving it enabled for
> > now).
> 
> TLS 1.0 and 1.1 have been deprecated for HTTPS (at least practically,
> since modern browsers stopped supporting it last year and IETF
> formally deprecated 1.0 and 1.1 March 2021) and TLS 1.2 is out for
> more than 10 years.

Yes, that's because the relevant attacks are browser-related.  Hence
the /for SMTP/ qualification.

> Any site, that does not support at least TLS 1.2 is running absolutely
> outdated software. GnuTLS handshake errors are logged very few times
> (<<1% of the messages), I suppose that enabling TLS1.1 and lower would
> not increase encrypted connections very much.

Indeed, but my take is that some encryption is better than no
encryption, see .

> Anyway: My main goal is to protect credentials of my users, if I would
> enable TLS1.1 and lower, I would risk that this communication is not
> secured adequately.

Indeed, that's why I would recommend a floor of TLS 1.2 for portss 587
and 465, but not necessarily port 25.

> Additionally, I enforce encryption (TLS1.2+) on outgoing connections
> (only very few sites do not support that, I maintain a list of
> exceptions, when I see mails lingering in the queue).

This is where our priorities differ.  Barring a practical downgrade
attack on SMTP STARTTLS made possible by keeping TLS 1.0 enabled, I
see little reason yet to force the remaining TLS 1.0 to use cleartext.
(Yes I'm aware of past cross-protocol attacks, see the author list of
DROWN: )

On Sun, Sep 19, 2021 at 10:21:20AM +0200, Simon Josefsson via Exim-users wrote:

> > Make that TLS 1.0, almost nobody uses TLS 1.1, the sites that don't
> > support at least TLS 1.2 almost invariably only support TLS 1.0.
> 
> FWIW, I have used standard Debian exim (heavy, with GnuTLS) for my
> personal email server for a couple of years, and I don't recall any
> TLS-related problem.  FWIW, it seems TLS1.2 and TLS 1.3 is in wide
> use, see statistics from the last couple of days on my server:

Indeed TLS 1.0 is increasingly rare.  The DANE survey finds the
below TLS version frequencies for MX hosts with DANE TLSA records:

TLSv1.3 21,177
TLSv1.2  3,180
TLSv1.0 12

But these are domains that showed some active interest in SMTP security,
by publishing DANE TLSA records.  I'd expect the TLS 1.0 frequency among
general domains to be somewhat higher.

Anyway, your call of course.  My take is that supporting TLS 1.0 does
not in any practical way reduce the security of email sent to sites that
support TLS 1.2 or 1.3.  TLS version negotiation is downgrade resistant.
Downgrades would in any case require an active attack, and SMTP STARTTLS
does not defend against active attacks.  Far easier to just strip
STARTTLS than to perform TLS version downgrades.

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTLS vs OpenSSL

[Viktor Dukhovni via Exim-users]

On Sat, Sep 18, 2021 at 09:45:28PM +0100, Andrew C Aitchison via Exim-users 
wrote:

> > Besides this: About 85% of the incoming traffic is still unencrypted
> > (for my statistics, mainly because some high volume mailing list
> > servers do not use TLS), about 10% uses TLS1.3, 5% still uses TLS1.2
> > (I log TLS ciphers via +tls_cipher in Exim).
> 
> It looks as though you do not allow TLSv1.1 - I suspect that a 
> substantial faction of that 85% would use it if you allowed it.
> For email it is probably better to allow TLSv1.1 than reject it
> and end up receiving the message in plain.

Make that TLS 1.0, almost nobody uses TLS 1.1, the sites that don't
support at least TLS 1.2 almost invariably only support TLS 1.0.

There's little to nothing particularly wrong with TLS 1.0 for SMTP, and
certainly nothing that's fixed in TLS 1.1, so if the floor isn't TLS 1.2
it should be 1.0 (I still recommend leaving it enabled for now).

-- 
Viktor.

-- 
## 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/

Re: [exim] GnuTLS vs OpenSSL

[Viktor Dukhovni via Exim-users]

On Sat, Sep 18, 2021 at 10:58:33AM +0100, Sabahattin Gucukoglu via Exim-users 
wrote:

> Is there really a good reason? I do it chiefly because I like
> OpenSSL’s cipher selection (I want very permissive, ordered by
> @STRENGTH, and TLS 1.3 would be nice). There were also horror stories
> about RNG entropy starvation caused by GnuTLS.

OpenSSL is a good choice for ensuring interoperable TLS support.  GnuTLS
has had in the past its share of various quirks that have led to
unwanted or surprising behaviour.  I used to hear it derided as "GunTLS"
(as in foot-gun).

That said, GnuTLS has been around for quite some time now, and likely
most of the kinks have been worked out.

You could reach out to the Debian community and see whether they're
willing to also provide an alternative pre-packaged Exim built against
OpenSSL.

-- 
Viktor.

-- 
## 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/

Re: [exim] OPenssl 3.0.0

[Viktor Dukhovni via Exim-users]

On Tue, Sep 07, 2021 at 07:34:11AM -0600, The Doctor via Exim-users wrote:

> IIRC, exim is openssl 3 compliant.

What does that mean?  There are likely at least deprecation warnings,
though it may build.  DANE support may not consistently work without
some changes.

-- 
Viktor.

-- 
## 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/

Re: [exim] exim can't handle 521 response from remote MX

[Viktor Dukhovni via Exim-users]

On Sat, Sep 04, 2021 at 04:51:29PM -0400, John C Klensin wrote:

> As I assume you may have guessed given that you follow
> EMAILCORE, my main interest in this right now is to think about
> what changes, if any, are needed in 5431bis.  Watch for a note
> on that list and some changes in -04 that reflect this
> conversation, for which thanks to everyone.

Will do, thanks.

> From that particular perspective and purpose, as soon as someone says
> "for my specific application or bright idea, it does not matter what
> the standard says", I sort of lose interest.

FWIW, the "does not matter" in question is very narrowly scoped to the
fine-grained detail in the second and third digits of 3-digit SMTP
responses.

You might recall the "what dogs hear" analogy from an earlier thread on
emailcore.  Many an SMTP client doesn't look beyond the first digit of
the SMTP server's response.  Postfix is among them, perhaps Exim is not?

We do strive to emit the expected 2XY/4XY/5XY codes, but expect others
to use them consistently in return.

> However, while (apparently unlike many of the rest of you) I
> have not spent any significant time in more than a decade
> pouring over logs looking for mail transaction behavior
> anomalies, I don't believe "worked well enough for 22+ years"
> actually conveys much information.

What's worked well in this context is using the response from the last
line.  Actually emitting a different response code on the last last is
a much more recent "innovation", and is used very narrowly to turn away
abusive botnet nodes without the cost of tying up a heavy-weight SMTP
server process to handle the connection.

The postscreen(8) service is an optional feature, that is off by
default, and greet pauses are also off by default, even when
postscreen(8) is enabled.

Legitimate MTAs are typically not turned away by postscreen(8), so
seeing the "220-" followed by a "521" is by far the exception rather
than the rule, and if a legitimate MTA ends up retrying the message,
that could be argued to be a feature, the undeserved IP reputation
might have been resolved by then.

Indeed Postfix (as a client) defaults to retrying (another MX or defer
to later) after a 5XX greeting.  So Exim is not doing anything
unexpected.

> When I was last looking at those logs, the number of times I saw a
> server returning a multiline reply with mixed codes was zero or very
> close to it.

This both recent and unusual when the client is not a botnet, ...

> If all of the codes are the same, as SMTP requires, then things will
> work well no matter which one is picked.   Now, if you were to say
> "there haven't been any problems since this behavior first became
> common N years ago", that would be useful information.  But...

The variable multi-line response code server-side behaviour is new with
postscreen(8), which was first released in Feb 2011.

As mentioned above, it should be rather rare for a legitimate MTA as a
client to see such responses.  Users of postscreen(8) should be cautious
to not make it too aggressive in its policies.  The intent is to reduce
the number of bad connections that make it through to the real SMTP
servers, not eliminate all possibility of unwanted clients getting
through.  Light-weight first stage of defense in depth.

-- 
Viktor.

-- 
## 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/

Re: [exim] exim can't handle 521 response from remote MX

[Viktor Dukhovni via Exim-users]

On 4 Sep 2021, at 3:00 pm, Andrew C Aitchison  wrote:

> > The greet pause test is *specifically* designed to detect botnet spam
> > engines that don't wait for the complete multi-line response, and start
> > talking as soon as they detect the first line of the response.  That's
> > why the pause is after, and not before, "220-".  This is also why the
> > final response code is unavoidably different from the initial.
> 
> Are you saying that applies in this case ?
> If so, then exim is replying during the greet pause, which is a real bug ?

No, in this case, during or at the end of the greet pause this particular
systems was likely also configured to perform RBL checks and the like, and
the final "go away" response is a result of IP reputation, not a greet-pause
violation.  I expect that Exim handles multi-line responses correctly.

Regardless, the final status was not known at the time of the initial
"220-" greeting, and the "521" final line was the earliest opportunity
for the bad news.  At that point there is no point in continuing an SMTP
conversation, the client is presumed to be a botnet node or equivalent.
Rather than just drop the connection, a "521 go away" is used to finish
the multi-line response.

-- 
Viktor.

-- 
## 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/

Re: [exim] exim can't handle 521 response from remote MX

[Viktor Dukhovni via Exim-users]

On Sat, Sep 04, 2021 at 01:18:17PM -0400, John C Klensin wrote:

> > Absent a time-machine, and given that the ultimate decision is
> > made after the initial banner and greet pause, and that
> > refusing SMTP service (521 banner) is supposed to only happen
> > to botnet and similar clients, the postscreen(8) service has
> > no choice but to appear to change its mind after the initial
> > "220-".
> 
> If, by "change its mind", you mean "send a response sequence
> with different codes", not true.  First, if it cared about the
> SMTP spec (and I understand the reasons why it might not), it
> should accumulate whatever information it thinks useful before
> sending the initial connection response and then reply with
> either 220 or 521 (or something else) as it thinks appropriate,
> not try to mix them.

The greet pause test is *specifically* designed to detect botnet spam
engines that don't wait for the complete multi-line response, and start
talking as soon as they detect the first line of the response.  That's
why the pause is after, and not before, "220-".  This is also why the
final response code is unavoidably different from the initial.

> Second, it could return 220 (normally considered the correct response
> if it accepts mail from anyone) and then return 521 reply codes to any
> further commands until either those commands stopped coming or it go
> fed up and just closed the connection.

Once the client is believed to be an undesirable source of email
connections, we don't bother with niceties, and drop the connection.
The "521" is a best effort concession to rough protocol conformance.

Clients blacklisted by postscreen(8) don't get to talk SMTP the real
Postfix SMTP server.

> It does occur to me that a "no mail accepted right now" code
> might help to clarify the situation.  Watch for rfc5321bis-04.

In practice, there are just 5 response codes in SMTP:

2XY
4XY vs 421
5XY vs 521

No values of "XY" other than "21" make any difference to most
implementations.  So I don't see much point in new response codes.

What could perhaps be clarified further is the meaning of 5XY greetings.
Should a sending system that encounters a 5XX greeting defer or bounce
the message envelope.  The right answer depends on understanding when
5XX greetings occur in recent practice.

-- 
Viktor.

-- 
## 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/

Re: [exim] exim can't handle 521 response from remote MX

[Viktor Dukhovni via Exim-users]

On Sat, Sep 04, 2021 at 08:28:29PM +0300, Evgeniy Berdnikov via Exim-users 
wrote:

> IMHO, this discussion should be a motive for Exim and Postfix developers
> to add checks for consistency of SMTP status codes in multiline answers.
>
> Inconsistent protocol messages are indicators of software bugs, so they
> should lead to some attempts to work around (if possible) or switch to
> status "communication impossible -- permanent failure".

That's not going to happen in Postfix.  The basic philosophy is that
Postfix is the business of routing email messages, not gratuitous RFC
enforcement.  The postscreen(8) behaviour observed is not RFC-compliant,
but it is a not a bug, it is a deliberate trade-off among various
imperfect options.

The status code on the last line of a multi-line response is and will be
taken as authoritative, regardless of any other status codes on prior
lines of the response.  This has worked well enough for 22+ years.

The one related thing that might be worth changing is the default of:

http://www.postfix.org/postconf.5.html#smtp_skip_5xx_greeting

there used to be Microsoft Exchange servers that erroneously replied
with 5XX greetings under load, if that's no longer the case, we could
accept 5XX greetings as dispositive.

Thus, FWIW, just the like an Exim client that retries the message under
the reported conditions, a Postfix client in its default configuration
would also retry, but for a different reason.  It would see the 521
reply, but then treat that as though it were 421 and either try the next
MX host or defer.

-- 
Viktor.

-- 
## 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/

Re: [exim] exim can't handle 521 response from remote MX

[Viktor Dukhovni via Exim-users]

On Sat, Sep 04, 2021 at 03:42:39PM +0100, Jeremy Harris via Exim-users wrote:
> On 04/09/2021 15:03, Sabahattin Gucukoglu via Exim-users wrote:
> > perhaps Exim should consider the last line of a response instead of the 
> > first for purposes of evaluation?
> 
> I don't see a coherent argument for either direction,
> when they differ.
> 
> If postscreen is doing it so wrongly, it is the thing that needs fixing.

The postscreen(8) behaviour is unlikely to change.

Absent a time-machine, and given that the ultimate decision is made
after the initial banner and greet pause, and that refusing SMTP service
(521 banner) is supposed to only happen to botnet and similar clients,
the postscreen(8) service has no choice but to appear to change its mind
after the initial "220-".

We hope that any clients that are erroneously rejected legitimate MTAs
will get the hint, but the primary audience for postscreen bad news are
botnet SMTP engines, and what they make of the dropped connections is of
little interest.

FWIW, Postfix has always taken the SMTP status code from the last line
of a multi-line server response, but as you noted there is no RFC
requirement to do so, and the code is expected to not vary from line to
line.

This does mean that the few Postfix systems that enable greet pauses in
postscreen(8), and then reject a legitimate MTA they judge to have a
poor IP reputation, might end up dealing with repeated retries from such
MTAs.

Choosing the last response code has some advantages, but Exim is under
no obligation to do so.

-- 
Viktor.

-- 
## 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/

Re: [exim] Certificate name mismatch over VPN

[Viktor Dukhovni via Exim-users]

On Fri, Jul 30, 2021 at 07:29:33PM +0100, Alain D D Williams via Exim-users 
wrote:

> I get this error in B's log, it is complaining that M's certificate is using
> the public name, not the VPN name:
> 
> [78.32.209.33] SSL verify error: certificate name mismatch: 
> DN="/CN=freshmint.phcomp.co.uk" H="mint-vpn.phcomp.co.uk"
> 
> I could generate a certificate that is for 'mint-vpn' without much problem.
> 
> My question
> 
> How to I get exim on M to present the 'mint-vpn' certificate to
> connections that come over the VPN ?

Exim supports SNI-based server certificate selection.  Configure the
appropriate certificate for each SNI name.  Configure the VPN client
to send SNI, and otherwise default to the public IP name.

-- 
Viktor.

-- 
## 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/

Re: [exim] 4.95 RC0 - gnutls outgoing TLS cert verification broken

[Viktor Dukhovni via Exim-users]

On Sun, Jul 18, 2021 at 06:29:41PM +0200, Andreas Metzler via Exim-users wrote:

> I do not think so. Both exim 4.94.2 and gnutls-cli and s_client[1] are
> happy with the cert setup. It is a straightforward Let's Encrypt chain.
> 
>  0 s:CN = vsrv21575.customer.vlinux.de
>i:C = US, O = Let's Encrypt, CN = R3
>  1 s:C = US, O = Let's Encrypt, CN = R3
>i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
>  2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
>i:O = Digital Signature Trust Co., CN = DST Root CA X3

The self-signature on the DST Root CA X3 is SHA-1, any chance the new
Exim discriminates against SHA-1 self-signed roots?  This root CA
expires on 2021-09-30...

FWIW, OpenSSL will typically ignore the depth 2 certificate by finding
the "ISRG X1" root in the local trust store.  I don't know what GnuTLS
does, or whether the ISRG Root is installed in the GnuTLS trust store
on your system.

-- 
Viktor.

-- 
## 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/

Re: [exim] TLS error no shared cipher with SSL_accept: error in error

[Viktor Dukhovni via Exim-users]

On Mon, May 31, 2021 at 11:19:23PM +0200, Marcin Gryszkalis via Exim-users 
wrote:

> On 31.05.2021 22:59, Viktor Dukhovni via Exim-users wrote:
> >> I checked on exim built on FreeBSD 12 (with openssl 1.1) and it works fine 
> >> - but fails on other installation with openssl 1.0.
> > 
> > So what version of FreeBSD and OpenSSL are on the system with the
> > reported issue?  Support for negotiated ECDHE groups has evolved in
> > OpenSSL over time.  With older OpenSSL releases unless group selection
> > is explicitly set to "auto", the server picks some single default group,
> > which may not match this particular client's choice.
> 
> Sorry, I forgot to mention this.
> 
> This is OpenSSL 1.0.2u (base version for FreeBSD 11.4).

I see, the version of OpenSSL may be relevant here.

Is the server in question "mail.fuze.pl"?  On port 25 for that server I
see:

No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3757 bytes and written 475 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID: ...
Session-ID-ctx:
Master-Key: ...
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1622494851
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no

Which does show working support for ECDHE with P-256.  I'd also humbly
suggest not bothering with 4096 bit RSA certs, they're rather pointless.
The major CAs are all using 2048 bit RSA.  RSA 4096 is just bloat.

> I could switch to 1.1.1k from ports but that would require rebuilding 
> exim and the rest.
> I also could switch to libressl or even GnuTLS...

I would not recommend either of those two, but OpenSSL 1.1.1 would be a
much better choice, 1.0.2 has been EOL for quite some time.

-- 
Viktor.

-- 
## 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/

Re: [exim] TLS error no shared cipher with SSL_accept: error in error

[Viktor Dukhovni via Exim-users]

On Mon, May 31, 2021 at 11:08:22PM +0300, Evgeniy Berdnikov via Exim-users 
wrote:

> > SSL-Session:
> > Protocol  : TLSv1.2
> > Cipher: ECDHE-ECDSA-AES256-GCM-SHA384
> > Session-ID: ...
> > Session-ID-ctx:
> > Master-Key: ...
> > Key-Arg   : None
> > PSK identity: None
> > PSK identity hint: None
> > SRP username: None
> > Start Time: 1622470949
> > Timeout   : 7200 (sec)
> > Verify return code: 0 (ok)
> > 
> > 
> > But - I tried to specify the curve and it failed
> > 
> > openssl s_client -connect 127.0.0.1:465 -tls1_2 -cipher
> > ECDHE-ECDSA-AES256-GCM-SHA384 -curves prime256v1

This cipher requires the server to have an ECDSA certificate,
you've probably only configured an RSA certificate.  The
support SHA384 ciphers in OpenSSL 1.1.1 are:

$ OpenSSL_1_1_1/bin/openssl ciphers -s -tls1_2 -v ALL+SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)  
Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA 
Enc=Camellia(256) Mac=SHA384
ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=Camellia(256) 
Mac=SHA384

>  It looks like recent libssl considers ECDHE-ECDSA-AES256-GCM-SHA384
>  as TLSv1.3-only cipher. And post-handshake message mentions it
>  in some other manner:

That's not the case.

-- 
Viktor.

-- 
## 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/

Re: [exim] TLS error no shared cipher with SSL_accept: error in error

[Viktor Dukhovni via Exim-users]

On Mon, May 31, 2021 at 04:42:55PM +0200, Marcin Gryszkalis via Exim-users 
wrote:

> openssl s_client -connect 127.0.0.1:465 -tls1_2 -cipher 
> ECDHE-ECDSA-AES256-GCM-SHA384

> But - I tried to specify the curve and it failed
> 
> openssl s_client -connect 127.0.0.1:465 -tls1_2 -cipher 
> ECDHE-ECDSA-AES256-GCM-SHA384 -curves prime256v1
> 
> CONNECTED(0004)
> 34380884168:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake 
> failure:/usr/src/crypto/openssl/ssl/s3_pkt.c:1498:SSL alert number 40
> 34380884168:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake 
> failure:/usr/src/crypto/openssl/ssl/s3_pkt.c:659:
> 
> prime256v1 = secp256r1
> 
> I checked on exim built on FreeBSD 12 (with openssl 1.1) and it works fine - 
> but fails on other installation with openssl 1.0.

So what version of FreeBSD and OpenSSL are on the system with the
reported issue?  Support for negotiated ECDHE groups has evolved in
OpenSSL over time.  With older OpenSSL releases unless group selection
is explicitly set to "auto", the server picks some single default group,
which may not match this particular client's choice.

-- 
Viktor.

-- 
## 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/

Re: [exim] TLS error no shared cipher with SSL_accept: error in error

[Viktor Dukhovni via Exim-users]

On Mon, May 31, 2021 at 01:44:39PM +0200, Marcin Gryszkalis via Exim-users 
wrote:

> exim's cipher list is wide 
> ALL:!EXPORT:!DES:!RC2:!RC4:!MD5:!PSK:!aNULL:!eNULL:!EXP:!SRP:!DSS:!DHE:!3DES

What is the reason for disabling DHE ciphers?  And though in modern
OpenSSL releases there are no longer any "LOW" ciphers, for some reason
you've left those potentially enabled, while making extra sure to delete
the export ones twice.  The "PSK" and "SRP" ciphers are harmless, since
they're off by default anyway, without appropriate configuration.

This cipher list looks rather kludgey.  Try "DEFAULT".

> 40884 openssl option, adding to 03104000: 0200 (no_sslv3 +no_sslv2 
> +cipher_server_preference)
> 40884 openssl option, adding to 03104000: 0100 (no_sslv2 
> +cipher_server_preference)
> 40884 openssl option, adding to 03104000: 0040 
> (cipher_server_preference)
> 40884 setting SSL CTX options: 0x3504000
> 40884 Diffie-Hellman initialized from default with 2048-bit prime
> 40884 ECDH OpenSSL 1.0.2+ temp key parameter settings: autoselection
> 40884 tls_certificate file '/letsencrypt/certs/mail.domain.com/fullchain.pem'
> 40884 tls_privatekey file  '/letsencrypt/certs/mail.domain.com/privkey.pem'
> 40884 Initialized TLS
> 40884 required ciphers: 
> ALL:!EXPORT:!DES:!RC2:!RC4:!MD5:!PSK:!aNULL:!eNULL:!EXP:!SRP:!DSS:!DHE:!3DES
> 40884 host in tls_verify_hosts? no (option unset)
> 40884 host in tls_try_verify_hosts? no (end of list)
> 40884 SMTP>> 220 TLS go ahead
> 40884 Calling SSL_accept
> 40884 SSL_accept: before/accept initialization
> 40884 SSL3 alert write:fatal:handshake failure

That rather looks like your own server is initiating the handshake
failure.  It is writing the alert, not reading a remote alert.

> 40884 SSL_accept: error in error
> 40884 SSL_accept: error in error

I haven't seen that one much.  Perhaps an issue in the Exim OpenSSL glue
code.

> 40884 TLS error '(SSL_accept): error:1408A0C1:SSL 
> routines:ssl3_get_client_hello:no shared cipher'
> 
> 40884 LOG: MAIN
> 40884   TLS error on connection from mail.externaldomain.com [1.2.3.4] 
> I=[192.168.1.3]:25 (SSL_accept): error:1408A0C1:SSL 
> routines:ssl3_get_client_hello:no shared cipher
> 40884 TLS failed to start

The server does not believe it has any shared ciphers available.  You
should also check the system-wide "openssl.cnf" file for any vendor
configured protocol or cipher restrictions.

> 
> wireshark dump from client hello

This does not look like the entire client hello message.

> 
>  Cipher Suites Length: 24
>  Cipher Suites (12 suites)
>  Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
> (0xc02b)
>  Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
>  Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
> (0xc023)
>  Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
>  Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
>  Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
>  Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
>  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
>  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
>  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
>  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
>  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
>  Compression Methods Length: 1
>  Compression Methods (1 method)
>  Compression Method: null (0)
>  Extensions Length: 51
>  Extension: supported_groups (len=4)
>  Type: supported_groups (10)
>  Length: 4
>  Supported Groups List Length: 2
>  Supported Groups (1 group)
>  Supported Group: secp256r1 (0x0017)
>  Extension: ec_point_formats (len=2)
>  Type: ec_point_formats (11)
>  Length: 2
>  EC point formats Length: 1
>  Elliptic curves point formats (1)
>  EC point format: uncompressed (0)
>  Extension: signature_algorithms (len=20)
>  Type: signature_algorithms (13)
>  Length: 20
>  Signature Hash Algorithms Length: 18
>  Signature Hash Algorithms (9 algorithms)
>  Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
>  Signature Hash Algorithm Hash: SHA256 (4)
>  Signature Hash Algorithm Signature: RSA (1)
>  Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
>  Signature Hash Algorithm Hash: SHA384 (5)
>  Signature Hash Algorithm Signature: RSA (1)
>  Signature Algorithm: rsa_pkcs1_sha1 (

Re: [exim] Error compile exim 4.94.2

[Viktor Dukhovni via Exim-users]

On Wed, May 05, 2021 at 06:04:11PM +0200, Sławomir Dworaczek via Exim-users 
wrote:


> exim.o: In function `exim_gettime':
> exim.c:(.text+0xfbe): undefined reference to `clock_gettime'
> exim.o: In function `main':
> exim.c:(.text+0x1894): undefined reference to `clock_gettime'
> collect2: ld returned 1 exit status
> make[1]: *** [exim] Error 1
> 
> gcc version 4.5.2 (GCC)

What operating system and Glibc (or other C library) version?

On a Fedora 31 system:

NAME
   clock_getres, clock_gettime, clock_settime - clock and time functions

SYNOPSIS
   #include 

   int clock_getres(clockid_t clk_id, struct timespec *res);

   int clock_gettime(clockid_t clk_id, struct timespec *tp);

   int clock_settime(clockid_t clk_id, const struct timespec *tp);

--->   Link with -lrt (only for glibc versions before 2.17).

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):  

   
   clock_getres(), clock_gettime(), clock_settime():
  _POSIX_C_SOURCE >= 199309L

On a FreeBSD 12.2 system these functions are in the C library, and the
manpage reports:

STANDARDS
 The clock_gettime(), clock_settime(), and clock_getres() system calls
 conform to IEEE Std 1003.1b-1993 (“POSIX.1b”).

-- 
Viktor.

-- 
## 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/

Re: [exim] Exim 4.94.2 - security update released (DANE fix)

[Viktor Dukhovni via Exim-users]

The DANE fix:

-   ob->tls_sni = sx->first_addr->domain;   /* force SNI */
+   ob->tls_sni = sx->conn_args.host->name; /* force SNI */

replaces the recipient domain with the MX hostname.

When the MX host is a CNAME, is that necessarily the same as
the TLSA base domain?

How does Exim handle MX hosts that are CNAMEs?  Are fully
expanded (secure at every step, with fallback to the original
name) CNAMEs used for TLSA lookups (per RFC7672?)?

-- 
Viktor.


-- 
## 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/

Re: [exim] DANE vs unknown CA

[Viktor Dukhovni via Exim-users]

On Mon, May 03, 2021 at 06:33:24PM +0200, Heiko Schlittermann wrote:

> For the upcoming 4.94.2 a patch is part of the 4.94.2+fixes branch
> already. It will be cherry-picked to master soon.

Got a pointer to the patch?

> Thank you again for your fast response yesterday.

You're welcome.  Yes, there's a non-trivial number of domains where
production of the correct certificate depends on sending the TLSA base
domain as the SNI value.  I am not a fan of per-host-domain MX
hostnames, and associated reliance on SNI, but for some mysterious
reason there are operators who prefer this model.

-- 
Viktor.

-- 
## 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/

Re: [exim] DANE vs unknown CA

[Viktor Dukhovni via Exim-users]

On Sun, May 02, 2021 at 04:11:30PM -0400, Viktor Dukhovni via Exim-users wrote:

> However, Postfix no longer uses my danessl library, as of Postfix 3.6
> (which I'm running), it uses the DANE code in OpenSSL 1.1.x.  So there
> are a few differences here...

I built the latest snapshot of Postfix 3.5 (which uses code
fundamentally similar to the DANE library in Exim, which is
a variant of that Postfix code, carved out as a independent
library).  I linked Postfix 3.5 against OpenSSL 1.1.1j (also
built from source).  FWIW, though this should not matter, the
operating system was MacOS Big Sur.

This also worked:

$ posttls-finger -c "[smtp.dukhovni.org]"
posttls-finger: using DANE RR: _25._tcp.smtp.dukhovni.org IN TLSA 3 1 1 
DB:95:0F:0E:00:30:90:0B:7E:5F:29:FB:80:D8:43:26:89:85:F3:86:D1:91:5E:E2:00:0D:52:7B:5F:36:9C:17
posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: depth=0 matched end 
entity public-key sha256 
digest=DB:95:0F:0E:00:30:90:0B:7E:5F:29:FB:80:D8:43:26:89:85:F3:86:D1:91:5E:E2:00:0D:52:7B:5F:36:9C:17
posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: subjectAltName: 
mournblade.imrryr.org
posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: Matched subjectAltName: 
smtp.dukhovni.org
posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: subjectAltName: 
smtp.imrryr.org
posttls-finger: smtp.dukhovni.org[100.2.39.101]:25 CommonName 
mournblade.imrryr.org
posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: 
subject_CN=smtp.dukhovni.org, issuer_CN=R3, 
fingerprint=4D:6F:56:47:08:9A:69:63:1E:AE:6E:6D:DF:76:CF:6F:02:03:2E:2E, 
pkey_fingerprint=5E:13:73:70:CB:0A:4C:AF:A5:3D:02:53:69:A3:FB:B0:AE:11:72:5A
posttls-finger: Verified TLS connection established to 
smtp.dukhovni.org[100.2.39.101]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 
(256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) 
server-digest SHA256

If the reported problem is reproducible, barring further evidence it
feels like a regression in Exim, rather than OpenSSL or the contributed
DANE code.

I am aware that this looks like passing buck, and as the guest Postfix
guy on this list, I should ideally have a stronger basis for blaming
Exim.  Sorry about that, especially if I turn out to be wrong, but
that's the best lead I have at the moment...

In order to make progress, the test matrix needs to be broadened to
include OpenSSL 1.1.1k and additional versions of Exim.  I don't know of
any substatial changes in the upstream contributed DANE code since it
was merged into Exim, but FWIW, it can be found at:

https://github.com/vdukhovni/ssl_dane

Commit history at:

https://github.com/vdukhovni/ssl_dane/commits/master

My impression is that the version in Exim is current, but there
could have been changes in the surrounding glue (DNS lookups, or
other plumbing of DANE policy before getting down the nuts and
bolts of actually doing the handshake) that perhaps introduced
a defect.

-- 
Viktor.

-- 
## 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/

Re: [exim] DANE vs unknown CA

[Viktor Dukhovni via Exim-users]

On Sun, May 02, 2021 at 04:11:30PM -0400, Viktor Dukhovni via Exim-users wrote:

> With Postfix, I get:
> 
> # posttls-finger -c "[serv02.atvirtual.eu]"
> posttls-finger: serv02.atvirtual.eu[2a0b:1640:1:1:1:1:179:ba44]:25: 
> Matched DANE EE certificate at depth 0: 3 1 1 
> 7E95E999DA41CDD250EB3F97C397BFDB087AEAB914EDBDF1B5B6C49457923048
> posttls-finger: serv02.atvirtual.eu[2a0b:1640:1:1:1:1:179:ba44]:25: 
> subject_CN=serv02.atvirtual.eu, issuer_CN=AlphaSSL CA - SHA256 - G2, 
> fingerprint=70:4C:CF:00:75:BF:47:BB:D4:C7:D1:B4:E6:63:2B:52:E0:40:97:4F:3E:F1:18:C5:F7:D6:B3:E6:43:25:6C:69,
>  
> pkey_fingerprint=7E:95:E9:99:DA:41:CD:D2:50:EB:3F:97:C3:97:BF:DB:08:7A:EA:B9:14:ED:BD:F1:B5:B6:C4:94:57:92:30:48
> posttls-finger: Verified TLS connection established to 
> serv02.atvirtual.eu[2a0b:1640:1:1:1:1:179:ba44]:25: TLSv1.2 with cipher 
> ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

FWIW, there's no evidence of any recent changes in the associated TLSA
records, unless the DANE survey happened to miss a brief glitch.  The
history table shows a single TLSA record unchanged in 3+ years:

{
  "qname": "_25._tcp.serv02.atvirtual.eu",
  "usage": 3,
  "selector": 1,
  "mtype": 1,
  "data": 
"7e95e999da41cdd250eb3f97c397bfdb087aeab914edbdf1b5b6c49457923048",
  "stime": "2018-04-13",
  "etime": null
}

-- 
Viktor.

-- 
## 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/

Re: [exim] DANE vs unknown CA

[Viktor Dukhovni via Exim-users]

On Sun, May 02, 2021 at 09:13:55PM +0200, Heiko Schlittermann via Exim-users 
wrote:

> this is especially for Victor. I'm out of ideas.
> 
> Dane verify_cert verify_callback_client_dane: BAD depth 1
> /C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2 - err 20
> 'unable to get local issuer certificate' SSL3 alert
> write:fatal:unknown CA

Do connections to my domain work (also DANE 3 1 1, be it with an LE
cert).

> LOG: MAIN
>   DANE attempt failed; TLS connection to serv02.atvirtual.eu
>   [185.206.180.72]: (SSL_connect): error:1416F086:SSL
>   routines:tls_process_server_certificate:certificate verify
>   failed

With Postfix, I get:

# posttls-finger -c "[serv02.atvirtual.eu]"
posttls-finger: serv02.atvirtual.eu[2a0b:1640:1:1:1:1:179:ba44]:25: Matched 
DANE EE certificate at depth 0: 3 1 1 
7E95E999DA41CDD250EB3F97C397BFDB087AEAB914EDBDF1B5B6C49457923048
posttls-finger: serv02.atvirtual.eu[2a0b:1640:1:1:1:1:179:ba44]:25: 
subject_CN=serv02.atvirtual.eu, issuer_CN=AlphaSSL CA - SHA256 - G2, 
fingerprint=70:4C:CF:00:75:BF:47:BB:D4:C7:D1:B4:E6:63:2B:52:E0:40:97:4F:3E:F1:18:C5:F7:D6:B3:E6:43:25:6C:69,
 
pkey_fingerprint=7E:95:E9:99:DA:41:CD:D2:50:EB:3F:97:C3:97:BF:DB:08:7A:EA:B9:14:ED:BD:F1:B5:B6:C4:94:57:92:30:48
posttls-finger: Verified TLS connection established to 
serv02.atvirtual.eu[2a0b:1640:1:1:1:1:179:ba44]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

I have: openssl-1.1.1k

However, Postfix no longer uses my danessl library, as of Postfix 3.6
(which I'm running), it uses the DANE code in OpenSSL 1.1.x.  So there
are a few differences here...

But I still have some Perl code lying around that uses that library and
it worked against the host in question:

serv02.atvirtual.eu. IN MX 0 serv02.atvirtual.eu.
serv02.atvirtual.eu. IN A 185.206.180.72
serv02.atvirtual.eu. IN  2a0b:1640:1:1:1:1:179:ba44
_25._tcp.serv02.atvirtual.eu. IN TLSA 3 1 1 
7e95e999da41cdd250eb3f97c397bfdb087aeab914edbdf1b5b6c49457923048
;; SSL: protocol = TLSv1.2, cipher = ECDHE-RSA-AES128-GCM-SHA256 (128 bits)
;; Passed(depth 0): serv02.atvirtual.eu. IN TLSA 3 1 1 
7e95e999da41cdd250eb3f97c397bfdb087aeab914edbdf1b5b6c49457923048

as did posttls-finger from Postfix 3.5 (in-situ build in the source
tree):

$ LD_LIBRARY_PATH=$PWD/lib ./bin/posttls-finger -o compatibility_level=3 -c 
'[serv02.atvirtual.eu]'
posttls-finger: using DANE RR: _25._tcp.serv02.atvirtual.eu IN TLSA 3 1 1 
7E:95:E9:99:DA:41:CD:D2:50:EB:3F:97:C3:97:BF:DB:08:7A:EA:B9:14:ED:BD:F1:B5:B6:C4:94:57:92:30:48
posttls-finger: serv02.atvirtual.eu[185.206.180.72]:25: depth=0 matched end 
entity public-key sha256 
digest=7E:95:E9:99:DA:41:CD:D2:50:EB:3F:97:C3:97:BF:DB:08:7A:EA:B9:14:ED:BD:F1:B5:B6:C4:94:57:92:30:48
posttls-finger: serv02.atvirtual.eu[185.206.180.72]:25: Matched 
subjectAltName: serv02.atvirtual.eu
posttls-finger: serv02.atvirtual.eu[185.206.180.72]:25 CommonName 
serv02.atvirtual.eu
posttls-finger: serv02.atvirtual.eu[185.206.180.72]:25: 
subject_CN=serv02.atvirtual.eu, issuer_CN=AlphaSSL CA - SHA256 - G2, 
fingerprint=22:72:97:BE:67:C7:33:89:8B:F8:95:02:2F:41:5F:C2:25:73:0B:8C, 
pkey_fingerprint=9E:6C:44:E3:C9:52:B7:F4:FA:37:D2:0D:47:31:46:38:CC:C2:D6:3A
posttls-finger: Verified TLS connection established to 
serv02.atvirtual.eu[185.206.180.72]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

> The Exim 4.94.2 producing this uses openssl 1.1.1j With older Exim
> 4.92.3 it works (openssl 1.1.0i)

That's interesting, can you try 1.1.1k?

> Any idea? For what I understand about DANE, it shouldn't care about
> the CA cert, should it? (The TLSA record uses 3 1 1)

Correct, the "3 1 1" record should be dispositive, and with a matching
"3 1 1" there should not even be a call to the OpenSSL chain building
code, the "chain" should consist of just the leaf cert.

-- 
Viktor.

-- 
## 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/

Re: [exim] Development Request for Selectable Opportunistic vs. Forced TLS

[Viktor Dukhovni via Exim-users]

On Fri, Apr 30, 2021 at 01:42:51AM -0400, Stan Haimes, MD via Exim-users wrote:

> For most messages, sending the outgoing email by Opportunistic TLS would 
> be desirable and perfect.
> 
> However, if the Subject field contains "[Secure]", I would like that to 
> trigger different message handling by EXIM.

Other than your choice of a subject pattern as the trigger, you're
looking for something akin to the REQUIRETLS ESMTP extension:

https://www.ietf.org/rfc/rfc8689.html

but it seems only for the first message delivery hop, and without a
commitment by the receiving MTA to honour the TLS requirement
end-to-end, or meaningful authentication of the MX host.

If the presence of the header in question can be used to influence the
selection of the smtp "router" (I think that's the right term in Exim,
in Postfix terminology that'd be a "transport"), then likely the TLS
policy of mandatory, but possibly unauthenticated TLS could just be a
router property.

So this would likely not require new code, or at most very little code,
just enough to ensure that the right "router" is selected for non-local
message recipients.  The only thing that requires care is to avoid
inadvertent routing of local recipients via SMTP, thus the "router"
selection logic must not affect local or other non-SMTP recipients:

if (remote && subject_tagged_secure
then
mandatory_tls_router
else
normal_router_selection
endif

-- 
Viktor.

-- 
## 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/

Re: [exim] haproxy smtps problem

[Viktor Dukhovni via Exim-users]

On Fri, Apr 16, 2021 at 10:09:37PM +0200, Heiko Schlittermann via Exim-users 
wrote:

> > Incoming connections come from an haproxy on that vps server. I've been able
> > to route the incoming connections toward port 25. Now I need to enable the
> > authentication through port 465, but if I enable it on haproxy, my exim
> > server is not able to interpret the incoming message and I see something
> > like: "SMTP syntax error in "\026\003\001\001" on the exim log file.
> 
> - The "\026\…." *could* be the proxy v2 proxy header (not sure about the 
> exact value)

It isn't, it is a TLS client HELLO message.  Possibilities:

- The proxy handling has already been done, and the issue
  is that the SMTP server is not configured to do "implicit
  TLS" on this port (expects STARTTLS).

- The proxy is not actually handling this port and raw
  TLS is hitting the SMTP server when it is expecting
  the proxy handshake.

My money is on the first variant (it says "SMTP syntax", not
"haproxy syntax" after all).

-- 
Viktor.

-- 
## 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/

Re: [exim] 8192 length SSL keys

[Viktor Dukhovni via Exim-users]

On Mon, Apr 12, 2021 at 02:39:41PM -0600, The Doctor via Exim-users wrote:

> Does Exim support 8192 bit SSL keys?

Even 4096-bit RSA keys are noticeably slow/bulky, none of the public CAs
are using anything stronger than 4096-bit RSA keys and most are using
2048.  Why on earth would you want 8192 bits?

If you actually want practical strong keys, use ECDSA P256, Ed25519
or Ed449.

> IF so why is Thunderbird choking?

Wrong question IMHO, don't use 8192 bit RSA, it is not a good idea.

-- 
Viktor.

-- 
## 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/

[exim] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low

[Viktor Dukhovni via Exim-users]

[ If your domain is DNSSEC signed and employs NSEC3 for authenticated
  denial of existence, or you're considering deploying DNSSEC at some
  point, read on... ]

RFC 5155 defined NSEC3 iterations to scale up with the RSA/DSA key size
up to perhaps as high as 2500 iterations for 4096-bit keys.  In
retrospect such a generous iteration cap is counter-productive.  It is
neither particularly effective at keeping your zone content "secret",
nor sufficiently cheap to avoid negative impact on authoritative and
iterative resolver performance.

In that light, Wes Hardaker and I have authored an Internet-Draft that
strongly recommends setting the NSEC3 additional iteration count to 0
(at least one initial SHA1 hash is always performed).

https://tools.ietf.org/html/draft-hardaker-dnsop-nsec3-guidance-02

Today, the Knot resolver became the first one to cap NSEC3 iterations
for now at 150, but this will likely be reduced further (perhaps
ultimately as low as ~25):

https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.3.1

and is expected to be done by more resolvers.

Since iteration counts above the resolver cap make denial-of-existence
for the entire zone insecure, it is important that all domains with a
high NSEC3 iteration count proactively lower it ideally to 0, but
otherwise ~10 or less.

While DNSSEC still precludes forged positive answers, any signed
NXDomain or NODATA NSEC3 response can be replayed for any query,
regardless of the qname.

This impacts any protocol in which negative responses have security
consequences.  Potential exposures include:

- Forged absence of RFC7672 DANE SMTP TLSA records
- Forged absence of CAA records
- Forged absence of HTTPS records enabling various downgrades
- ...

A number of TLDs have already lowred their iteration counts, and it is
expected that most of the rest will follow soon.

TLD before  after
--- --  -
la 150  1
xn--q7ce6a 150  1
blue   100 10
green  100 10
lat100 10
mx 100 10
pink   100 10
red100 10
schaeffler 100 10
by 100  3
creditunion100  3
ally   100  1
autos  100  1
boats  100  1
homes  100  1
motorcycles100  1
yachts 100  1

If your DNS zone is configured to use NSEC3, please:

- Reduce the iteration count to 10 or less.

- Disable opt-out, you're very unlikely to need it.

- Either rotate the salt each time you sign, or skip
  it entirely.  But a short fixed salt is harmless if
  leaving it alone easier than changing it.

Of course, if your zone is small enough (just the zone apex and a
handful of already public or easy to guess names) or in any case has
nothing to hide, even better is to use just plain NSEC.  You get smaller
negative replies (less exposure to DoS) and more effective negative
caching at resolvers.  So in many cases, it is even simpler to abandon
NSEC3 entirely.  Please also consider the pros/cons of that option.

-- 
Viktor.

-- 
## 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/

Re: [exim] Pipelining QUIT after data

[Viktor Dukhovni via Exim-users]

> On Mar 6, 2021, at 12:03 PM, Jeremy Harris via Exim-users 
>  wrote:
> 
> I do find, when implementing it, that both Outlook and Google screw up,
> as server, when Exim does it.  In both cases, CHUNKING had also been used.
> I wonder if anyone else has observed this?

Good question, Postfix supports BDAT only in the SMTP server, and does not
use it in the SMTP client.  So the Postfix experience with PIPELINING of
DOT+QUIT is limited to "DATA" not "BDAT".

> I see no theoretical bar to pipelining QUIT after BDAT LAST,

Well, RFC3030 does not unambiguously specify whether BDAT LAST is a
synchronisation point or not. :-(

In [PIPE] https://tools.ietf.org/html/rfc2920#section-3.1 we have:

   Once the client SMTP has confirmed that support exists for the
   pipelining extension, the client SMTP may then elect to transmit
   groups of SMTP commands in batches without waiting for a response to
   each individual command. In particular, the commands RSET, MAIL FROM,
   SEND FROM, SOML FROM, SAML FROM, and RCPT TO can all appear anywhere
   in a pipelined command group.  The EHLO, DATA, VRFY, EXPN, TURN,
   QUIT, and NOOP commands can only appear as the last command in a
   group since their success or failure produces a change of state which
   the client SMTP must accommodate. (NOOP is included in this group so
   it can be used as a synchronization point.)

   Additional commands added by other SMTP extensions may only appear as
   the last command in a group unless otherwise specified by the
   extensions that define the commands.

   The actual transfer of message content is explicitly allowed to be
   the first "command" in a group. That is, a RSET/MAIL FROM sequence
   used to initiate a new message transaction can be placed in the same
   group as the final transfer of the headers and body of the previous
   message.

With this, on the one hand we're allowed to pipeline additional commands
(e.g. QUIT) after message transfer, but on the other hand "BDAT" is not
one of the mentioned commands, and so pipelining for BDAT should be
clearly defined in RFC3030, but it is sadly not, beyond just an example:

https://tools.ietf.org/html/rfc3030#section-4.2

   R: 
   R: 220 cnri.reston.va.us SMTP service ready
   S: EHLO ymir.claremont.edu
   R: 250-cnri.reston.va.us says hello
   R: 250-PIPELINING
   R: 250-BINARYMIME
   R: 250 CHUNKING
   S: MAIL FROM: BODY=BINARYMIME
   S: RCPT TO:
   S: RCPT TO:
   R: 250 ... Sender and BINARYMIME ok
   R: 250 ... Recipient ok
   R: 250 ... Recipient ok

[ Have to wait after last recipient and first BDAT, to see whether
  MAIL FROM and at least one of the recipients have been accepted.
  But this is not specified clearly. ]

   S: BDAT 10
   S: (First 10 octets of canonical MIME message data)
   S: BDAT 324
   S: (Remaining 324 octets of canonical MIME message data)
   S: BDAT 0 LAST

[ Here QUIT is sent separately, with no explanation. ]

   R: 250 10 octets received
   R: 250 324 octets received
   R: 250 Message OK, 100324 octets received
   S: QUIT
   R: 221 Goodbye


> but if
> servers out there are are commonly broken I may need to restrict the
> implementation.  Either non-Chunking only, or a  hostlist option on
> the transport, come to mind.

This should probably be raised on the ietf-smtp list, and perhaps
an erratum filed against RFC3030.  It really has to specify how
BDAT is pipelined much more clearly.

Postfix does not bother with client-side BDAT, because SIZE=...
is sent as part of MAIL, and so the main reason for sending chunks
(avoiding large transmission of content which the remote server will
not accept) is rarely applicable.

-- 
Viktor.


-- 
## 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/

Re: [exim] syscall: Connection reset by peer (outlook.com)

[Viktor Dukhovni via Exim-users]

On Sat, Feb 27, 2021 at 10:31:50PM +0100, Heiko Schlittermann via Exim-users 
wrote:

> I assume, that a connection coming *from* outlook to you. They (outlook)
> seem to have the bad habit to forcefully tear down the connection as
> soon as they received your "250 OK". They don't send a QUIT, nor do they
> perform a regular SSH "good bye" handshake. They just behave rude.

If this is indeed a connection closed after message delivery, there are
a few possibilities.

1.  ESMTP PIPELINING was not used to pipeline "DOT" and "QUIT",
the server sends QUIT separately, but does not wait for a
response and hangs up.

Not waiting for a QUIT response is not uncommon, but PIPELINING
typically hides this because the sender will of course wait for
the DOT response, and it will typically be sent together with
the QUIT response, when the commands were pipelined.

2.  Exim is sending a TLS close_notify alert when closing the write
side of its SSL connection, and reporting any I/O errors that
may occur when doing that.  Here, it may be reasonable to not
report these.  SMTP is not a protocol where data truncation
is a concern, SMTP framing takes care of that above the TLS
layer.

3.  The client does not even send QUIT, and just closes the channel,
but here, I would not expect the server to send any SMTP
response, so if it is still writing something, it is probably
again the TLS close_notify (as in 2 above).

Perhaps more, but these are the ones that come to mind.

-- 
Viktor.

-- 
## 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/

Re: [exim] Exim smtp client and Self Signed Certificate

[Viktor Dukhovni via Exim-users]

On Wed, Jan 27, 2021 at 12:40:33PM +0800, Kevin Shell via Exim-users wrote:

> Is it possible to make Exim smtp client not perform certificate chain
> checks, instead trusting remote SSL/TLS peer certificate by Subject
> Key Identifier or fingerprint?
> 
> I want to trust some self signed certificates.

Separately from the how, which I am not the right person to answer, it
is worth noting that the "Subject Key Identifier" is NOT a trustworthy
proxy for the underlying key.  The creator of the certificate is free
to set it to any value of their choice, e.g. to the value for some
other unrelated key.

Therefore, you MUST NEVER conclude posession of the private key based on
a subject key identifier match.

Perhaps you were thinking of a DANE-style SPKI digest match, with the
digest computed by the client directly from the public key (rather that
extracted from an extension in the certificate).  Those would be fine.
There's precedent for supporting such fingerprint matching in at least
one other MTA.

I also assume that the check in question would be destination domain or
MX host dependent, so that different EE certs or public key digests,
would be trusted for different sites.  So you'd need some sort of
lookup table to match the peer cert or key against the policy for
the given nexthop.

If you operate both ends, one approach would just be to use DANE, which
Exim is known to support, and which obviates the need for all those
per-destination policy tables (for the DNSSEC-signed domains that
implement DANE TLSA records).

-- 
Viktor.

-- 
## 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/

Re: [exim] PLEASE NOTE: Upcoming changes in Let's Encrypt issuer certificates

[Viktor Dukhovni via Exim-users]

On Mon, Sep 21, 2020 at 02:07:00PM -0600, Dan Egli via Exim-users wrote:

> You didn't answer my main question of how do I determine if I need to 
> upgrade my LetsEncrypt certificates.

If you're not using DANE, there's nothing special you need to do with
your Let's Encrypt certificates.  Just run "certbot" or your preferred
ACME client on a regular basis to make sure the certs have not expired.

> And although I'm going to google it, What the %$&@%$* is DANE? :-[

https://tools.ietf.org/html/rfc7672#section-1.3

-- 
Viktor.

-- 
## 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/

Re: [exim] PLEASE NOTE: Upcoming changes in Let's Encrypt issuer certificates

[Viktor Dukhovni via Exim-users]

On Mon, Sep 21, 2020 at 04:23:55AM -0200, Viktor Dukhovni via Exim-users wrote:

> Links to the actual certificates can be found at:
> 
>   https://letsencrypt.org/certificates/
>   https://letsencrypt.org/certs/lets-encrypt-r3.pem
>   https://letsencrypt.org/certs/lets-encrypt-e1.pem
> 
> The "2 1 1" digests of "R3" and "E1" are (but don't take my word for it,
> re-compute these for yourself):
> 
>   ; $ tlsagen lets-encrypt-r3.pem smtp.example.org 2 1 1
>   ;
>   _25._tcp.smtp.example.org. IN TLSA 2 1 1 
> 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D
> 
>   ; $ tlsagen lets-encrypt-e1.pem smtp.example.org 2 1 1
>   ;
>   _25._tcp.smtp.example.org. IN TLSA 2 1 1 
> 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10

It was correclty noted in:


https://community.letsencrypt.org/t/dane-and-upcoming-le-issuer-certs/134172/2?u=ietf-dane

that the "backup" CAs should also be listed, as LE might need to switch
to using them in an emergency without prior notice.

Therefore the full list of DANE-TA(2) digests to publish (when relying
on these rather than "3 1 1" records) is:

; (These can be retired soon, but not just yet)
;
; letsencryptauthorityx3.pem
; letsencryptauthorityx4.pem 
;
_25._tcp.smtp.example.org. IN TLSA 2 1 1 
60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517616E8A18
_25._tcp.smtp.example.org. IN TLSA 2 1 1 
B111DD8A1C2091A89BD4FD60C57F0716CCE50FEEFF8137CDBEE0326E02CF362B

; (May not be needed if your leaf cert is RSA, ECDSA certs
; will I expect be soon signed with one of these).
;
; lets-encrypt-e1.pem
; lets-encrypt-e2.pem
;
_25._tcp.smtp.example.org. IN TLSA 2 1 1 
276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10
_25._tcp.smtp.example.org. IN TLSA 2 1 1 
BD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422E0C89270

; (May not be needed if your leaf cert is ECDSA, once 
; ECDSA certificate issuance cuts over to e1/e2).
;
; lets-encrypt-r3.pem
; lets-encrypt-r4.pem

-- 
Viktor.

-- 
## 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/

[exim] PLEASE NOTE: Upcoming changes in Let's Encrypt issuer certificates

[Viktor Dukhovni via Exim-users]

Please note that the Let's Encrypt intermediate CA certificate "X3" will soon be
phased out in favour of "R3" and "E1" which have new keys, and so any DANE TLSA
"2 1 1" records matching "X3" will not match "R3" or "E1".

 https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html

If you are using Let's Encrypt with DANE-TA(2) [issuer CA] TLSA records, any 
extant
"2 1 1" records need to be augmented soon with additional records matching the 
new
"R3" and "E1", in advance of these reissuing your certificates.

Failure to act in time is likely to result in an outage once renewals switch to
signing via "R3" or "E1".

Links to the actual certificates can be found at:

https://letsencrypt.org/certificates/
https://letsencrypt.org/certs/lets-encrypt-r3.pem
https://letsencrypt.org/certs/lets-encrypt-e1.pem

The "2 1 1" digests of "R3" and "E1" are (but don't take my word for it,
re-compute these for yourself):

; $ tlsagen lets-encrypt-r3.pem smtp.example.org 2 1 1
;
_25._tcp.smtp.example.org. IN TLSA 2 1 1 
8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D

; $ tlsagen lets-encrypt-e1.pem smtp.example.org 2 1 1
;
_25._tcp.smtp.example.org. IN TLSA 2 1 1 
276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10

The above were computed with the attached "tlsagen" script, but it is
prudent to also check with tools from other sources, this email message
could well have been a forgery (I hope your copy matches what I sent).

-- 
Viktor.



tlsagen
Description: Binary data


-- 
## 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/