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

In article <903acb7d-847e-c87c-f21b-dcfa698bf...@wisc.edu> you write: >You can't think of universities as single entities with central management >authority. For the longest time our CS department owned >wisc.edu and central IT had to ask them for permission to use it for >campus-wide email. I

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

I beleive that we can and should address the Columbia University problem. Here are some thoughts: Policy Types =--- We have three types of policies: - "p=" policy for a specific domain - "sp=" policy for subdomains that do not enumerate their own - "sp=" policy for non-existent

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

On 11/13/2020 9:09 AM, Jesse Thompson wrote: You can't think of universities as single entities with central management authority. For the longest time our CS department owned wisc.edu and central IT had to ask them for permission to use it for campus-wide email. This highlights that the

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

On 11/13/20 9:03 AM, dotz...@gmail.com wrote: > > > On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan > wrote: > > > > As another case, would people be surprised that email for the > medical center cumc.columbia.edu is a

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

On 11/13/2020 6:46 AM, Joseph Brennan wrote: The simple solution is for cumc.columbia.edu to publish its own record. Done. Michael Hammer I don't think I have the right to force the owner of another domain to publish dmarc. The owner of the other domain

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

On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan wrote: > > >>> 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

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

> >> 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 >>

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

On 11/12/2020 6:12 PM, Dotzero wrote: engineering.sun.com people would be surprised that the organization domain is oracle.com This just isn't that interesting. I would expect (hope?) that Oracle has enough of a clue

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

On Thu, Nov 12, 2020 at 9:24 AM Joseph Brennan wrote: > > > On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker wrote: > >> >> Just to invoke a bit of ancient history, here, you are saying that if >> there was the domain name: >> >> engineering.sun.com >> >> people would be surprised that the

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

On Thu 12/Nov/2020 10:40:17 +0100 Alessandro Vesely wrote: On Wed 11/Nov/2020 18:38:41 +0100 Dave Crocker wrote: On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote: The proposal is, I think, to change the main document to leave a pointer, and the pointer can be changed much more easily than the

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

On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote: So the new DMARC document would say: "Determine the Organizational Domain. The legacy way to do this can be found in [other-RFC], but other better methods are anticipated." Then when something better than PSL (maybe a tree walk, maybe

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

Hi, Le 11/11/2020 à 22:33, Seth Blank a écrit : > > To the earlier conversation, this is all simplified dramatically if we > define organizational domain (or whatever it's renamed) discovery in a > separate I-D that DMARC just inherits... Let me point out, though, that sending reports to

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

On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker wrote: > > Just to invoke a bit of ancient history, here, you are saying that if > there was the domain name: > > engineering.sun.com > > people would be surprised that the organization domain is > > oracle.com > > As another case, would

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

On Wed 11/Nov/2020 18:38:41 +0100 Dave Crocker wrote: On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote: The proposal is, I think, to change the main document to leave a pointer, and the pointer can be changed much more easily than the actual method.  So the new DMARC document would say:

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

It appears that these tickets are all related to this issue: #24 objection to maintaining registry for all participating public suffixes #34 Define the term "Public Suffix" referencing RFC8499 #46 Separate org domain definition from core DMARC #58 Add third

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

This use case is actually the intention of (the extremely poorly worded) https://trac.ietf.org/trac/dmarc/ticket/59 To the earlier conversation, this is all simplified dramatically if we define organizational domain (or whatever it's renamed) discovery in a separate I-D that DMARC just

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

On Wed, 11 Nov 2020, Dave Crocker wrote: Just to invoke a bit of ancient history, here, you are saying that if there was the domain name: engineering.sun.com people would be surprised that the organization domain is oracle.com In a DMARC context, that would be quite surprising. I am

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

On 11/11/2020 11:24 AM, John R Levine wrote: DMARC has had a consistent construct, which is 'the domain name that is at the top of the organization's administrative hierarchy".  Hence, Organizational Domain.  Nothing in the term requires that it be up the 'current' domain name chain. I think

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

On 11/11/2020 8:50 AM, John R Levine wrote: The current text says (in many more words), take a list of public suffixes, ... If you mean that we would punt a potential change this large into a different document, that seems like a stretch. It's not. The entire topic is a mess. In

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

I believe the core of this is referenced in https://trac.ietf.org/trac/dmarc/ticket/68 and can be discussed in detail when the chairs or relevant editors open that ticket. The further discussion seems to be if "org domain" (or whatever new name its given) definition and discovery mechanism should

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

On 11/11/2020 10:18 AM, John Levine wrote: "Parent default" or something like that. There's no claim that it is or isn't in the same organization, just that it's a parent name of the target name. For Scott's _dmarc.BANK. thing it would deliberately*not* be the same organization. Where is

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

In article <03758d8d-a4d7-3f9d-bc0c-3ee404fc5...@dcrocker.net> you write: >On 11/11/2020 8:58 AM, John R Levine wrote: >> Except that if we do a tree walk, I don't think we'd call that the >> Organizational Domain any more. > >What would you call it? "Parent default" or something like that.

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

On 11/11/2020 8:58 AM, John R Levine wrote: Except that if we do a tree walk, I don't think we'd call that the Organizational Domain any more. What would you call it? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list

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

On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote: The proposal is, I think, to change the main document to leave a pointer, and the pointer can be changed much more easily than the actual method.  So the new DMARC document would say: "Determine the Organizational Domain.  The legacy way to do

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

On Wed, Nov 11, 2020 at 8:52 AM John R Levine wrote: > The current text says (in many more words), take a list of public > suffixes, find the longest match, and the Org domain is one below that > match. If we consider the Org domain to be found via a list of public > registration points, that

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

On Wed, 11 Nov 2020, Dave Crocker wrote: So, DMARC should punt the entire topic. It should have some text, along the lines of: Find the Organizational Domain. The means of finding the Organizational Domain are outside the scope of this specification. Except that if we do a tree walk, I

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

On 11/11/2020 8:50 AM, John R Levine wrote: The current text says (in many more words), take a list of public suffixes, ... If you mean that we would punt a potential change this large into a different document, that seems like a stretch. It's not. The entire topic is a mess. In

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

On Wed, 11 Nov 2020, Dave Crocker wrote: There is a difference between "splitting out existing text, on topic x" from "revise text on topic x". The current suggestion is to take the org domain text that is current in the DMARC spec and to split it out, so that the core DMARC spec does not