Re: [dmarc-ietf] Next draft concerns

Doug,

I believe I have asked you before to provide specific examples of current domains with records that will cause a problem if assessed via the DMARCbis approach.  If there's a real problem that needs solving, then surely there are examples of it.  If they're none, then how about moving on.

I think you're misreading the thread.

Let's have an example of a real domain, with a  real DMARC record, that would be negatively impacted by being assessed using the DMARCbis design. I haven't found any I think are problematic, but if you have, I'm all ears?

Scott K

On June 12, 2022 8:08:13 PM UTC, Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
>Les' question has returned us to the problem of justifying the tree walk.
> We need to document the problems with PSL, but we also need to demonstrate
>that the tree walk solves those problems without creating others.
>
>In most cases, the tree walk and PSL will produce the same results, because
>they will both find the top-most DMARC policy in a structure with neither a
>private registrar nor a PSD policy.   So the justification is really
>limited to those exceptions.
>
>We assume that most PSL errors will cause organization fragmentation,
>because of identifying a private registry for XSS purposes which is not a
>private registry for email purposes.    We also know that the current DNS
>has no information about private registries, so if we apply the tree walk
>to the current DNS, we may sometimes error by landing too high and causing
>inappropriate organization consolidations.
>
>In the case that the tree walk stops lower than the PSL target, the most
>secure solution is to believe the DNS policy.   This can only occur if the
>policy has a DMARCbis token which explicitly says that a policy has the
>Organizational Domain role.
>
>In the case that the tree walk stops higher than the PSL target, which do
>we believe?    To tilt the decision in favor of the tree walk, we need a
>token which indicates that the tree walk did not pass over an undocumented
>private registry.   This will also require a new token on the
>organizational domain, which is not yet defined.   I see these possible
>informational signals:
>- No private registries or organizational boundaries underneath this
>organizational domain.
>- All sub-organizations underneath this organizational domain are also
>documented with organizational domain DMARC policies.
>- A private registry exists underneath this organizational domain and is
>documented with a PSD policy.
>
>This means that for either exception, a new DMARCbis token is required on
>the organizational domain.   Consequently, a domain which has not published
>an applicable DMARCbis token should be evaluated using the PSL, and a
>domain which has published a sufficient set of DMARCbis tokens should be
>evaluated using the Tree Walk.   This approach also satisfies our other
>requirement, which is that the tree walk requires an organizational domain
>policy.
>
>I know this is discouraging, because John's original hope was to avoid
>placing a change requirement on domain owners, but I do not see that it can
>be helped.
>
>Doug Foster
>
>
>On Thu, Jun 9, 2022 at 3:18 PM Les Barstow <lbarstow=
>40proofpoint.com@dmarc.ietf.org> wrote:
>
>> Thank you for the history fill-in, John. That does at least explain why
>> we’re here and not somewhere else.
>>
>>
>>
>> I will respectfully disagree that the “psd” tree walk standard is
>> well-defined based on the remainder of my response – that the use of the
>> “psd” TLA for the tag is unfortunate/misleading and that more specificity
>> is desirable. But having the alternatives eliminated at least gets me to
>> “it should be in this spec”.
>>
>>
>>
>> On Thursday, June 9, 2022, John Levine wrote:
>>
>>
>>
>> It appears that Les Barstow  <lbarstow@proofpoint.com> said:
>>
>> >-=-=-=-=-=-
>>
>> >[Strong opinion follows]
>>
>> >
>>
>> >IMO [from April], determination of a DMARC authority boundary (registrar, PSD+1, private registry (+1), or internal subdomain
>>
>> >boundary) should really be done outside of the DMARC standard altogether – a separate DNS lookup not dependent or centered
>>
>> >around DMARC, and one flexible enough to respond with indications of various levels of authority. It is useful for
>>
>> >decentralizing other queries beyond just DMARC (e.g. determining an appropriate WHOIS TLD for lookup). Unfortunately, here we
>>
>> >are at draft 8 of the new DMARC standard and we have nothing to use as a sidecar mechanism.
>>
>>
>>
>> The DBOUND working group already tried and failed to come up with a
>>
>> general way to publish DNS boundaries, so we're not going back there.
>>
>>
>>
>> >Is there a driving need to have this in the standard NOW?
>>
>>
>>
>> Yes, of course. The point of writing a standard is to tell people what
>>
>> to do to interoperate. The current underspecified fudge which winks at
>>
>> the PSL has well known issues since, among other things, the people
>>
>> who run the PSL have made it quite clear that it's not designed to
>>
>> make DMARC work. It contains plenty of entries which make sense for
>>
>> web cookies but not for DMARC.
>>
>>
>>
>> The tree walk is well specified and doesn't depend on third parties
>>
>> who aren't interested in what we want or need.
>>
>>
>>
>> R's,
>>
>> John
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>