Re: [exim] How to get ec cert used with DANE and ec+rsa certs

On Mon, Sep 07, 2020 at 06:14:37PM +0200, Axel Rau via Exim-users wrote: > testing my TLSA setup here > https://www.huque.com/bin/danecheck > fails always with the ec cert, while the rsa cert succeeds: Are you sure you're interpreting the results correctly? > DNS TLSA RRset: > qname:

Re: [exim] DANE ERROR: TLSA LOOKUP DEFER

On Fri, Aug 28, 2020 at 04:47:50PM +0800, daniel via Exim-users wrote: > I have an update of this problem. > > Today I found out the solution of this problem. > > The solution is to NOT using any google DNS server (8.8.8.8 8.8.4.4). > > I am not sure how these two things does not work to each

Re: [exim] Moving a queue from server to server

On Wed, Jul 15, 2020 at 12:03:09PM -0400, Phil Pennock via Exim-users wrote: > > As to how: just copy the files. And delete the old ones. Preferably > > having ensured the daemon on the old machine is not running. > > > > I'm not answering the "whether to"; that's policy. > > Be sure to

Re: [exim] MTA-STS and Server Name Indication (SNI) on mail servers

On Wed, Jun 17, 2020 at 08:47:08PM -0400, Felipe Gasper wrote: > > On Jun 17, 2020, at 8:17 PM, Viktor Dukhovni via Exim-users > > wrote: > > > > However, its use is recommended: > > > >https://tools.ietf.org/html/rfc8446#section-4.4.2.2 >

Re: [exim] MTA-STS and Server Name Indication (SNI) on mail servers

On Wed, Jun 17, 2020 at 07:51:18PM -0400, Felipe Gasper via Exim-users wrote: > > On Jun 17, 2020, at 6:22 PM, Phil Pennock via Exim-users > > wrote: > > > > because TLS1.3 mandates SNI. > > Phil, do you have a citation for this? I skimmed the RFC just now, and > the only mandatory details

Re: [exim] MTA-STS and Server Name Indication (SNI) on mail servers

On Wed, Jun 17, 2020 at 06:22:28PM -0400, Phil Pennock via Exim-users wrote: > I keep mentally thinking that we're setting this automatically when DANE > is in play but it looks like we never got around to that. Ah, I stopped > relying on fallible memory and filed a bug about it: >

Re: [exim] Upcoming Glibc changes and DANE support in Exim, Postfix, and perhaps other MTAs

On Thu, Apr 16, 2020 at 07:53:08PM +0100, Jeremy Harris via Exim-users wrote: > On 15/04/2020 18:46, Viktor Dukhovni via Exim-users wrote: > > I read this to mean that the new "trust-ad" option, if set, causes the > > Glibc stub resolver to set AD=1 in queries

[exim] Upcoming Glibc changes and DANE support in Exim, Postfix, and perhaps other MTAs

On Tue, Apr 14, 2020 at 05:59:51PM -0400, Viktor Dukhovni wrote: Apparently the Glibc 2.31 (released Feb 2020) stub resolver either always solicits or always censors the AD-bit from its configured forwarding nameservers: https://gnutoolchain-gerrit.osci.io/r/c/glibc/+/461/3/NEWS * The

Re: [exim] DANE ERROR: TLSA LOOKUP DEFER

On Tue, Mar 31, 2020 at 12:04:06PM +0100, Jeremy Harris via Exim-users wrote: > On 30/03/2020 07:50, daniel via Exim-users wrote: > > And is exim > > by default will try DANE on all hosts or not? Because i dont found  > > these two configs in the exim config currently. > >

Re: [exim] DANE ERROR: TLSA LOOKUP DEFER

On Mon, Mar 30, 2020 at 03:25:54PM +0800, daniel via Exim-users wrote: > Here is one example of the actual problem i have just recently tested on > the problem server without apply the option fix (source domain masked > for privacy reason): > > 2020-03-30 15:02:59 1jIoRn-0004MT-RH <=

Re: [exim] DANE ERROR: TLSA LOOKUP DEFER

On Wed, Mar 25, 2020 at 01:10:53PM -0400, Phil Pennock via Exim-users wrote: > On 2020-03-23 at 20:54 +0800, daniel via Exim-users wrote: > > We recently received many of our end users complains that they are having > > problem sending email to *.gov.hk with this exim error: > > DANE ERROR:

Re: [exim] DANE ERROR: TLSA LOOKUP DEFER

> On Mar 23, 2020, at 8:54 AM, daniel via Exim-users > wrote: > > We recently received many of our end users complains that they are having > problem sending email to *.gov.hk with this exim error: > DANE ERROR: TLSA LOOKUP DEFER > However we have contacted our government and their responds

Re: [exim] Delay on exim send increases with uptime

On Sun, Feb 02, 2020 at 08:50:03PM -0800, Ian Zimmerman via Exim-users wrote: > On 2020-02-02 23:00, Viktor Dukhovni wrote: > > > And is the OpenSSL library that "/usr/bin/openssl" is linked with, the > > same one as the one for Exim? > > I am quite sure it is, because I build exim myself. I

Re: [exim] Delay on exim send increases with uptime

On Sun, Feb 02, 2020 at 09:57:25AM -0800, Ian Zimmerman via Exim-users wrote: > On 2020-02-01 22:52, Viktor Dukhovni wrote: > > > Is your build configured to look in /etc/ssl for certificates? Likely > > not. > > > > $ openssl version -d > > OPENSSLDIR: "/etc/ssl" > > On my devuan

Re: [exim] Delay on exim send increases with uptime

On Sat, Feb 01, 2020 at 02:42:06PM -0500, Holden Rohrer via Exim-users wrote: > It turns out that Debian's openssl is kind of broken, and this is a known > issue > (https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/396818). This isn't it. It is rather outdated, against a command-line

Re: [exim] Smarthost + queue worker keep alive the connection

On Wed, Jan 22, 2020 at 01:21:08AM +0100, Maeldron T. via Exim-users wrote: > I’m not sending spam, hence the emails are personalized. Even more, they > are confidential. Unfortunately, the only thing that helped was turning off > the SSL on the internal (sending) server. I can’t keep it like

Re: [exim] Line length RFC issues

On Thu, Jan 16, 2020 at 10:56:08PM -0500, John C Klensin wrote: > However, 5321 also makes it very clear that SMTP-conformant > servers are not supposed to be tampering with message payloads > (everything that follows the DATA command up to the "." CRLF, > often called "content", but I'm trying

Re: [exim] Line length RFC issues

We'll have to disagree on this, because given non-conformant (with RFC5322 Section 2.1.1) input we're free to do whatever is reasonably pragmatic and yields a conformant message for delivery to the next hop. Perhaps not surprisingly, users preferred delivery over bounces. > On Jan 16, 2020, at

Re: [exim] Line length RFC issues

> On Jan 16, 2020, at 1:12 PM, Jeremy Harris via Exim-users > wrote: > >> Does anyone know of anything that Exim can do to modify the message as >> it is routed through > > Exim can't; it's a policy decision in what it regards it's job > as being. That covers things like not converting from

Re: [exim] TLSv1 not supported ?

On Fri, Dec 27, 2019 at 07:53:30PM +0100, David Saez Padros via Exim-users wrote: > a remote server which was able to send us mail using > P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256 , after upgrading to Exim 4.93 + > OpenSSL 1.1.1d is no longer able to send mail to us, logging this error: What OS

Re: [exim] protecting privileged users from SMTP-AUTH attacks

On Sun, Dec 01, 2019 at 01:48:29PM +, Jeremy Harris via Exim-users wrote: > On 29/11/2019 17:43, Cyborg via Exim-users wrote: > > which brings me to a quick question: has exim any build in support to > > protected privileged users like root from getting brute forced by this? > > Exim

Re: [exim] Exim 4.93 Received Header tls clause

On Mon, Nov 18, 2019 at 12:13:47PM +0100, Cyborg via Exim-users wrote: > BTW: I always missed exims default level of detailed loginformations > when i had to work with other mailservers ;) If there's something missing from Postfix logging, please feel free to drop me a note off-list. --

Re: [exim] Exim 4.93 Received Header tls clause

> On Nov 13, 2019, at 7:10 PM, Cyborg via Exim-users > wrote: > > It would be better to change the rfc and make it mandatory to log the > version and cipher used ;) There's no IETF RFC police. MTAs will log what their developers and administrators conspire to log. So there's no "mandatory",

Re: [exim] Exim 4.93 Received Header tls clause

> On Nov 13, 2019, at 6:01 PM, Wolfgang Breyha via Exim-users > wrote: > >> I agree that the new format is inadequate, especially for TLS 1.3. >> In Postfix I've kept, and even expanded the "comment" form of the >> TLS trace info. For example: > > Do you know of any proposed improvements to

Re: [exim] Exim 4.93 Received Header tls clause

On Wed, Nov 13, 2019 at 06:27:42PM +0100, Wolfgang Breyha via Exim-users wrote: > While testing 4.93-RCx I recognized that it uses a new default for Received: > headers including TLS information as RFC 8314 defines it using > by with esmtps tls TLS_AES_256_GCM_SHA384 > instead of > by with

Re: [exim] Problem with tls_certificate and multiple domains

> On Oct 16, 2019, at 3:41 PM, Evgeniy Berdnikov via Exim-users > wrote: > >> So, how do I configure exim so mail can still be accessed via tls and an >> account can be created without any complaints about certificates from Apple >> Mail? > > It sounds as problem is in your Mac Mail, because

Re: [exim] Problem with tls_certificate and multiple domains

On Thu, Oct 17, 2019 at 10:39:18AM +0200, Cyborg via Exim-users wrote: > EHLO mail.example.com > 250-mail.server.de Hello muedsl-82-207-210-124.citykom.de [82.207.210.124] > ... > STARTTLS > 220 TLS go ahead > > There is no way to figure out what to write in the 220 greeting, except > you have

Re: [exim] Problem with tls_certificate and multiple domains

On Wed, Oct 16, 2019 at 10:04:16PM +0200, Cyborg via Exim-users wrote: > Am 16.10.19 um 19:25 schrieb Nospam2k via Exim-users: > > > I want to use > > mail.hosteddomainone.com for the mail > > server names and not maindomain.com for > > the

Re: [exim] Define preferred encryption algorithms

On Mon, Oct 14, 2019 at 12:34:34PM +0200, jmedard--- via Exim-users wrote: > Sorry, i don't understand why you prefere blacklist to whitelist ! Because it does not preclude future ciphers, less prone to typos, and gets the cipher order roughly right. Basically, less prone to cargo-culted poor

Re: [exim] Define preferred encryption algorithms

On Sun, Oct 13, 2019 at 06:43:48PM +0100, Jeremy Harris via Exim-users wrote: > Poking around the openssl sources I find a "Changes" note: > the definition for "DEFAULT" > (SSL_DEFAULT_CIPHER_LIST) now is just "ALL:!aNULL:!eNULL", but > remains equivalent to >

Re: [exim] Define preferred encryption algorithms

On Sun, Oct 13, 2019 at 09:51:42AM -0700, Phillip Carroll via Exim-users wrote: > This thread has given me a much deeper understanding of how to manage > cipher negotiation in exim. As a result of this thread I have adopted > Viktor's setting for tls_require_ciphers. (Thanks Viktor) One thing

Re: [exim] Define preferred encryption algorithms

On Sun, Oct 13, 2019 at 09:51:42AM -0700, Phillip Carroll via Exim-users wrote: > Following is the cipher list result I see on CentOS 7.7.1908 > with openssl 1:1.0.2k-19.el7: > > [root@localhost ~]#openssl ciphers > > 'DEFAULT:!EXPORT:!LOW:!MEDIUM:!kECDH:!kDH:!aDSS:!PSK'|tr : '\n' > > [...] > >

Re: [exim] tls_sni = $host for all outgoing connections

> On Oct 12, 2019, at 7:56 AM, Heiko Schlittermann via Exim-users > wrote: > > what harm can happen if we set tls_sni = $host for all outgoing > smtp connections? > > Can't we make it defaulting to the remote host name? It needs to match the TLSA base domain for DANE, which is occasionally,

Re: [exim] Define preferred encryption algorithms

> On Oct 12, 2019, at 9:36 AM, Mike Tubby via Exim-users > wrote: > > # OWASP Widest Compatibility (List C) > tls_require_ciphers = >

Re: [exim] Define preferred encryption algorithms

> On Oct 10, 2019, at 10:30 AM, jmedard--- via Exim-users > wrote: > > More and more Internet security diagnostic tools (such as Immuniweb and > Hardenize) specify that mail servers should be able to offer their preferred > encryption algorithms. They consider it a security risk if the server

Re: [exim] RFC: submission mode should strip BCC header?

> On Sep 26, 2019, at 12:50 PM, Evgeniy Berdnikov via Exim-users > wrote: > >> at least one MUA strips the >> BCC headers before submitting the message, but fails to do so when >> "resending" the message. (I'm talking about Mutt, and its "bounce" >> capability). > > Because "bounce" function

Re: [exim] New compromise...?

On Wed, Sep 25, 2019 at 09:47:41AM +0200, Mark Elkins via Exim-users wrote: > However - from my viewpoint, the Username used in the authentication > "mycli...@zanet.co.za" should be the same as the "From".. i.e. <= > minan...@zanet.co.za. > Is there a neat way to drop emails when the "From" is

Re: [exim] SSL encryption rejected

On Mon, Sep 16, 2019 at 05:05:47PM -0300, Jorge Listas via Exim-users wrote: > days ago my hosting provider has updated exim without notifying me, from > version 4.87_1 to 4.89 > > It is installed on a server under CentOS release 5.11 and with openSSL 0.98e OpenSSL 0.9.8 has been unsupported

Re: [exim] TLS unsupported protocol?

> On Sep 2, 2019, at 7:01 PM, Mike Tubby via Exim-users > wrote: > > 2019-09-02 23:57:30 CONNECT: New connection from 80.82.32.21:62950 -> > 195.171.43.32:25 > 2019-09-02 23:57:30 CONNECT: Accepting connection from: 80.82.32.21 - not > blocked by any RBL > 2019-09-02 23:57:30 HELO: Accepted

Re: [exim] Exim and Postfix

> On Aug 31, 2019, at 7:52 AM, Jasen Betts via Exim-users > wrote: > > Interpreted code is abot 100 times slower than native code, but disk is > about 100 times slower than memory, and WAN is about 100 times slower than > disk. what's the hurry? It is not the CPU cost of the MTA's code

Re: [exim] Exim and Postfix

On Wed, Aug 28, 2019 at 05:19:37PM +0800, Eliza via Exim-users wrote: > If exim supports runtime configuration, it becomes more flexible, for > content filter etc. But how about the performance to accept/deliver > messages comparing to postfix? Postfix should generally outperform Exim under

Re: [exim] Exim and Postfix

> On Aug 27, 2019, at 10:10 PM, Eliza via Exim-users > wrote: > > Is exim a multi-processes MTA, No, Exim is largely monolithic, with the same process accepting the inbound message and delivering it (modulo some messages being queued for later delivery). > While postfix is a threads powered

Re: [exim] disable ipv6 for smtp to google

> On Jul 30, 2019, at 11:13 AM, Randy Bush via Exim-users > wrote: > > Google's reputation and hoops of fire for accepting smtp over ipv6 have > become overly annoying. how can i disable ipv6 when delivering to > google with out disabling for reasonable ipv6 enabled internet sites. > or do i

Re: [exim] [exim-dev] Excursus Retry 451 452 Strategies

> On Jul 29, 2019, at 10:30 AM, Дилян Палаузов via Exim-dev > wrote: > > I guess, that a site publishing many MX records pointing to many IP addresses > is not an additional option to increase > the retry rate. RFC-compliant MTAs accept at least 100 recipients per transaction. RFC-compliant

Re: [exim] DNS problems with sending via multiple smarthosts

On Fri, Jul 19, 2019 at 09:15:26AM +0300, Evgeniy Berdnikov via Exim-users wrote: > > Might there be a dnssec-related difference? > > Definitely NO, because this difference is in client's initial packets. Actually, the "tcpdump" documentation is misleading. In the attached PCAP file (single

Re: [exim] DNS problems with sending via multiple smarthosts

> On Jul 18, 2019, at 6:32 PM, Jeremy Harris via Exim-users > wrote: > >> A few anomalies are checked and may result in extra fields enclosed in >> square brackets: If a query contains an answer, authority records or >> additional records section, ancount, nscount, or

Re: [exim] Available ciphers with stock Debian (gnutls) exim

On Sat, Jul 13, 2019 at 02:16:22PM +0100, Russell King via Exim-users wrote: > Maybe someone can provide some hints what Key Usage should be set for an > exim server certificate. According to Red Hat's website: > > >

Re: [exim] Failure to deliver to Gmail

On Fri, Jun 28, 2019 at 02:50:25PM +0100, Richard Jones via Exim-users wrote: > On Jun 27, Viktor Dukhovni via Exim-users wrote > > Which is exactly this. IIRC there's a recent Exim patch, or you > > can disable TLS 1.3, or switch to Exim built with OpenSSL. > > Thanks Vikt

Re: [exim] Failure to deliver to Gmail

On Thu, Jun 27, 2019 at 04:44:33PM +0100, Richard Jones via Exim-users wrote: > On Jun 27, Niels Dettenbach wrote > > Relaying to GMail from "unknown third party" SMTP servers could be very > > limited / "downslowed" by different "temp avail" strategies. Google offers > > a > > "postmaster

Re: [exim] Failure to deliver to Gmail

> On Jun 27, 2019, at 5:58 AM, Richard Jones via Exim-users > wrote: > > There have been a few mails about this recently, but I don't think they > cover my case (nor is this about my previous mail about retry times) There was a recent thread that's an excellent match, that reported

Re: [exim] 4xx from GMAIL for fatal errors

On Thu, Jun 27, 2019 at 12:51:20PM +0200, Axel Rau via Exim-users wrote: > > On 27/06/2019 10:17, Axel Rau via Exim-users wrote: > >> 451-4.3.0 Multiple destination domains per transaction is unsupported. > >> or > >> 452-4.2.2 The email account that you tried to reach is over quota. I don't

Re: [exim] exim-4.92: GSSAPI authenticator doesn't work

On Thu, Jun 20, 2019 at 04:05:52PM +0200, Frank Richter via Exim-users wrote: > 4.91: > … > 17651 Initialised Cyrus SASL server connection; service="smtp" > fqdn="servername.tu-chemnitz.de" realm="NULL" What user is exim 4.91 running as when reading the keytab file? And which keytab file has

Re: [exim] A TLS fatal alert has been received.: Insufficient security

> On Jun 11, 2019, at 2:08 PM, Thomas Krichel via Exim-users > wrote: > >> shows that the error message in question is from the GnuTLS DANE >> library in dane_state_init() trying to initialize libunbound... > > On the sender or the receiver? Is there any fix I can do > or do I need to

Re: [exim] A TLS fatal alert has been received.: Insufficient security

> On Jun 11, 2019, at 4:30 AM, Jeremy Harris via Exim-users > wrote: > >> 2019-03-25 09:00:08 1h8LSh-0001oy-Uy DANE attempt failed; TLS connection >> to mx-ha03.web.de [212.227.15.17]: (certificate verification failed): TLSA >> record problem: There was error initializing the DNS query. > >

Re: [exim] A TLS fatal alert has been received.: Insufficient security

On Mon, Jun 10, 2019 at 05:51:42PM +0200, Arno Thuber via Exim-users wrote: > The thing is, that it as far as I can see only happens when receiving > messages from the German mail provider GMX. The gmx.de MTAs support DANE in both directions. Does your MX host have published DANE TLSA records?

Re: [exim] TLS with gmail started failing

> On Jun 7, 2019, at 1:37 PM, Viktor Dukhovni via Exim-users > wrote: > > Actually, that did not work, I must have botched the command-line > arguments. The "STARTTLS" never happened, as can be seen from the > fact that the EHLO response still cont

Re: [exim] TLS with gmail started failing

On Fri, Jun 07, 2019 at 10:30:52AM -0700, Marc MERLIN wrote: > > And also with gnutls-cli: > > > > $ gnutls-cli --crlf --starttls --port 25 smtp.example.net > > alt4.gmail-smtp-in.l.google.com > > Thanks for that suggestion. > That seems to work > > magic:~# gnutls-cli --crlf --starttls

Re: [exim] TLS with gmail started failing

On Fri, Jun 07, 2019 at 09:16:04AM -0700, Marc MERLIN via Exim-users wrote: > 14:32:03 5341 gnutls_handshake was successful > 14:32:03 5341 TLS certificate verification failed (certificate invalid): > peerdn="C=US,ST=California,L=Mountain View,O=Google LLC,CN=mx.google.com" > 14:32:03 5341

Re: [exim] SSL forcing

> On May 19, 2019, at 1:00 PM, Cyborg via Exim-users > wrote: > > Problem is, that even if tls_1.2 is out since 2008, a communication > partner may use SSLv3 or TLS 1.0/1.1 and using just "encrypted = *" , > you will accept it. My advice is to avoid knee-jerk reactions to mostly HTTP-related

Re: [exim] Message rejected due to long Reference: header

On Tue, Apr 16, 2019 at 04:38:54PM +0100, Jeremy Harris via Exim-users wrote: > The 998 limit is for de-folded lines. Go over that and you'd need > multiple header lines; to do which you'd have to be duplicating > header_names: as well as adding linebreaks. And yes, that would > very likely

Re: [exim] Deny when from and to are the same (Jeremy Harris)

> On Apr 8, 2019, at 11:33 PM, AC via Exim-users wrote: > > No, I understand what I'm looking at and I know what I'm asking for. In point of fact, you really don't understand the message "envelope", i.e. how messages are processed in transit between systems. [ The liberating thing about not

Re: [exim] Server offering *all* certificates

> On Mar 29, 2019, at 11:18 PM, Phil Pennock via Exim-users > wrote: > > With OpenSSL, as Jeremy hints at: the behaviour depends entirely upon > whether you provide the library with "a file containing all valid certs" > or "a directory within which we can look for files matching a hash of > the

Re: [exim] exim segfault on CSA check

On Fri, Mar 15, 2019 at 12:04:47PM -0400, Bill Cole via Exim-users wrote: > > I've not looked hard to find one. The original RFC > > for SRV doesn't mention CNAME. > > It would not be feasible to prohibit a CNAME reply for a specific query > RRTYPE, since a CNAME has always been defined as

Re: [exim] MTA-STS support?

> On Feb 3, 2019, at 11:28 PM, Alice Wonder via Exim-users > wrote: > > Some don't want to have coordinate certificates with fingerprints in TLSA > records, > as more hosting providers provide DNSSEC just by default when you use their > DNS as > well, MTA-STS may be easier than new

Re: [exim] MTA-STS support?

On Thu, Jan 31, 2019 at 08:58:04PM -0800, Alice Wonder via Exim-users wrote: > One thing I am hoping is that an update to the standard will be > published that allows the mode (enforce or testing or none) to be > published in the DNS record for MTA-STS. > > When the zone is DNSSEC signed, the

Re: [exim] Expiriences with TLS 1.3

On Tue, Jan 29, 2019 at 06:53:33PM +0200, Max Kostikov via Exim-users wrote: > Jeremy Harris via Exim-users писал 2019-01-28 13:56: > > I've not seen any such connections in production yet. > > FreeBSD 12 have OpenSSL 1.1.1 in base system so I see entries in the > Exim log. For the record, not

Re: [exim] Expiriences with TLS 1.3

> On Jan 28, 2019, at 6:56 AM, Jeremy Harris via Exim-users > wrote: > >> is anyone of you running TLS 1.3 already ? > > It functions fine in the Exim regression-test suite, > on systems having suitable library support. > > I've not seen any such connections in production yet. As part of the

Re: [exim] How multi-recipient messages are handled?

> On Nov 19, 2018, at 3:35 PM, Jasen Betts via Exim-users > wrote: > > Ideally you use PRDR if the source requests it. > > PRDR: > https://tools.ietf.org/html/draft-hall-prdr-00 > https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html#SECTPRDRACL Keep in mind

Re: [exim] [m...@openssl.org: Re: [openssl-users] openssl 1.0.2 and TLS 1.3]

> On Sep 11, 2018, at 5:35 PM, Phil Pennock wrote: > > My proposal to change the OpenSSL API we use ran into the need to > basically recreate the framework, because of LibreSSL declining to > implement that new API. I just compiled Exim master against OpenSSL 1.1.0 (in /usr/local) on my

Re: [exim] [m...@openssl.org: Re: [openssl-users] openssl 1.0.2 and TLS 1.3]

> On Sep 11, 2018, at 5:35 PM, Phil Pennock wrote: > > My proposal to change the OpenSSL API we use ran into the need to > basically recreate the framework, because of LibreSSL declining to > implement that new API. LibreSSL is basically OpenSSL 1.0.2, you don't have to wait for LibreSSL to

Re: [exim] [m...@openssl.org: Re: [openssl-users] openssl 1.0.2 and TLS 1.3]

On Tue, Sep 11, 2018 at 03:37:12PM +0100, Jeremy Harris via Exim-users wrote: > One wonders if there exists a succinct definition of what the difference > in the API is. The FAQ section on the openssl.org site doesn't have > one. The CHANGES file describes the changes between 1.0.2 and 1.1.0

Re: [exim] DANE(TA) doesn't work with self signed certificates

On Mon, Sep 10, 2018 at 11:30:03AM +0200, Michael Westerburg wrote: > > It seems you mean a "private" issuer CA, or any root CA that is not > > included in the local trust store used for non-DANE verification. > > You are absolutely right. Sorry for my misleading description. > > > Your report

Re: [exim] DANE(TA) doesn't work with self signed certificates

> On Sep 9, 2018, at 10:47 AM, Jeremy Harris via Exim-users > wrote: > > I've managed to reproduce the situation in the Exim testsuite. > With the current master branch, built with OpenSSL it works fine; > built with GnuTLS (v 3.6.3 on Fedora 28) it does not. I did not expect DANE-TA(2)

Re: [exim] DANE(TA) doesn't work with self signed certificates

> On Sep 4, 2018, at 8:26 AM, Michael Westerburg via Exim-users > wrote: > > Hello Exim-users-list, > > shortly we introduced DANE but soon afterwards we detected problems > sending mails to domains using DANE(TA) with self signed certificates. > Using Exim 4.91 with GnuTLS 3.5.18 (Ubuntu

Re: [exim] DANE(TA) doesn't work with self signed certificate

> On Sep 7, 2018, at 1:32 PM, Andreas Metzler via Exim-users > wrote: > > Are you positive that this is a problem in GnuTLS and not in a problem > in exim's usage of gnutls-dane? > > Asking, since > danetool --check=lists.gentoo.org --proto tcp --starttls-proto=smtp > succeeds. (I have

Re: [exim] DANE(TA) doesn't work with self signed certificate

> On Sep 7, 2018, at 1:19 PM, Jan Ingvoldstad via Exim-users > wrote: > > Additionally, Debian is, in the longer term, in a position to use a > different TLS library than GnuTLS. Debian has historically been ultra-conservative on the potential License compatibility issues between GPL (Exim)

Re: [exim] DANE(TA) doesn't work with self signed certificate

> On Sep 7, 2018, at 3:33 AM, Jan Ingvoldstad via Exim-users > wrote: > > Please, if you have not already done so, file a bug report with Debian, > this is a pretty major bug. Until there's either a fix in GnuTLS (Nikos Mavrogiannopoulos can get in touch with me if there are questions), or

Re: [exim] DANE(TA) doesn't work with self signed certificate

On Wed, Sep 05, 2018 at 03:56:55PM +0100, Klaus Ethgen via Exim-users wrote: > > I suppose your Exim is also linked to GnuTLS? > > Sure, it is the common debian version and Debian is always linking > against gnutls. You can rebuild the source deb against OpenSSL:

Re: [exim] DANE(TA) doesn't work with self signed certificates

> On Sep 5, 2018, at 1:56 AM, Klaus Ethgen via Exim-users > wrote: > > I had the same problem some days ago. > > I do not trust any CA, so no CA is in my truststore. However, some days > ago, I posted to lists.gentoo.org. They have a valid TLSA entry but exim > told me that it can't be

Re: [exim] DANE(TA) doesn't work with self signed certificates

> On Sep 4, 2018, at 8:52 AM, Jeremy Harris via Exim-users > wrote: > > As the docs say: > > "DANE-TA usage is effectively declaring a specific CA to be used; this > might be a private CA or a public, well-known one." > > That CA needs to be known by the Exim configuration. Sorry, that's

[exim] DANE-TA(2) private CAs and SHA-1

By using DANE-TA(2) TLSA records you can associate your SMTP server with a either a public or private (your own) issuer CA. This can simplify the management of TLSA records of multiple MX hosts by using a CNAME to a common location where you publish the shared CA key hash. Some care needs to be

Re: [exim] Apple + Outlook - Exim on 587 does not work - Solutions

> On Jun 9, 2018, at 10:01 AM, Jeremy Harris via Exim-users > wrote: > >> I cannot get this to work with my Macbook and MS >> Outlook as there is no setting for TLS encryption in MS Outlook for Mac. >> (believe you me, I have looked extensively). > >

Re: [exim] disable tls_verify_cert_hostnames?

> On May 31, 2018, at 2:05 PM, Emanuel Gonzalez via Exim-users > wrote: > > The problem occurs when my clients send through a mail client (example > thunderbird) > Which is when Exim verifies the *client's* certificate. > tls_certificate = /opt/exim/ssl/exim2.crt > tls_privatekey =

Re: [exim] Exim & DANE .. status ?

> On May 23, 2018, at 9:58 AM, Cyborg via Exim-users > wrote: > > We should get back to a working config example :) Indeed, and actual Exim users will probably share config advice, but *before* you get to that: Step 0a: Implement monitoring. Do not deploy

Re: [exim] Exim & DANE .. status ?

> On May 23, 2018, at 3:14 AM, Kurt Jaeger via Exim-users > wrote: > > Can you elaborate ? We're getting into off-topic ratholes that are the subject of much heated debate. Perhaps best to stop here? -- Viktor. -- ## List details at

Re: [exim] Exim & DANE .. status ?

> On May 23, 2018, at 1:38 AM, Niels Dettenbach (Syndicat IT & Internet) > wrote: > > DANE is very young? Yes, actually, the base specification is from late 2012, but it it had browsers in mind, even though it has since turned out to be a much better fit for MTA-to-MTA

Re: [exim] Exim & DANE .. status ?

> On May 22, 2018, at 1:00 PM, Niels Dettenbach (Syndicat IT & Internet) via > Exim-users wrote: > > Am 22. Mai 2018 18:09:24 MESZ schrieb Cyborg via Exim-users > : >> Hi Guys, >> >> the german office of security ( BSI ) has given out a policy, that

Re: [exim] Exim & DANE .. status ?

On Tue, May 22, 2018 at 12:30:23PM -0400, Viktor Dukhovni via Exim-users wrote: > One small correction to the text below: > >https://tools.ietf.org/html/rfc7671#section-5.2.2 Perhaps another tweak would be useful, in the below: At the time of writing, https://www.huque.com/bin

Re: [exim] Exim & DANE .. status ?

> On May 22, 2018, at 12:09 PM, Cyborg via Exim-users > wrote: > > So, whats the status of DANE for Exim? > > Any usefull selfexplaning examples at hand ? :) Have you looked at:

Re: [exim] UTF 8 From header

> On May 1, 2018, at 3:31 AM, Jasen Betts via Exim-users > wrote: > > RFC5322 makes no concrete restrictions on From header content. This is of course false. https://tools.ietf.org/html/rfc5322#section-3.6.2 from= "From:" mailbox-list CRLF Which then

Re: [exim] UTF 8 From header

> On May 1, 2018, at 1:20 AM, Ted Cooper via Exim-users > wrote: > > Is this a legal "From:" header? > >> From: =?utf-8?b?IkVsbGEgQmFjaMOpIiA8ZGlnaXRhbEBlbGxhYmFjaGUuY29tLmF1Pg==?= It is a legal display name (phrase in the language of RFC5322), but it is missing the

Re: [exim] setting up purchased SSL certificates on existing system

> On Apr 30, 2018, at 10:32 AM, Heiko Schlittermann via Exim-users > wrote: > > Or just combine everything: > >cat CERT-PEM BUNDLE-PEM <(openssl rsa -in KEY-PEM) > DIR/ssl.pem Don't forget a prior "umask 077" to make sure that the key file is NOT world-readable. --

Re: [exim] Next Exim: TLS: changed smarthost example config

> On Apr 20, 2018, at 8:17 PM, Phil Pennock via Exim-users > wrote: > > .ifdef _HAVE_OPENSSL > tls_require_ciphers = HIGH:@STRENGTH > .endif I'd make that: HIGH:!aNULL:!aDSS:!kECDHr:!kECDHe:!kDHr:!kDHd Because, the ciphers are already sensibly ordered as of

Re: [exim] compiling 4.91 under FreeBSD

> On Apr 16, 2018, at 1:02 PM, Lena--- via Exim-users > wrote: > > Had someone this error? Using port: > > cc tls.c > In file included from tls.c:122: > tls-openssl.c: In function `tls_refill': > tls-openssl.c:2499: error: structure has no member named `verify_stack' >

Re: [exim] Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list

> On Mar 28, 2018, at 3:10 AM, Konstantin Boyandin via Exim-users > wrote: > > Can someone recommend simplest ciphers selection for Exim, to exclude the > mentioned cipher? The settings present on cipherli.st: > > tls_require_ciphers = AES128+EECDH:AES128+EDH >

[exim] Recording of DANE talk at ICANN61

[ Also posted to dane-us...@sys4.de, and postfix-us...@postfix.org, please pardon the duplication if you're seeing this two or more times. I'm planning to also post d...@ietf.org ] I gave a talk about DANE for SMTP at the ICANN61 conference last week. Audio and slides are available, but not

Re: [exim] Any way to implement an incoming SMTP time limit?

> On Mar 12, 2018, at 7:38 AM, Jeremy Harris via Exim-users > wrote: > >> I've set smtp_receive_timeout in an attempt to limit the time an incoming >> connection can stay active - this works as designed - however this timer is >> reset whenever any new data comes in -

Re: [exim] TLS 1.3

> On Mar 7, 2018, at 4:49 AM, Torsten Tributh via Exim-users > wrote: > > Hi, > if you want to use openssl you just have to add some TLSv1.3 Ciphers to > the tls_require_ciphers. > It must be TLS13-AES-128-GCM-SHA256 (openssl writing of the cipher) > > See the RFC

Re: [exim] TLS error in incoming emails from *.outlook.com

> On Feb 12, 2018, at 11:57 PM, Ian Zimmerman via Exim-users > wrote: > > I am slightly surprised I could do that; I'd have expected only root on > the host machine to have that power. I would also expect that typically the changes need to happen on the host, though some

Re: [exim] TLS error in incoming emails from *.outlook.com

> On Feb 12, 2018, at 10:19 PM, Ian Zimmerman via Exim-users > wrote: > >> My previous assesment was wrong: even when exim was compiled with >> OpenSSL instead of GnuTLS the error did occur, albeit with a different >> error message. > > Same here. The new error message

<    1   2   3   >