Kurt, Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC > spec itself): > 2. (from 3.2 step 3) "search the PSL for the name that matches the > largest number of labels found in the subject DNS domain. Let that number > be "x". / (step 4) Construct a new DNS domain name using the name matched > form the PSL and prefixing to it the "x+1"th label"...[this] is the org > domain. > 3. Check the name created from the "x" labels determined in step 2 (hence > my designation as "org-1"). > These are not the same as "longest" and "shortest" names from the org > domain candidate set unless the psl code follows that specified > construction algorithm.
Ah, I misunderstood the proposal. I viewed your '-1' as subtracting an index against the PSL set, not subtracting an actual label from the organizational domain. I'm also a little confused by terminology - "org-1" above is just the largest number of labels entry on the PSL, isn't it? In that case, yes it would address point #3, but would also potentially introduce problems for the county code TLDs (does a country-level registrar have the right to dictate policy for all domains in the country?) and some of the non-sponsored generics (.com, .edu, .org, etc.) The cardinality is still a potential issue, because you may want the DMARC management to devolve to the most general authority in the tree. But as I said, it's easy enough to state "DMARC doesn't handle that case" if it's not an effective abuse vector or a significant management problem. Best, Peter On Thu, Apr 5, 2018 at 8:19 AM, Kurt Andersen (b) <[email protected]> wrote: > On Thu, Apr 5, 2018 at 7:22 AM, Peter M. Goldstein < > [email protected]> wrote: > >> Hi, >> >> These are both a species of the same problem, yes. The solution so >>> far has been to say that you're supposed to match the longest of the >>> candidate set... >> >> >> Right. And the suggestion that Kurt made was to modify this to: >> >> 1. Check the domain itself >> 2. Check the longest of the organizational domain candidate set >> 3. Check the shortest of the organizational domain candidate set >> > > Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC > spec itself): > > 2. (from 3.2 step 3) "search the PSL for the name that matches the > largest number of labels found in the subject DNS domain. Let that number > be "x". / (step 4) Construct a new DNS domain name using the name matched > form the PSL and prefixing to it the "x+1"th label"...[this] is the org > domain. > > 3. Check the name created from the "x" labels determined in step 2 (hence > my designation as "org-1"). > > These are not the same as "longest" and "shortest" names from the org > domain candidate set unless the psl code follows that specified > construction algorithm. > > Which covers the case where that candidate set has cardinality 2 or less, >> but leaves some question about cases where the cardinality is 3 or more. I >> don't know how common the latter is - not sure if we have stats on that. >> > > I still don't know why the cardinality matters with the approach I've > proposed. > > Do you mean this _across_ TLDs (e.g. the "variants" case such as >>> differnet spellings of China depending on the writing system) or do >>> you just mean that the top most label and everything flowing down from >>> there is all under the same policy? >> >> >> The latter. >> >> To be more clear, there are now a significant number of TLDs that are >> managed exclusively by one entity (e.g. .microsoft, .google) as well as >> other TLDs that make specific guarantees around DMARC (e.g. .bank). In >> those cases it may make sense to give the registry owners some defined >> mechanism for imposing global DMARC policy across the TLD. This is >> especially important for organizational domain names that don't resolve for >> that TLD. >> >> So, for example, let's consider an email seemingly sent from >> [email protected] . A query to the domain iamareal.bank returns an >> NXDOMAIN, as does the a TXT query to the corresponding DMARC record >> _dmarc.iamareal.bank domain. So there's no DMARC policy in place. So a >> receiver may wind up delivering this email to the inbox, especially if it >> passes SPF and DKIM in an unaligned fashion. >> > > If .bank, i.e. "1", is the largest number of labels found in the PSL (step > 2), why would this approach not protect NXDOMAINs under .bank? > > --Kurt > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
