> On May 6, 2018, at 3:44 PM, Daniel Margolis <d...@af0.net> 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!
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
