> On May 6, 2018, at 12:55 PM, Daniel Margolis <[email protected]> wrote:
>
> 2. Why is the "mx" pattern matched against the SANs and not the MX records
> themselves? As Viktor noted and I commented briefly in passing, we debated
> this a *lot* before. One point here is that this is only visible to MTA
> implementors; sysadmins who mistakenly believe the "mx" field should match
> the DNS records (which should themselves match the servers' certificates)
> will end up making their configurations valid per the actual specification.
> In other words, "match the policy against the SAN" matches a superset of
> conditions which are valid in the alternative ("match the policy against the
> MX records and match those records against the certificate"). Personally I
> would consider this edit to have been a compromise--it was not and is still
> not my first choice--but, given it is the status quo, I am fairly loath to
> change it.
>
> On these points--especially #2--I continue to defer to the guidance of the
> chairs on how best to resolve such issues.
After having to revisit this in response to the DISCUSS, I can
crystalize the issue in terms of the following dichotomy:
* Does MTA-STS secure the connections to the endpoints indicated
by a domain's MX RRset, without preempting MX-based SMTP routing?
or
* Does MTA-STS secure the MX RRset, possibly filtering it to at
at most a set of names cached in the policy, with great care
to first take care of loop elimination.
My sense is that the first option (current text) is a less invasive
change in SMTP, it changes only how the peer is authenticated.
For example, it "testing" mode, one probably SHOULD NOT trim the MX
RRset based on a "testing" policy. Or one might support multiple
authentication mechanisms for the peer MX (say key fingerprint as
a fallback of MTA-STS fails).
There are more implications to filtering the RRset then just
the presented-id matching...
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
