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
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
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,
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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 Fata
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
>
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
&
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_c
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
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 l
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
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.
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
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 =
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".
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
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
>
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
>
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
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
> >
&g
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
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
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
>
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
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.
>
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
>
>
>
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
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
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 th
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 m
> 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
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
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
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.
> 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
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
> >
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
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
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
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
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
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
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
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
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:
>
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
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 ope
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:
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
>
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
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
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
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,
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 o
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 cert
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
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
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
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
[ 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
> 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
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
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
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
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
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
1 - 100 of 201 matches
Mail list logo
