[exim] Re: Exim attempting retries in rapid succession without delay?

On Thu, Oct 10, 2024 at 10:45:08PM +0100, Andrew C Aitchison via Exim-users wrote: > > > I posted this problem as an exim bug, but it was immediately dismissed > > because the MTA rejection response indicates a temporary problem, so > > apparently retrying 4 more times inside a second to differe

[exim] Re: DANE with certificate errors

On Thu, Sep 12, 2024 at 03:32:36PM +0200, Kai Bojens via Exim-users wrote: > I have a very simple question: why would Exim notify about Certificate > errors in regard to DANE/TLS but continue to send the mails anyway? And how > do I stop this behaviour? > > DANE attempt failed; TLS connection to

[exim] Re: autoreply and DKIM signature ?

On Thu, Aug 15, 2024 at 08:26:06AM +0100, Julian Bradfield via Exim-users wrote: > > No. Alignment, etc., is DMARC not DKIM. Absent a DMARC policy for > > the "From:" domain, any the DKIM signature allows the receiving system > > to use the "d=" value as a key into a reputation system, but quest

[exim] Re: autoreply and DKIM signature ?

On Thu, Aug 15, 2024 at 08:36:19AM +0200, Cyborg via Exim-users wrote: > > Because of the <> envelope-from, how can the proper sender-domain > > (and dkim key) be found on the sending host ? > > To answere your original question:  you don't do this. > > You send the auto-reply with the correct m

[exim] Re: autoreply and DKIM signature ?

On Wed, Aug 14, 2024 at 08:25:30PM +0100, Julian Bradfield via Exim-users wrote: > > I do not agree. > > The DKIM RFC says that anyone can sign a message. > > Yes, but it also says very clearly that it's up to the Identity > Assessor to decide what, if any, trust to place in a message signed by >

[exim] Re: sender verification details

On Fri, Aug 09, 2024 at 03:52:05PM +0200, Slavko via Exim-users wrote: > Ahoj, > > Dňa Fri, 9 Aug 2024 15:16:17 +0200 Jan Ingvoldstad via Exim-users > napísal: > > > Please remember that in the absence of MX records, A record lookup(s) > > will be performed for email delivery. > > more precise,

[exim] Re: sender verification details

On Wed, Aug 07, 2024 at 09:12:57AM +0100, Jeremy Harris via Exim-users wrote: > On 06/08/2024 21:16, Ian Z via Exim-users wrote: > > Does non-callout sender verification of nonlocal addresses, in the case of > > a dnslookup router, determine the MX host of the sender domain? > > No (and there coul

[exim] Re: sender verification details

On Wed, Aug 07, 2024 at 10:23:38AM +0300, Evgeniy Berdnikov via Exim-users wrote: > On Tue, Aug 06, 2024 at 01:16:29PM -0700, Ian Z via Exim-users wrote: > > Does non-callout sender verification of nonlocal addresses, in the case of > > a dnslookup router, determine the MX host of the sender domai

[exim] Re: exim don't speak to google any more!

On Tue, Jul 30, 2024 at 01:17:00PM +0100, Jeremy Harris via Exim-users wrote: > On 30/07/2024 12:52, Andrew C Aitchison via Exim-users wrote: > > *If* I extended the config to allow admins to set the OpenSSL option > > SSL_OP_IGNORE_UNEXPECTED_EOF (and an equivalent gnutls option if I can > > find 

[exim] Re: exim don't speak to google any more!

On Mon, Jul 29, 2024 at 09:44:17AM +0100, Bernard Quatermass via Exim-users wrote: > > Exim really should be updated to ignore OpenSSL's truncation > > detection, I don't recall whether that even already happened and the > > OP is running an older version? > > I rather think postfix is the codeb

[exim] Re: exim don't speak to google any more!

On Mon, Jul 29, 2024 at 09:25:21AM +0200, Francois Sauterey via Exim-users wrote: > The response was : > > TLS Negotiation failed: FAILED_PRECONDITION: starttls error (71): > 54099363978240:error:1410:SSL > routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:third_party/openssl/boringss

[exim] Re: exim don't speak to google any more!

On Mon, Jul 29, 2024 at 03:24:35AM +, Thomas Krichel via Exim-users wrote: > > Exim really should be updated to ignore OpenSSL's truncation detection, > > I don't recall whether that even already happened and the OP is running > > an older version? > > root@tagol~# exim --version | head -1 >

[exim] Re: exim don't speak to google any more!

On Sun, Jul 28, 2024 at 05:56:33PM +0100, Jeremy Harris via Exim-users wrote: > > BUT in the log, I get the following message: > > > >  H=gmail-smtp-in.l.google.com [142.251.16.26] TLS error on > > connection (recv): The TLS connection was non-properly terminated. > > Google is violating stan

[exim] DANE TLSA records for exim.org?

Until roughly today, at least the primary MX host for "exim.org" had DANE TLSA records. Today, they're gone (I hope temporarily). And ideally (subject to real world constraints, and all that), it would even be could for the secondary MX to be signed and have TLSA RRs. ; NOERROR AD=1 exim

[exim] Re: GnuTLS and Dane-Problem finally solved

On Sat, Jul 13, 2024 at 09:46:25PM +0200, Wolfgang via Exim-users wrote: > and all others helping me, to find the problem with my exim not able to > deliver to the > https://blog.lindenberg.one/EmailSecurityTest . It sure looks to my expert eyelike you've still failed to identify the reason for

[exim] Re: Follow-Up: Debug TLS/DANE problems it is GnuTLS!

On Mon, Jul 08, 2024 at 03:22:50PM +, Slavko via Exim-users wrote: > >I checked into that already also. First I used my own nameserver, where the > >output just looks as > >yours. > > dig +noall +stats +comment -t mx et.lindenberg.one | grep -E '^;; > > (flags|SERVER):' > > ;; flags: qr rd

[exim] Re: no SNI used, when sending TLS secured messages out

On Mon, Jul 08, 2024 at 03:20:40PM +0200, Wolfgang via Exim-users wrote: > Hello, > Why is exim not using SNI for every TLS connection, which got established? > SNI is helpful even far > away from DANE for message routing, multiplexing MX and other stuff. Historically, there wasn't a well-defin

[exim] Re: Follow-Up: Debug TLS/DANE problems it is GnuTLS!

On Mon, Jul 08, 2024 at 03:02:35PM +0200, Wolfgang via Exim-users wrote: > >Perhaps the issue is as mundane as you not having a local validating > >resolver in /etc/resolv.conf, so that the destination domain looks > >unsigned to Exim? Can you post the output of: > > >$ dig +noall +stats +com

[exim] Re: Debug TLS/DANE problems

On Sun, Jul 07, 2024 at 06:34:21PM +0200, Wolfgang via Exim-users wrote: > > > Actual debug output from the Exim system. I pointed out how best > > to do that on the 2nd (assuming that the Exim system is the > > accepting end for the connection). > > > [ In case it's an outbound connection at

[exim] Re: Follow-Up: Debug TLS/DANE problems it is GnuTLS!

On Sun, Jul 07, 2024 at 03:59:30PM +0100, Jeremy Harris via Exim-users wrote: > On 07/07/2024 14:31, Viktor Dukhovni via Exim-users wrote: > > So is sure seems like Exim DANE with GnuTLS fails to set the TLSA base > > domain as the SNI name, while the Exim with OpenSSL does take c

[exim] Re: Follow-Up: Debug TLS/DANE problems it is GnuTLS!

On Sun, Jul 07, 2024 at 09:36:48AM +0100, Jeremy Harris via Exim-users wrote: > Basics such as who the actors are in the connection, with which roles > (that last item because of the confusion in the message I > responded to yesterday). The connection is to "mx06.et.lindenberg.one" on port 25. W

[exim] Re: Follow-Up: Debug TLS/DANE problems it is GnuTLS!

On Sat, Jul 06, 2024 at 09:44:58PM +0100, Jeremy Harris via Exim-users wrote: > Actually, you don't know whether the option was forced. Only the result on > the > connection - which you have not described how you evaluated. A "tshark" analysis of the connection should be able to reveal all, sin

[exim] Re: Follow-Up: Debug TLS/DANE problems / GnuTLS?

On Fri, Jul 05, 2024 at 02:01:38PM +0200, Wolfgang via Exim-users wrote: > I am much more familar with openssl, but debian-exim is linked against > gnu-tls, so I started digging in gnttls binary tools also. > Unfortunately gnutls-cli is far less capable, that the openssl cli > tools. I started t

[exim] Re: Problems with outgoing DANE-TLSA, when CA-anchored test fails

On Tue, Jul 02, 2024 at 03:51:38PM +0200, Wolfgang via Exim-users wrote: > > Otherwise, any MX host with a Let's Encrypt certificate could > > impersonate any other such host. > > I don't get this: Even, when either the CN nor an additional SAN matches, I > see no risk > for impersonating, as th

[exim] Re: Problems with outgoing DANE-TLSA, when CA-anchored test fails

On Sun, Jun 30, 2024 at 11:32:58PM +0200, Wolfgang via Exim-users wrote: > I have problems connecting DANE configured hosts, when the MX has a > correct TLSA-RR but an valid certificate (letsencrypt) with the wrong > CN. This is required and expected behaviour. See: https://datatracker.ietf.

[exim] More changes (2024-06-06) at Let's Encrypt affecing DANE-TA(2) TLSA records

On Fri, Dec 08, 2023 at 02:01:30PM -0500, Viktor Dukhovni wrote: > It now turns out that they will also be switching to new underlying > intermediate CAs. So you'll a random choice of *new* issuers. > > > https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/L7XoAXt_s1c/m/k_vdk9rQ

[exim] Re: SSL Certificates

On Wed, Mar 20, 2024 at 06:17:48AM +0100, Niels Kobschätzki via Exim-users wrote: > Use https://whatsmychaincert.com/, put in your certificate and get a file > with a correct full chain with or without root back. This is prone to accidental pasting of one's private keys into the webform. A sa

[exim] Re: SSL Certificates

On Tue, Mar 19, 2024 at 09:45:37PM -0700, Ian Z via Exim-users wrote: > On Tue, Mar 19, 2024 at 11:40:05PM -0400, Jerry Stuckle via Exim-users wrote: > > > I got a free SSL certificate but am having problems implementing it. > > It came as certificate.crt and private.key. It also contained > > ca

[exim] Re: restricted characters in address

On Sun, Mar 10, 2024 at 07:53:40PM +, Julian Bradfield via Exim-users wrote: > Of course, there is still the question as to why any form of source > routing should be enabled in a default configuration of anything, > given its almost total obsoleteness. > (I could imagine source routing being

[exim] Re: restricted characters in address

On Sun, Mar 10, 2024 at 09:49:14AM +, Julian Bradfield via Exim-users wrote: > That would be a configuration problem for that site - not a reason to > stop your users replying to perfectly valid addresses. > > > And by the way, by default Postfix still supports % and ! addresses: > > > >

[exim] Re: restricted characters in address

On Sat, Mar 09, 2024 at 09:26:39PM +, Julian Bradfield via Exim-users wrote: > Secondly, is there really any reason nowadays for restricting % and ! ? > > The last time I saw a % address was in 1995, and the last time I saw a > ! address was in 1994. (And of course, when I did see them, they

[exim] DANE: ATTENTION: Let's Encrypt drops DST X3 from default chain, breaking "depth 2" ISRG "2 1 1" TLSA records...

As of roughly the start of this month, the DANE survey at is seeing a steady stream of validation failures for MX hosts that rely only on: _25._tcp.mail.domain.example. IN TLSA 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 [ Some also

[exim] Re: undefined reference to `SSL_get0_chain_certs' error on compile

On Sat, Dec 16, 2023 at 09:44:59AM +, Ian B via Exim-users wrote: > In the meantime I think I've just got it working ok with exporting > LD_LIBRARY_PATH and CC=gcc -std=gnu99 -lrt -I/usr/local/ssl/ > -L/usr/local/ssl/lib -Wl,-rpath,/usr/local/ssl/lib (not even sure those are > correct just atm

[exim] Re: undefined reference to `SSL_get0_chain_certs' error on compile

On Fri, Dec 15, 2023 at 12:26:53PM +, Ian B via Exim-users wrote: > Just wanted to say thanks, I got this all working after the full install. > > (I've compiled a later release of openssl into /usr/local/ssl and created > /etc/ld.so.conf.d/openssl.conf with the lib in there, followed by ldconf

[exim] TAKE NOTE 3: Upcoming new Let's Encrypt intemediate issuer CAs.

My previous post on this topic noted that covered Let's Encrypt are planning to *randomise* the choice of intermediate issuer CA used with each renewal. It now turns out that they will also be switching to new underlying intermediate CAs. So you'll a random choice of *new* issuers. https:/

[exim] Re: Exim hates CNAMEs, not IPv6

On Fri, Dec 01, 2023 at 12:09:44AM -0500, John R Levine via Exim-users wrote: > Oh, I see the problem. lists.exim.org is a CNAME for cumin.exim.org, > and qmail is standard compliant per RFC 1123: > > 5.2.2 Canonicalization: RFC-821 Section 3.1 > > The domain names that a Sender-

[exim] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.

On Sun, Nov 19, 2023 at 09:33:37PM +, Slavko via Exim-users wrote: > > * Staging a future key, that the ACME client will conditionally > >switch to, once the TLSA record is live. > > Do you mean opposite of usual certbot logic: first generate key, then > setup TLSA for it, and after that

[exim] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.

On Sun, Nov 19, 2023 at 01:30:29PM +0100, Slavko via Exim-users wrote: > > I don't recommend DANE-TA(2), and encourage use of DANE-EE(3) instead. > > I am far from DANE expert, but my understanding is, that DANE-TA is > good for own CAs, where one have full control on (intermediate) CA's > certs

[exim] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.

On Thu, Nov 16, 2023 at 07:41:46PM +, Slavko via Exim-users wrote: > >If you're using Let's Encrypt as your CA and prefer to publish > >DANE-TA(2), rather than DANE-EE(3) TLSA records, please look over: > > Just curious. Enough recent certbot provides --reuse-key and --new-key > (or so) optio

[exim] Re: dnsdb loses characters (exim 4.96.2, 4.97)

On Wed, Nov 15, 2023 at 07:00:20PM +, Andrew C Aitchison via Exim-users wrote: > On Wed, 15 Nov 2023, Victor Ustugov via Exim-users wrote: > > > Hello > > > > This is a real case. > > > > Let's resolve the TXT record of the perrigo.com domain. > > > > # pkg info -E exim > > exim-4.96.2 > >

[exim] TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.

On Wed, Nov 15, 2023 at 12:17:50AM -0500, Viktor Dukhovni wrote: > It must be that Let's Encrypt finally stopped by default including that > cross certificate in their chains. As pointed out helpfully by Geert Hendrickx on the postfix-users list: > They plan to stop providing the cross-signed "l

[exim] TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

The DANE/DNSSEC survey () has seen a recent spike in the number of MX hosts whose "2 1 1" TLSA records no longer match their certificate chain. The records in question all shar the same digest value, for various TLSA base domains: _25._tcp.mx1.example. IN TLSA

[exim] Re: Fixing or disabling TLS for internal network hosts

On Sat, Oct 07, 2023 at 09:53:25PM -0700, AC via Exim-users wrote: > As for misunderstanding the error, perhaps it could be modified to better > explain which side is causing the message since I obviously assumed that a > message in the server logs indicated the server had a problem absent any > o

[exim] Re: Fixing or disabling TLS for internal network hosts

On Sat, Oct 07, 2023 at 08:52:24PM -0700, AC via Exim-users wrote: > The error message on the main server is: > TLS error on connection from [host] (recv): A TLS fatal alert has been > received.: Certificate is bad You've misunderstood the message. TLS "alerts" are errors reported to the local T

[exim] Re: Is sender verification possible on a server that is used as a smarthost?

On Wed, Oct 04, 2023 at 09:36:12PM +0200, Mario Emmenlauer wrote: > > Rather than leak user@.domain forms out to the public > > Internet, explain and solve the real problem that not masquerading > > all users behind the primary domain is supposed to solve??? > > So for me, the exim email system o

[exim] Re: Is sender verification possible on a server that is used as a smarthost?

On Wed, Oct 04, 2023 at 12:49:29PM -0400, Chris Siebenmann via Exim-users wrote: > > But does that mean that in turn, each of these subdomains would need > > to be added as a local domain in exim on mydomain.org? Are there any > > downsides with that? It seems a bit wrong that mydomain.org has loc

[exim] Re: Is sender verification possible on a server that is used as a smarthost?

On Wed, Oct 04, 2023 at 02:11:27PM +0200, Mario Emmenlauer via Exim-users wrote: > Also, I'd like to have unique mailnames for each desktop, like > .mydomain.org, to better identify where the mail originated > from. But these domains do not really exist, they would be "fake" > mailnames to identif

[exim] Re: Exim Zero Day?

On Sun, Oct 01, 2023 at 05:50:00PM +0200, Andreas Barth via Exim-users wrote: > I have seen the security side as debian release manager for quite many > software products. And I doubt much that postfix would do it much > different. Coordinated release of security updates is standard industry prac

[exim] Re: RFC822 Date format.

On Mon, Sep 25, 2023 at 03:21:20AM -, Jasen Betts via Exim-users wrote: > On 2023-09-25, Jasen Betts via Exim-users wrote: > > I want to add a Resent-Date: header. Is there any way to access this > > RFC822 timestamp using simple string expansion? > > so far this is my best candidate: > >

[exim] Re: TLS error on connection (recv): The TLS connection was non-properly terminated.

On Wed, Sep 13, 2023 at 04:43:46PM +0100, Jeremy Harris via Exim-users wrote: > On 13/09/2023 16:31, Viktor Dukhovni via Exim-users wrote: > > So long as the delivery completed, > > That's not relevant here. It does... eventually. FWIW, I meant the *specific* delive

[exim] Re: TLS error on connection (recv): The TLS connection was non-properly terminated.

On Wed, Sep 13, 2023 at 09:33:36AM +0100, Jeremy Harris via Exim-users wrote: > "non-properly terminated" means the far end didn't do a proper TLS close > sequence. It's unfortunately common. However, combined with the 30s stall, > worth checking on. Get a delivery run with debug; look for the

[exim] Re: OpenSSL 3 under FreeBSD

On Tue, Sep 12, 2023 at 08:16:12AM +0300, Lena--- via Exim-users wrote: > FreeBSD port of openssl 1.1.1 had an update yesterday, it says: > > Final version of OpenSSL 1.1.1, this port will upgrade to > 3.0 (LTS) with a next commit. > > Does somebody use Exim with openssl 3 under FreeBSD already?

[exim] Re: Please avoid TLSA records matching retired issuing CAs.

On Mon, Jul 17, 2023 at 10:11:08AM +0200, Niels Dettenbach via Exim-users wrote: > helpful for pro-actively watching / monitoring different aspects of a > DANE / TLSA setup per Nagios (as "compatible" monitoring systems): > https://github.com/matteocorti/check_ssl_cert > > which is very flexible

[exim] Please avoid TLSA records matching retired issuing CAs.

[ Also posted to dane-us...@list.sys4.de ] There are still ~250 MX hosts with DANE TLSA records that match the retired X3 or X4 Let's Encrypt CAs. Perhaps also other retired CAs, but these are the ones I'm tracking at: https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html Please take care t

[exim] Re: exim spitting out "bad certificate" log lines

On Thu, Jul 13, 2023 at 10:30:06PM +0300, Evgeniy Berdnikov via Exim-users wrote: > On Thu, Jul 13, 2023 at 11:11:31AM -0400, Viktor Dukhovni via Exim-users > wrote: > > Perhaps the OpenSSL library could change the message to be: > > > > "TLS fatal alert from

[exim] Re: exim spitting out "bad certificate" log lines

On Thu, Jul 13, 2023 at 04:43:42PM +0200, Cyborg via Exim-users wrote: > >> "TLS error (SSL_read): error:0A000412:SSL routines::sslv3 alert bad > >> certificate" > > This is the correct log message. > > If the chain of events is like we expect it to be, that the client tries > to validate the ce

[exim] Re: exim spitting out "bad certificate" log lines

On Thu, Jul 13, 2023 at 04:50:44PM +0200, Cyborg via Exim-users wrote: > > If the issue is observed on the MX host for your domain, note that its > > certificate chains up to the already expired "DST Root CA X3": > > where do you see an expired cert here?  Or did you mean "soon to be > reaching

[exim] Re: exim spitting out "bad certificate" log lines

On Thu, Jul 13, 2023 at 10:21:02AM +0200, Cyborg via Exim-users wrote: > 2023-07-13 08:15:41 TLS error (SSL_read): error:0A000412:SSL > routines::sslv3 alert bad certificate If the issue is observed on the MX host for your domain, note that its certificate chains up to the already expired "DST R

[exim] Re: exim spitting out "bad certificate" log lines

On Thu, Jul 13, 2023 at 10:21:02AM +0200, Cyborg via Exim-users wrote: > Since 08:15 CEST Exim is spitting out these errors: > > 2023-07-13 08:15:41 TLS error (SSL_read): error:0A000412:SSL > > routines::sslv3 alert bad certificate This is reported by OpenSSL to the local application (Exim serv

[exim] Re: fake helo at connect

On Mon, Jun 19, 2023 at 02:02:49PM +0300, Myhaylo Golub via Exim-users wrote: > Some host provides fake information after connect. > > telnet mail.hostname. 25 > Trying *.*.*.*... > Connected to mail.hostname. > Escape character is '^]'. > 220-mx.mail.hostname ESMTP Postfix > 220 mx.mail.hostname

Re: [exim] Routing failed deliveries through an ESP

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 rec

Re: [exim] Something like "domains_require_tls"

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 differen

Re: [exim] Something like "domains_require_tls"

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,

Re: [exim] Exim, OAUTH2 and gnutls problem

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

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

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_certifi

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

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 lat

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

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

Re: [exim] suspected mail loop - Not

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 r

Re: [exim] TLS authentication

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

Re: [exim] TLS authentication

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 serv

Re: [exim] TLS authentication

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

Re: [exim] TLS authentication

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 >

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

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 break

Re: [exim] got this garbage from HP

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 con

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

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

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

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 1

Re: [exim] debugging tls handshake failure

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 > >re

Re: [exim] debugging tls handshake failure

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

Re: [exim] debugging tls handshake failure

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 th

Re: [exim] OpenSSL IOT woes

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_

Re: [exim] OpenSSL IOT woes

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 OpenSS

Re: [exim] OpenSSL IOT woes

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 Fat

Re: [exim] OpenSSL IOT woes

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 > ca

Re: [exim] OpenSSL IOT woes

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 &

Re: [exim] GnuTTS woes

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

Re: [exim] GnuTTS woes

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 -startt

Re: [exim] GnuTTS woes

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 lo

Re: [exim] GnuTTS woes

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 co

Re: [exim] GnuTTS woes

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.

Re: [exim] GnuTTS woes

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 m

Re: [exim] GnuTTS woes

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

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

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".

Re: [exim] GnuTTS woes

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 fo

Re: [exim] GnuTTS woes

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 > d052828c650cc

Re: [exim] GnuTTS woes

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 > analysi

Re: [exim] GnuTTS woes

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

Re: [exim] GnuTTS woes

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 > > &

Re: [exim] GnuTTS woes

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

Re: [exim] GnuTTS woes

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 tes

Re: [exim] SSL_renegotiate:wrong ssl version

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:

  1   2   3   >