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

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

> On Feb 12, 2018, at 8:21 PM, Andreas Bauer via Exim-users > wrote: > > 504 540.259940 40.92.67.82 TCP 66 >45792 → 25 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 > 505 540.259967 40.92.67.82

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] 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 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 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 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 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 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: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

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

[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] [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 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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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 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 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] 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 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] 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 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] 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] 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] 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 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] 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] 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 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] 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] 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 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] 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] [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 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] 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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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 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] 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 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] 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] 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] 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

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

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

[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] 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] PLEASE NOTE: Upcoming changes in Let's Encrypt issuer certificates

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

Re: [exim] PLEASE NOTE: Upcoming changes in Let's Encrypt issuer certificates

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

[exim] PLEASE NOTE: Upcoming changes in Let's Encrypt issuer certificates

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   2   3   >