Hi Brandon,
Thank you for the responses. I’ll send you some examples off list of successes
and failures from the exact same sender and final recipient, both Gmail users.
I’d very much like to understand why we are seeing what appears to be an
increase in DKIM validation failures in order to d
> I'm sure I've had a long explanation on here in the past year, but the
> short answer is if the message is not DKIM valid and you're forwarding, you
> should rewrite
> the MAIL FROM to a domain you own that will SPF authn the message... and
> try not to forward spam.
That's not how forwarding wo
Looking at the messages from that IP getting that rejection message, I'm
seeing a lot of DKIM body hash did not verify, I'd also verify that your
system isn't modifying the messages that it is forwarding.
Brandon
On Tue, Sep 12, 2023 at 8:20 PM Brandon Long wrote:
> That message did not have a
That message did not have a DKIM header ... or was so garbled that we
didn't extract it.
Due to DKIM replay, we may spam reject forwarded messages that DKIM verify
but not SPF, but those would not have that rejection message.
And yes, we are continuing to ramp no auth, no entry.
I'm sure I've ha
We are seeing an increasing number of bounces by Gmail related to failed
authentication checks. The bounces include language like:
<<< 550-5.7.26 This mail is unauthenticated, which poses a security risk to
the
<<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender must
<<< 550-
On Tue, Sep 12, 2023 at 3:09 PM Anne Mitchell via mailop
wrote:
>
> From what I read into this, it likely means you are already on a paid
> package, and that package includes the individual reports, and also that
> now they are offering aggregated reports and you will be able to get
> thosealso
> On Sep 12, 2023, at 2:30 PM, Mark Fletcher wrote:
>
>> We just wrote up everything that we know about this, including how much it
>> will cost, what it actually means, what's still free, etc. It's too long to
>> quote here (and it contains quotes from Validity) but here it is in case you
On Tue, Sep 12, 2023 at 11:19 AM Anne Mitchell via mailop
wrote:
>
> We just wrote up everything that we know about this, including how much
> it will cost, what it actually means, what's still free, etc. It's too long
> to quote here (and it contains quotes from Validity) but here it is in case
We just wrote up everything that we know about this, including how much it
will cost, what it actually means, what's still free, etc. It's too long to
quote here (and it contains quotes from Validity) but here it is in case you
want all of that info:
https://www.isipp.com/blog/validity-fbl-ch
I confirm it was a SNI issue. Some people were using custom MX names
pointing to our IPs, and some senders didn't like the default certificate.
Thank you all!
Camille
Le 12/09/2023 à 15:04, Taavi Eomäe via mailop a écrit :
On 12/09/2023 15:33, Bill Cole via mailop wrote:
Your CA (LetsEncrypt)
I confirm it was a SNI issue. Some people were using custom MX names
pointing to our IPs, and some senders didn't like the default certificate.
Thank you all!
Camille
Le 12/09/2023 à 15:04, Taavi Eomäe via mailop a écrit :
On 12/09/2023 15:33, Bill Cole via mailop wrote:
Your CA (LetsEncrypt)
On 12/09/2023 15:33, Bill Cole via mailop wrote:
Your CA (LetsEncrypt) says that is breakage and they offer a fix. Take
it or leave it, but saying that it isn't broken is wrong.
It is not wrong.
There's a valid and trusted path, that is sufficient. If your TLS client
does not build certifica
On 2023-09-12 at 02:18:56 UTC-0400 (Tue, 12 Sep 2023 08:18:56 +0200)
Camille - Clean Mailbox via mailop
is rumored to have said:
Hi Bill,
└─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls
smtp
[...]
---
Certificate chain
0 s:CN = clean-mailbox.com
i:C = US, O = Let's Encryp
I think I figured out what's happening after increasing the TLS debug logs.
Some incoming connections are initiated using a FQDN for which I don't
have a valid SSL certificate (another address than mx.clean-mailbox.com).
I'll investigate & keep you posted.
Best regards,
Camille
Le 12/09/2023
On Tue, Sep 12, 2023 at 09:25:54AM +0200, Camille - Clean Mailbox via mailop
wrote:
> Hi,
>
> I didn't changed anything in Postfix configuration. But yes, over the last
> months, we upgraded from Debian 11 (OpenSSL 1.1.1n) to Debian 12 (OpenSSL
> 3.0.9).
> I don't see anything in openssl.cnf that
If it works without your MTA being involved then it may a configuration setting
on your side or theirs.
Can you turn up the TLS debug log level on your MTA? That should point to where
in the negotiation it’s failing for future connections.
Ken.
> On 12 Sep 2023, at 12:28, Camille - Clean Ma
Ahoj,
Dňa Tue, 12 Sep 2023 12:28:13 +0200 Camille - Clean Mailbox via mailop
napísal:
> └─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls smtp
I can do TLS1.0, TLS1.2 & TLS1.3 handshake with your server and GnuTLS
reports certificate as valid, thus the certificate itself seems to
Hi,
└─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls smtp
CONNECTED(0003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = clean-mailbox.com
verify return:1
---
Certif
What do you see when you run openssl s_client -connect… against the the MTAs
that are associated with this specific error in your logs?
Ken.
> On 12 Sep 2023, at 10:50, Camille - Clean Mailbox via mailop
> wrote:
>
> Ok I'm now running RSA without DST cert:
> # openssl crl2pkcs7 -nocrl -cer
Ok I'm now running RSA without DST cert:
# openssl crl2pkcs7 -nocrl -certfile
/etc/letsencrypt/live/clean-mailbox.com/fullchain.pem | openssl pkcs7
-print_certs -noout
subject=CN = clean-mailbox.com
issuer=C = US, O = Let's Encrypt, CN = R3
subject=C = US, O = Let's Encrypt, CN = R3
issuer=C =
Ahoj,
Dňa Tue, 12 Sep 2023 09:25:59 +0200 Geert Hendrickx via mailop
napísal:
> The reason is likely the certificate itself, not the chain; this
> server offers (only) an ECC certificate, and while the vast majority
> of clients are compatible with this today, some still only support
> RSA.
Yes
Hi,
Just changed it to RSA, still have the same kind of errors:
2023-09-12T09:32:42.528685+02:00 mx1 postfix/smtpd[903460]: SSL_accept
error from o167.p8.mailjet.com[87.253.233.167]: -1
2023-09-12T09:32:42.528920+02:00 mx1 postfix/smtpd[903460]: warning: TLS
library problem: error:0A000412:SSL
Hi James,
I'm using certbot 2.1.0 (provided with Debian 12). I don't have anything
like this in my renewal configuration file:
[renewalparams]
account = [my ID]
authenticator = dns-cloudflare
dns_cloudflare_propagation_seconds = 30
dns_cloudflare_credentials = /etc/letsencrypt/cloudflare-clean-
On Mon, Sep 11, 2023 at 18:26:18 -0400, Bill Cole via mailop wrote:
> That's an indication that the client does not like your certificate.
>
> As for why, see
> https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
>
> TL;DR: you need to fix the chain of trust for your certificat
Hi,
I didn't changed anything in Postfix configuration. But yes, over the
last months, we upgraded from Debian 11 (OpenSSL 1.1.1n) to Debian 12
(OpenSSL 3.0.9).
I don't see anything in openssl.cnf that could restrict something, if
you have any idea.
Best regards,
Camille
Le 12/09/2023 à 07:
Dňa 12. septembra 2023 6:18:56 UTC používateľ Camille - Clean Mailbox via
mailop napísal:
>Also I think it's normal that the client doesn't like the answer of my servers
>if the client tries to initiate a SSLv3 connection, as I've disabled it in
>Postfix.
While i am not familiar with postfix
Dňa 12. septembra 2023 6:12:16 UTC používateľ "Taavi Eomäe via mailop"
napísal:
>No. The chain may contain an expired root certificate. A client must only
>validate the chain until the first trusted root. LetsEncrypt's should be
>trusted first, certificate chain must be validated until that an
27 matches
Mail list logo
