On Fri 09/Nov/2018 02:05:04 +0100 Scott Kitterman wrote: > On November 8, 2018 6:19:38 PM UTC, "Murray S. Kucherawy" wrote: >> On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely wrote: >>> >>> This problem is simpler than DBOUND. >>> >> >> Sure, the DMARC case is half of what DBOUND tried to tackle. If DBOUND >> had focused just on the DMARC use case, it would've succeeded. "Half of DBOUND" is exact. Apparently, DBOUND tried to simultaneously solve both the concept of Organizational domain (which is also related to reputation, responsibility, and possibly liability) and the concept of establishing a default, easily overridden policy. We only need the latter half.
>> [...] > > DBOUND was set up to provide, among other things, a specific input that > DMARC needs. The failure of that working group left DMARC with a hole in > its design. Operators use the Mozilla PSL as an ad hoc mechanism to fill > that hole. By its very nature, PSL defines Organizational domains —the first half. If you can exchange session cookies, you share liability. We don't need to define a topology in the DNS. We only need a default policy, established by the parent domain. Top level TXT RRs can allow some TLD's own semantics. DMARC policies also feature reporting addresses. They are quite different from, say, the point of contact (POC) linked to IP address space allocations, but let's note the concept of assigning some responsibility to the entity owning the first allocation. So, again, what's wrong with, for example: _dmarc.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"; eh? Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
