On 14 May 2021, at 21:53, Eric Germann via mailop wrote:
For the STARTTLS cert I’m using LetsEncrypt. DANE is also in place.
The TLS certificate checker at https://esmtp.email/tools/tls/ returns a
Sectigo certificate which otherwise matches mail.semperen.com and
www.mail.semperen.com on port 25. This is what a compliant MTA-STS
implementation would do (and is part of what
https://esmtp.email/tools/mta-sts/ does.
My question is what could be the cause of the failure?
1. Certificate validation error in the certificate chain
The certificate chain I am seeing is unusual (to me) because it is
presenting two separate signature paths, likely due to the rebranding of
Comodo/Sectigo.
```
$ ccheck chain --starttls smtp.semperen.com:25
* spec smtp.semperen.com:25
TLS version: TLS-1.2
Cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[chain 0]
[cert 0.0]
Subject: CN=smtp.semperen.com
Issuer: CN=Sectigo RSA Domain Validation Secure Server
CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
Serial: 22691099081371953397362798816794149806
Dates: 2020-10-23 00:00:00 +0000 UTC to 2021-10-23 23:59:59 +0000
UTC
Signature Algorithm: SHA256-RSA
CA: false
DNS: smtp.semperen.com
DNS: www.smtp.semperen.com
[cert 0.1]
Subject: CN=Sectigo RSA Domain Validation Secure Server
CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
Issuer: CN=USERTrust RSA Certification Authority,O=The USERTRUST
Network,L=Jersey City,ST=New Jersey,C=US
Serial: 166627644428940058458651716034439089575
Dates: 2018-11-02 00:00:00 +0000 UTC to 2030-12-31 23:59:59 +0000
UTC
Signature Algorithm: SHA384-RSA
CA: true
[cert 0.2]
Subject: CN=USERTrust RSA Certification Authority,O=The USERTRUST
Network,L=Jersey City,ST=New Jersey,C=US
Issuer: CN=USERTrust RSA Certification Authority,O=The USERTRUST
Network,L=Jersey City,ST=New Jersey,C=US
Serial: 2645093764781058787591871645665788717
Dates: 2010-02-01 00:00:00 +0000 UTC to 2038-01-18 23:59:59 +0000
UTC
Signature Algorithm: SHA384-RSA
CA: true
[chain 1]
[cert 1.0]
Subject: CN=smtp.semperen.com
Issuer: CN=Sectigo RSA Domain Validation Secure Server
CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
Serial: 22691099081371953397362798816794149806
Dates: 2020-10-23 00:00:00 +0000 UTC to 2021-10-23 23:59:59 +0000
UTC
Signature Algorithm: SHA256-RSA
CA: false
DNS: smtp.semperen.com
DNS: www.smtp.semperen.com
[cert 1.1]
Subject: CN=Sectigo RSA Domain Validation Secure Server
CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
Issuer: CN=USERTrust RSA Certification Authority,O=The USERTRUST
Network,L=Jersey City,ST=New Jersey,C=US
Serial: 166627644428940058458651716034439089575
Dates: 2018-11-02 00:00:00 +0000 UTC to 2030-12-31 23:59:59 +0000
UTC
Signature Algorithm: SHA384-RSA
CA: true
[cert 1.2]
Subject: CN=USERTrust RSA Certification Authority,O=The USERTRUST
Network,L=Jersey City,ST=New Jersey,C=US
Issuer: CN=AAA Certificate Services,O=Comodo CA
Limited,L=Salford,ST=Greater Manchester,C=GB
Serial: 76359301477803385872276235234032301461
Dates: 2019-03-12 00:00:00 +0000 UTC to 2028-12-31 23:59:59 +0000
UTC
Signature Algorithm: SHA384-RSA
CA: true
[cert 1.3]
Subject: CN=AAA Certificate Services,O=Comodo CA
Limited,L=Salford,ST=Greater Manchester,C=GB
Issuer: CN=AAA Certificate Services,O=Comodo CA
Limited,L=Salford,ST=Greater Manchester,C=GB
Serial: 1
Dates: 2004-01-01 00:00:00 +0000 UTC to 2028-12-31 23:59:59 +0000
UTC
Signature Algorithm: SHA1-RSA
CA: true
```
I would give this a try with an LE certificate. I use that myself to
send email to Gmail with no issues. Note that you will need to add a new
TLSA record.
2. No reverse DNS for the IPv6 address
The host is in AWS and has a PTR for IPv4 setup correctly. Not sure
if you can do a PTR for IPv6 in AWS
I have been able to do it with no issues in the past via the same form
you use for IPv4 rDNS/SMTP unblocking. That said, I wouldn't think this
is a factor when in the scenario you describe, Gmail will be _sending_
to semperen.com.
Mail is delivered successfully to and from gmail. DMARC and DKIM and
SPF and ARC all pass.
I think you will find that without rDNS for your IPv6, your MTA is
either trying first with IPv4 or retrying over IPv4 after failing with
IPv6 due to no rDNS. This is easy to check in the corresponding
`Received` header.
Hope this helps
-lem
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
