On Wed, Mar 29, 2023 at 06:59:42PM +0000, 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 different domain. Anyway, how to
> know that PTR/MX's name, obtained via DNS, is not forged?
FWIW, DANE SMTP (rfc7672) answers that question. The name to verify
(when validation is via DANE-TA(2) TLSA records) is any of:
- The TLSA base domain, or (typically same as),
- The MX hostname or
- The nexthop domain
> And finally, it seems that you expect, that cert will match
> name of MTA. OK, we can use name from MX, but what
> with systems which provides MTAs for thousands domains?
Makes little difference, one.com uses a modest pool of (tens of) MX
hosts for 1.2 million hosted domains. Other hosting providers use
per-domain MX hosts, but the same underlying public key and matching
"3 1 1" TLSA record. TLSA records can also be CNAMEs.
> Do you expect that all these domains have to use
> the same name in MX? Or do you expect thousands certs
> on that MTA?
Either will work, but a single MX hostname is simpler to operate.
> Or one cert with thousands names in SAN?
That's what SNI is for, but once again a shared MX hostname is better.
> Slavko
> https://www.slavino.sk/
--
Viktor.
P.S. By the way, your domain is DNSSEC-signed, you could with very modest
effort deploy DANE:
https://stats.dnssec-tools.org/explore/?slavino.sk
But, if so, make it robust. First implement monitoring, and a cert/key
rollover process that avoids intermittent outages during key changes
by pre-publishing overlapping TLSA records that match both the old
and new key for a few TTLs before the new cert is deployed:
https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
