In article <CAMSGcLCOUG_a13kwgU==HdpHG+ZpMO5caO2tXKqk3TH=n7-...@mail.gmail.com> you write: >As another case, would people be surprised that email for the medical >center cumc.columbia.edu is a separate system managed by a separate IT >group from columbia.edu, and that any authentication for one should not be >applied to the other? I don't think this is unique in large decentralized >universities. The real email world is a complicated place.
Good point, and those aren't boundaries that the PSL et al will show. On the other hand, if you don't want your nominal parent organization stealing your reports, you can fix that by publishing your own dmarc record regardless of how we find the org domain. I asked in DNSOP about tree walks and my take on the response is that they are OK, perhaps with some advice about how to limit the effect of long malicious domain names. The CAA record has required a tree walk since 2013 and the sky hasn't fallen in. I guess if we're planning to consider a tree walk, it could make sense to put the org domain stuff in a separate rather short draft. By the way: >> engineering.sun.com >> oracle.com _dmarc.sun.com. CNAME _dmarc.oracle.com. Since nothing else is going to be at the _dmarc label, CNAMEs work fine for cross-tree references. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
