Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

[John Levine <[e-mail]>]

In article <CAMSGcLCOUG_a13kwgU==HdpHG+ZpMO5caO2tXKqk3TH=[e-mail]> 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.