Thanks to both Jeremy and Jasen -
@jeremy - what logs would you like to see?
@jasen - not open to adding that many IP's to the white list, what with the billions of spammers
that use Microsoft mail services including O365 trial accounts to spam....
Sorry I'm relatively inexperienced here, so thanks very much.
John
-----Original Message-----
From: Exim-users [
mailto:exim-users-bounces+john=stegenga.net@exim.org] On Behalf Of
exim-users-request@???
Sent: Saturday, October 30, 2021 8:00 AM
To: exim-users@???
Subject: Exim-users Digest, Vol 209, Issue 29
Send Exim-users mailing list submissions to
exim-users@???
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.exim.org/mailman/listinfo/exim-users
or, via email, send a message with subject or body 'help' to
exim-users-request@???
You can reach the person managing the list at
exim-users-owner@???
When replying, please edit your Subject line so it is more specific than "Re: Contents of Exim-users
digest..."
Today's Topics:
1. Hi Exim users - problem with hybrid exchange domain sending
to exim. (John Stegenga)
2. Re: Hi Exim users - problem with hybrid exchange domain
sending to exim. (Jeremy Harris)
3. Re: Hi Exim users - problem with hybrid exchange domain
sending to exim. (Jasen Betts)
4. Certificate validation failed (Dominik Vogt)
5. Re: Certificate validation failed (Dominik Vogt)
6. Re: Certificate validation failed (Viktor Dukhovni)
7. Re: Certificate validation failed (Andreas Metzler)
8. Re: Certificate validation failed (Viktor Dukhovni)
9. Re: Certificate validation failed (Evgeniy Berdnikov)
10. Re: Certificate validation failed (Viktor Dukhovni)
11. Re: Certificate validation failed (Slavko)
12. Re: Certificate validation failed (Slavko)
13. Re: Certificate validation failed (Jeremy Harris)
14. Re: Certificate validation failed (Dominik Vogt)
15. Re: Certificate validation failed (Viktor Dukhovni)
16. Re: Certificate validation failed (Viktor Dukhovni)
17. Re: Certificate validation failed (Jeremy Harris)
----------------------------------------------------------------------
Message: 1
Date: Fri, 29 Oct 2021 15:14:44 -0400
From: "John Stegenga" <john@???>
To: <exim-users@???>
Subject: [exim] Hi Exim users - problem with hybrid exchange domain
sending to exim.
Message-ID: <08e201d7ccf9$3bb17e90$b3147bb0$@???>
Content-Type: text/plain; charset="us-ascii"
My Exim installation is standard, installed on Centos via WHM.
Most settings are default.
One of my hosted customers reported that one of HIS customers cannot send email to his domain.
We've looked at all kinds of settings, the customers SPF record is ok, but we don't know how to set
up a PTR for him because:
1- His outbound email comes through O365/exchange online,
2- His inbound email goes through ironport devices to an on-premise exchange server.
Has anyone dealt with this before?
I added his domain to the whitelist, to no effect.
Your advice and expertise is quite welcome!
John
------------------------------
Message: 2
Date: Fri, 29 Oct 2021 21:59:54 +0100
From: Jeremy Harris <jgh@???>
To: exim-users@???
Subject: Re: [exim] Hi Exim users - problem with hybrid exchange
domain sending to exim.
Message-ID: <7bae5548-ff0c-57db-53b4-c018520506f3@???>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 29/10/2021 20:14, John Stegenga via Exim-users wrote:
> Your advice and expertise is quite welcome!
Your relevant log entries?
His relevant log entries?
You've given no useful information.
--
Cheers,
Jeremy
------------------------------
Message: 3
Date: Fri, 29 Oct 2021 22:26:34 -0000 (UTC)
From: Jasen Betts <usenet@???>
To: exim-users@???
Subject: Re: [exim] Hi Exim users - problem with hybrid exchange
domain sending to exim.
Message-ID: <slhseq$bgn$1@???>
On 2021-10-29, John Stegenga via Exim-users <exim-users@???> wrote:
> My Exim installation is standard, installed on Centos via WHM.
>
>
>
> Most settings are default.
>
>
>
> One of my hosted customers reported that one of HIS customers cannot send email to his domain.
>
> We've looked at all kinds of settings, the customers SPF record is ok, but we don't know how to
set
> up a PTR for him because:
>
> 1- His outbound email comes through O365/exchange online,
>
> 2- His inbound email goes through ironport devices to an on-premise exchange server.
>
>
>
> Has anyone dealt with this before?
>
> I added his domain to the whitelist, to no effect.
It's not clear what exim is objecting to. or what change you made where.
Make sure that his domain does not have a broken dnssec configuration.
Perhaps try adding office 365's servers to the whitelist, you should
be able to pull their addresses from the SPF
--
Jasen.
------------------------------
Message: 4
Date: Sat, 30 Oct 2021 00:01:39 +0100
From: Dominik Vogt <dominik.vogt@???>
To: exim-users@???
Subject: [exim] Certificate validation failed
Message-ID: <YXx9U5KpovHxQoyM@???>
Content-Type: text/plain; charset=us-ascii
Since the Devuan 3 to 4 upgrade, my Exim 4.94.2 installation has a
problem with TLS certificates.
The local exit 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 exit does not use TLS
for server B and generates this log message:
... TLS session: (certificate verification failed): certificate
invalid: delivering unencrypted to H=<server-b> [<ip-address>]
(not in hosts_require_tls)
How can this be fixed or at least debugged?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
------------------------------
Message: 5
Date: Sat, 30 Oct 2021 00:07:30 +0100
From: Dominik Vogt <dominik.vogt@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <YXx+sg568UxwZiYm@???>
Content-Type: text/plain; charset=us-ascii
On Sat, Oct 30, 2021 at 12:01:39AM +0100, Dominik Vogt wrote:
> Since the Devuan 3 to 4 upgrade, my Exim 4.94.2 installation has a
> problem with TLS certificates.
>
> The local exit 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 exit does not use TLS
> for server B and generates this log message:
>
> ... TLS session: (certificate verification failed): certificate
> invalid: delivering unencrypted to H=<server-b> [<ip-address>]
> (not in hosts_require_tls)
>
> How can this be fixed or at least debugged?
P.S.: The server uses a self signed certificate. How can I tell
exit to accept this specific certificate?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
------------------------------
Message: 6
Date: Fri, 29 Oct 2021 19:35:54 -0400
From: Viktor Dukhovni <exim-users@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <YXyFWvQdLvDzt+XH@???>
Content-Type: text/plain; charset=us-ascii
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=<server-b> [<ip-address>]
> (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.
------------------------------
Message: 7
Date: Sat, 30 Oct 2021 08:07:02 +0200
From: Andreas Metzler <eximusers@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <YXzhBoK6sbHYzy2N@???>
Content-Type: text/plain; charset=us-ascii
On 2021-10-30 Viktor Dukhovni via Exim-users <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???
Good morning,
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.)
[...]
@original submitter:
* Use a certiticate that verifyable without client-side changes., e.g. setup
DANE on the server and/or use e.g. a letsencrypt cert.
* Give client-side exim a way to verify the cert by adding the cert to
the trusted list.
* Modify the tls_verify_hosts setting.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
------------------------------
Message: 8
Date: Sat, 30 Oct 2021 02:56:40 -0400
From: Viktor Dukhovni <exim-users@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <YXzsqL5M8+LyuS1b@???>
Content-Type: text/plain; charset=utf-8
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.
------------------------------
Message: 9
Date: Sat, 30 Oct 2021 10:46:24 +0300
From: Evgeniy Berdnikov <bd4@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <YXz4UEhvX40YCm7X@???>
Content-Type: text/plain; charset=us-ascii
On Sat, Oct 30, 2021 at 02:56:40AM -0400, Viktor Dukhovni via Exim-users wrote:
> 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. [...]
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).
--
Eugene Berdnikov
------------------------------
Message: 10
Date: Sat, 30 Oct 2021 05:13:05 -0400
From: Viktor Dukhovni <exim-users@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <YX0Moe0hemKafItJ@???>
Content-Type: text/plain; charset=us-ascii
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.
------------------------------
Message: 11
Date: Sat, 30 Oct 2021 11:29:26 +0200
From: Slavko <linux@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <20211030112926.37b793c1@???>
Content-Type: text/plain; charset="utf-8"
Hi,
D?a Sat, 30 Oct 2021 00:01:39 +0100 Dominik Vogt via Exim-users
<exim-users@???> nap?sal:
> How can this be fixed or at least debugged?
As you pointed elsewhere, you are using self signed certificate.
Self signed certificates are OK with one exception, they can be
validated only by self (as name suggests). But it cert can be used as
CA cert too, and will be able to verify only self.
While will i do not suggest this (as this becomes difficult task to
manage that on multiple hosts) you still can add this self signed
cert into your system's CA bundle and use it to verify it.
regards
--
Slavko
https://www.slavino.sk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digit??lny podpis OpenPGP
URL: <
https://lists.exim.org/lurker/list/exim-users/attachments/20211030/36cd9a63/attachment.sig>
------------------------------
Message: 12
Date: Sat, 30 Oct 2021 11:58:56 +0200
From: Slavko <linux@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <20211030115856.1a192a42@???>
Content-Type: text/plain; charset="utf-8"
Hi,
D?a Sat, 30 Oct 2021 02:56:40 -0400 Viktor Dukhovni via Exim-users
<exim-users@???> nap?sal:
> Thus:
>
> smtp_tls_security_level = none | may | encrypt | fingerprint |
> dane | secure
I think, that ideal MTA must have option:
guess_tls_verify = no | user | admin
in "admin" mode, it will reject to connect over not validated cert for
trusted hosts and in "user" mode it will accept TLS for not bad hosts.
That "guess" part points to deciding what hosts are trusted and/or
which are bad.
It will use AI for deciding this guess, in simple case eg. by random
number qualificator, initiated e.g. by IP value to increase entropy. Or
we can define new SMTP extension and MTA will reports its
goodness/badness in EHLO reply as longlongint value, based eg. on
government certification (which delegates it eg. to google or
microsoft).
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.
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.
regards
--
Slavko
https://www.slavino.sk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digit??lny podpis OpenPGP
URL: <
https://lists.exim.org/lurker/list/exim-users/attachments/20211030/ba843c48/attachment.sig>
------------------------------
Message: 13
Date: Sat, 30 Oct 2021 11:16:23 +0100
From: Jeremy Harris <jgh@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <96eb6732-ef2f-8da9-9a30-caeffcdd5382@???>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 30/10/2021 00:01, Dominik Vogt via Exim-users wrote:
> Since the Devuan 3 to 4 upgrade, my Exim 4.94.2 installation has a
> problem with TLS certificates.
>
> The local exit 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 exit does not use TLS
> for server B and generates this log message:
>
> ... TLS session: (certificate verification failed): certificate
> invalid: delivering unencrypted to H=<server-b> [<ip-address>]
> (not in hosts_require_tls)
>
> How can this be fixed or at least debugged?
Don't set tls_verify_hosts in the transport.
The defaults for it and tls_try_verify_hosts do what you
probably want.
--
Cheers,
Jeremy
------------------------------
Message: 14
Date: Sat, 30 Oct 2021 11:56:21 +0100
From: Dominik Vogt <dominik.vogt@???>
To: exim-users@???
Cc: Andreas Metzler <eximusers@???>
Subject: Re: [exim] Certificate validation failed
Message-ID: <YX0k1RqTmxSAuUQi@???>
Content-Type: text/plain; charset=us-ascii
On Sat, Oct 30, 2021 at 08:07:02AM +0200, Andreas Metzler via Exim-users wrote:
>
> If a host is in tls_verify_hosts and hosts_try_tls but not in
> hosts_require_tls exim will fall back to cleartext.
The Debian-11/Devuan-4 defaults for "SMARTHOST for outgoing main,
fetchmail for incoming mail" are what caused this:
.ifdef MAIN_TLS_VERIFY_HOSTS
tls_verify_hosts = MAIN_TLS_VERIFY_HOSTS
.endif
.ifdef MAIN_TLS_TRY_VERIFY_HOSTS
tls_try_verify_hosts = MAIN_TLS_TRY_VERIFY_HOSTS
.endif
.ifndef REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS
REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = *
.endif
.ifdef REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS
hosts_require_tls = REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS
.endif
No idea to what values of the upper case variables are in the
first place. Are they defined at compile time; is there a way to
look them up, other than from the Debian src package?
> @original submitter:
> * 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.
> * Give client-side exim a way to verify the cert by adding the cert to
> the trusted list.
Thanks. That works.
> * Modify the tls_verify_hosts setting.
There's no such setting in /var/lib/exim4/config.autogenerated.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
------------------------------
Message: 15
Date: Sat, 30 Oct 2021 07:11:18 -0400
From: Viktor Dukhovni <exim-users@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <YX0oVpgXOHpXpikZ@???>
Content-Type: text/plain; charset=us-ascii
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.
------------------------------
Message: 16
Date: Sat, 30 Oct 2021 07:19:52 -0400
From: Viktor Dukhovni <exim-users@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <YX0qWJWJzEySp95t@???>
Content-Type: text/plain; charset=us-ascii
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.
------------------------------
Message: 17
Date: Sat, 30 Oct 2021 12:37:50 +0100
From: Jeremy Harris <jgh@???>
To: exim-users@???
Subject: Re: [exim] Certificate validation failed
Message-ID: <80ea26a6-f0ca-bf94-9dbd-1c051b676671@???>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 30/10/2021 11:56, Dominik Vogt via Exim-users wrote:
> No idea to what values of the upper case variables are in the
> first place. Are they defined at compile time; is there a way to
> look them up, other than from the Debian src package?
They are macros, not variables. They will be defined somewhere
else in the configuration, before the places they are used.
"exim -bP macro <name-of-macro>" can be used to look one up.
--
Cheers,
Jeremy
------------------------------
Subject: Digest Footer
--
## List details at
https://lists.exim.org/mailman/listinfo/exim-users Exim details at
http://www.exim.org/ ##
------------------------------
End of Exim-users Digest, Vol 209, Issue 29
*******************************************
