> On May 6, 2018, at 5:20 PM, Viktor Dukhovni <[email protected]> wrote:
>
>> I don't believe that pre-filtering the MX candidate list is the only way to
>> do it. You could leave the loop as-is and just refuse to connect to (i.e.
>> treat as a transient connection failure) any candidate which fails the
>> policy validation. So this is an implementation question; modifying loop
>> pre-filtering is probably riskier than what we might call "connection early
>> termination", but both are compliant with the protocol.
>
> It makes a difference with a "testing" policy. Should mail be sent via
> an MX host not listed in the policy, or should it be skipped? With
> "testing" the mail should probably go out, with a report of the authentication
> failure (impossible success given unexpected MX name) sent per any "tlsrpt"
> policy.
>
> So at least "testing" should probably use all the MX hosts. Whether "enforce"
> does or does not is then a question of whether doing it differently for the
> two cases is a potential source of confusion/bugs, and prominent anti-loop
> warnings.
>
> There are even some domains where connecting to the backup MX host *before*
> trying a connection to the primary will cause firewall rules to be dynamically
> added to block the client!
And yet, of course, we could essentially in all cases go through the motions
of considering *every* MX host, and even connect to each X host in turn as
needed, but still authenticate the peer based on a match between the
certificate and the MX hostname, with the additional constraint that the
MX hostname match the policy "mx" list.
* In "testing" mode one would still actually connect even to MX hosts
whose names don't match the cached policy.
* In "enforce" mode, one could at the last moment optimize-out connections
to hosts which are sure to fail authentication, because the MX hostname
does not match the "mx" list. This of course after loop eiimination, etc.
I think that's the point that Daniel was trying to make...
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
