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....@exim.org] On Behalf Of exim-users-requ...@exim.org Sent: Saturday, October 30, 2021 8:00 AM To: exim-users@exim.org Subject: Exim-users Digest, Vol 209, Issue 29 Send Exim-users mailing list submissions to exim-users@exim.org 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-requ...@exim.org You can reach the person managing the list at exim-users-ow...@exim.org 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" <j...@stegenga.net> To: <exim-users@exim.org> Subject: [exim] Hi Exim users - problem with hybrid exchange domain sending to exim. Message-ID: <08e201d7ccf9$3bb17e90$b3147bb0$@stegenga.net> 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 <j...@wizmail.org> To: exim-users@exim.org Subject: Re: [exim] Hi Exim users - problem with hybrid exchange domain sending to exim. Message-ID: <7bae5548-ff0c-57db-53b4-c01852050...@wizmail.org> 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 <use...@revmaps.no-ip.org> To: exim-users@exim.org Subject: Re: [exim] Hi Exim users - problem with hybrid exchange domain sending to exim. Message-ID: <slhseq$bgn$1...@gonzo.revmaps.no-ip.org> On 2021-10-29, John Stegenga via Exim-users <exim-users@exim.org> 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.v...@gmx.de> To: exim-users@exim.org Subject: [exim] Certificate validation failed Message-ID: <yxx9u5kpovhxq...@gmx.de> 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.v...@gmx.de> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <yxx+sg568uxwz...@gmx.de> 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-us...@dukhovni.org> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <yxyfwvqdlvdzt...@straasha.imrryr.org> 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 <eximus...@bebt.de> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <yxzhbok6sbhyz...@argenau.bebt.de> Content-Type: text/plain; charset=us-ascii On 2021-10-30 Viktor Dukhovni via Exim-users <exim-users@exim.org> 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-us...@dukhovni.org> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <yxzsql5m8+lyu...@straasha.imrryr.org> 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 <b...@protva.ru> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <yxz4uehvx40yc...@sony.protva.ru> 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-us...@dukhovni.org> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <yx0moe0hemkaf...@straasha.imrryr.org> 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 <li...@slavino.sk> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <20211030112926.37b79...@bonifac.skk> 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@exim.org> 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 <li...@slavino.sk> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <20211030115856.1a192...@bonifac.skk> 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@exim.org> 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 <j...@wizmail.org> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <96eb6732-ef2f-8da9-9a30-caeffcdd5...@wizmail.org> 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.v...@gmx.de> To: exim-users@exim.org Cc: Andreas Metzler <eximus...@bebt.de> Subject: Re: [exim] Certificate validation failed Message-ID: <yx0k1rqtmxsau...@gmx.de> 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-us...@dukhovni.org> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <yx0ovpgxohpxp...@straasha.imrryr.org> 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-us...@dukhovni.org> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <yx0qwjwjzeysp...@straasha.imrryr.org> 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 <j...@wizmail.org> To: exim-users@exim.org Subject: Re: [exim] Certificate validation failed Message-ID: <80ea26a6-f0ca-bf94-9dbd-1c051b676...@wizmail.org> 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 ******************************************* -- ## 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/