This violates encapsulation and segregation of concerns.
For an MTA with a caching validating resolver on localhost (since all
but the validating part is common best practice today):
If validation logic goes into an MTA, then the MTA needs to be updated
to know about new signing algorithms, deal with yet more discovered
flaws in DNSSEC handling, and generally process UDP data received over
the network as the mail run-time user.
By contrast, letting the DNS resolver handle validation lets the work be
done right, by the experts, and updated accordingly. It lets trust
anchor management be done by DNS software, not mail-software. It lets
the cache, cache only the data that validates. Since all SMTP
mail-servers need a DNS cache near them to perform at all acceptably,
making sure that the cache is well managed and that the mail-server
works cooperatively with the cache is critical.
For Exim, we set DO, we check AD, and if the administrator sets things
up insecurely, that's their problem. The most I might do is add a check
that the resolver IP is 127/8 or ::1 or other local system IP address,
(in Exim speak, matches the @[] addresslist) and require a second option
dnssec_really_trust_offhost_validator when that doesn't match. Even
that would be dubious, leading to more debugging issues and insecurity
in practice, I suspect ... "DANE worked, until the localhost resolver
failed and resolution failed over to the resolver on the machine next
door, across a network with anti-spoof rules at the ingress".
I don't see any way I'd be happy moving the rest of the validation logic
into the MTA. We let Unbound do what Unbound is good at, and trust it.
Exim works _with_ other systems and is already pretty damned large for a
security-sensitive component, without deciding we can't trust any other
part of the OS and its facilities and replicating them internally.
In fact, I'm going to go so far as to say "Hell no!" -- we won't be
smoking that crack.
-Phil
