Thanks for the comments! Comments inline. On Mon, Feb 20, 2017 at 9:16 PM, David Illsley <[email protected]> wrote:
> In general, the fact the a complete failure causes a policy update makes > this simple and safe. There are a couple of reasons why I think it's not > quite that easy: > 1. It's not desirable for a 'report' configuration to be used beyond the > point that a domain has switched to 'enforce', and a long-cached 'report' > policy could do this. > 2. It prevents new MX records (eg new servers for increased capacity or > backups) not covered by the cached policy from being used until the > max_age, or until a failure to send with all the covered servers. > Right. And in fact, per section 5.2, if a policy covers only some of the current MX records, a sender with that policy may continue to use that policy unless/until none of the allowed MX records are reachable or unless/until none of the MX records are valid under the policy. There is no *requirement* that a sender refresh the cached policy as long as it continues to work. So you've pointed out a somewhat subtle pitfall. If I deploy a policy with "mx: ['*.google.com']" and I later deploy additional MXs with higher priority on mail.google.*net *(and, because I'm smart, I remember to update my deployed policy), senders may nonetheless only send mail to the old *.com* MXs, resulting in an unexpected traffic imbalance. A few observations about this case: 1. I don't know that this is a serious issue; it depends heavily on how specific the "mx" pattern is versus turnover in MX hosts. As far as I recall we haven't changed our MX hosts as long as I've worked here... 2. This could be fixed if we said that senders MUST seek a new policy whenever some MXs are filtered out by policy application (5.2 step 2). 3. This is optionally fixed by senders refreshing cached policies at an arbitrary time, which they may (but need not) do. Since they can cheaply discover the presence of new policies (and may in fact lookup the magical TXT record prior to doing a cache-policy-check anyway, depending on implementation), this isn't really far-fetched--but we don't require them to do so. There is also a downside that if policies are cached for a long time, > misconfiguration of the policy server is less likely to be noticed quickly > as fewer domains will be sending reports indicating a failure. > That's also a good point, and it is unaddressed by my hypothetical MUST above (#2). > > Having pondered it a bit, my suggestion is: > 1. A SHOULD that max_age is set to at least 6 months, other than during > roll-out > 2. A SHOULD that well-behaved clients with a cached policy should re-check > DNS TXT policy weekly, and retrieve via HTTPS if the policy id has changed. > I think the phrasing you give here suggests that if I send mail to your domain less than once a week, I should run a cron job to refresh the cache--and I hate cron jobs. So to be slightly pedantic, would it work just as well to say senders SHOULD check for an updated policy *if* *using* a policy which is older than one week? (My phrasing may be unclear, but I mean, of course, that they need only check for an updated policy if they are otherwise sending mail to that domain anyway.) Of course, we could still simply suggest/require senders *always* check for a new policy--it's one more DNS lookup to the recursive resolver per-send--but I bet in some implementations there are good reasons not to do this. > An alternative to (2) would be to add an optional refresh_after field with > similar semantics which would have a default value of 7 days which could be > overridden if, for some reason there are concerns that weekly is too often > (but I'm generally of the opinion that fewer options are better). > Agreed, I think extra options here are just extra complexity. > > I hope that makes sense, and do let me know if I've missed something. > Cheers, > David > > > > On Wed, Feb 15, 2017 at 7:57 PM, Brotman, Alexander < > [email protected]> wrote: > >> Folks, >> >> We uploaded new revisions for MTA-STS and TLSRPT. There are minor >> changes to each: >> >> 1) Remove the "_" from DNS records to be consistent with A/AAAA records >> used with the HTTPS retrieval, and make this a bit less confusing for >> deployments. We did this for both MTA-STS and TLSRPT. >> 2) Clarify language around punycode >> >> Please give these a review and get back to us with any comments. Thank >> you. >> >> -- >> Alex Brotman >> Sr. Engineer, Anti-Abuse >> Comcast >> x5364 >> >> >> _______________________________________________ >> Uta mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/uta >> > > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
