> On Aug 31, 2016, at 10:00 AM, Daniel Margolis <[email protected]> wrote:
>
>> My suggestion would be that non-matching MX hosts and any MX hosts with a
>> worse (higher) MX preference
>> be removed from the MX RRset, leaving only matching hosts at an equal or
>> better (lower) preference. Mail
>> delivery can proceed only if that set is non-empty. If a first matching MX
>> host fails authentication, then
>> a second matching MX host is tried, ... until one passes, all are tried, or
>> some sender limit on the number
>> of MX hosts to try is reached. Mail is deferred if none of the attempted MX
>> hosts pass authentication.
>
> Not to be stupid, but why eliminate hosts with a higher preference than the
> matching MX? It seems like they would still be valid candidate MXes in the
> failure case.
Perhaps I was not sufficiently clear, I was suggesting removal
of MX hosts at a worse preference than any non-matching host.
On second thought it would be sufficient for hosts (as usual)
to first eliminate all MX entries at an equal or worse preference
to any entry that matches themselves (by name or address), and
only then check which (remaining) MX host comply with STS policy.
The goal is to ensure that no loops result if an MX host applies
the STS filter first, and fails to remove other hosts at an equal
or worse priority.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
