On 19/11/2020 21:33, Todd Herr wrote:
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?
The current semantics considers an Organizational Domain to be the expression
of the organization itself, the organization's master domain. That's quite
nearly what the PSL strive for.
Tree walk, instead, discards any organizational boundary.
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
- _dmarc.com record doesn't exist, for the time being.
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.
Without asking them directly, we could also infer that folks at b.foo.com are
sneakily trying to divert feedback traffic.
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
Easiest and safest option.
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
SPF experience shows that large domains don't have the ability to maintain a
script that defines suitable DNS records for all their subdomains. This would
force inconsistent usage of '*' domains. BTW, as of your example, we have:
ale@pcale:~$ dig _dmarc.b.foo.com txt
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> _dmarc.b.foo.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44418
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ab33c1fc9c9860b18b1294575fb788126f7a88216eadcab7 (good)
;; QUESTION SECTION:
;_dmarc.b.foo.com. IN TXT
;; ANSWER SECTION:
_dmarc.b.foo.com. 600 IN TXT "v=spf1 -all"
;; AUTHORITY SECTION:
foo.com. 250 IN NS ns2.digimedia.com.
foo.com. 250 IN NS ns1.digimedia.com.
;; ADDITIONAL SECTION:
ns1.digimedia.com. 172450 IN A 23.21.242.88
ns2.digimedia.com. 172450 IN A 23.21.243.119
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.
Besides making a lot of confusion about where policies and feedback addresses
might come from, this feature inflates DNS queries more than it is desirable.
If you have From: DoS <[email protected]. ... x.y.z> you have to look up each
subdomain in the required order. (Maybe you can check if z exists, and in case
if m.n.o. ... x.y.z exists, and so on in a dichotomic anti-DoS tactic. Hm...)
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
