On Thu, Nov 19, 2020 at 7:39 AM Alessandro Vesely <[email protected]> wrote:
> On 18/11/2020 22:33, John R Levine wrote: > >> On 11/18/2020 12:44 PM, John Levine wrote: > >>> so I encourage the group to limit the debate to the existing Org/PSL > >>> kludge and a tree walk. > >> > >> "and a tree walk" is not a minor 'and'. neither conceptually nor > >> operationally. assurances to the contrary notwithstanding. > > > > I didn't say they were equivalent. But I do think they are the only > options > > that are likely to get much interest from the WG. > > > I don't think tree walk is a viable option, as it distorts semantics. > > Forgive me, but I don't know what you mean by the phrase "distorts semantics"; can you please help me understand? As for the viability of a tree walk, it is possible in complex environments to have something resembling the following: - RFC5322.From domain - a.b.foo.com - _dmarc.a.b.foo.com non-existent - _dmarc.b.foo.com record exists, p=x, rua=r1 - _dmarc.foo.com record exists, p=y, rua=r2 (The actual p= and rua= values for these two records are of no consequence; in this example it is only required that they differ from each other.) Let's put aside whether or not such a configuration is the ideal way to do things, because that's outside the scope of the working group; let's acknowledge that the "Holy Roman Empire" method of management of DNS and email does exist, and so centralized control of DNS across all organizations is just not possible. With the current DMARC specification, the receiver actions for policy discovery would look first for a policy record at a.b.foo.com, and finding none, would then look at the organizational domain, foo.com. This would result in a policy of y being applied to mail from a.b.foo.com, and aggregate reports going to r2. Perhaps the people in charge of DNS and email for a.b.foo.com intended for this to happen; we can't know their intentions without speaking directly with them (which obviously doesn't scale) but this is what the configuration would yield. On the other hand, one might infer from the DNS records that are published that their intent was for a.b.foo.com to inherit x for the policy and r1 as the destination for aggregate reports from the b.foo.com record; this would be an error on their part, because DMARC does not currently support discovery of the record at _dmarc.b.foo.com in this case. However, it's not hard to see that this might be what they intended, especially if the published policy here is p=none; they may be in the "audit" phase of their DMARC rollout for their portion of foo.com's namespace, wanting reports sent to a mailbox under their local control, so that they can effect change quickly to their mailstreams. The way I see it, we can choose one of three paths here: 1. Keep things as they are, where if there is no policy published for RFC5322.From, the policy is inherited from the org domain, if a policy is published there 2. Change the spec so that the only policy lookup done is for the RFC5322.From domain, and if there's no policy there, then DMARC doesn't exist for that domain 3. Change the spec so that policies published between the RFC5322.From domain and the organizational domain can be discovered, in order to support the most flexibility across organizations. Option 2 would cause the most pain for the current install base of domain owners that publish DMARC policies, because even those who understand DMARC will have to update DNS for domains below the org domain that are used in RFC5322.From headers. Meanwhile, options 2 and 3 would both require code changes for domains that do DMARC validation. The larger point, though, is that there are plausible scenarios that argue for supporting the ability to publish policies somewhere in the DNS hierarchy between the RFC5322.From domain and the organizational domain. -- *Todd Herr* | Sr. Technical Program Manager *e:* [email protected] *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
