Subject: Re: [dmarc-ietf] Organizational Domain

From: Alessandro Vesely <[email-masked]>
Date: Tue, 1 Feb 2022 11:07:53 +0100

On Tue 01/Feb/2022 00:01:33 +0100 Dotzero wrote:
> On Mon, Jan 31, 2022 at 3:51 PM Alessandro Vesely <[email-masked]> wrote:
> 
>> (This message is not going to be accepted by the IETF today, so I CC John too)
> 
> Why wouldn't your email be accepted?

I messed around with the DNS and reverse IP wasn't resolving —thanks for asking.

>> On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote:
>>>>> 3. The role of the function that uses the PSD and the role of the
>>>>> function that does a tree walk are identical.  Since you apparently feel
>>>>> otherwise, please explain.
>>>>
>>>> A PSD is potentially useful for DMARC policy determination if no policy exists
>>>> for the exact domain or the organizational domain.  It is not useful for
>>>> evaluating relaxed alignment.  Only the organizational domain can be used for
>>>> that.  So I do not think you are correct.
>>>
>>> The RFC  9091 does not contain the word 'relaxed', so I'm curious about the
>>> basis for your assertion of the limitation.
>>
>> Let me ask if the following scenario is possible at all:
>>
>> .BANK admins decide to setup a DKIM signing service for .bank domains.
>> They register dkim.bank, and accept and relay messages originating from
>> their customers, signing them with d=dkim.bank.  (Compare to
>> onmicrosoft.com?) >>
>> They may consider that a tangible way to protect .bank domains.
>>
>> Will that work to validate, say, mail From: [email-masked]?
>
> Let's be realistic, any organization providing a DKIM signing service (but
> why would banks divert their mail flows to go through such a service?) can
> easily sign in an aligned manner for any unique domain. I did this for
> multiple domains (about 6,000) with different mail systems at various times
> (Ironport, Message Systems, etc). If such a service or system couldn't sign
> for unique domains on the fly, it shouldn't be used.

Perhaps it could be a marketing hint, to demarcate (or do you say demark?) all 
mail from .bank.  I don't think it is a good idea, as it would conflate all 
those banks with one another.  I asked the question to see more clearly where 
the WG stands about ORG vs. PSD differences.  As a conclusion, it seems that 
nobody here thinks PSDs can be used for alignment.

To avoid BEC attacks, it is necessary to distinguish PSDs from ORGs.  If there 
are organizations that lease/rent or otherwise provide subdomains as part of 
their commercial offerings, they should be categorized as PSDs.  This is the 
duty that the PSL has been involved in.  Relaying on psd=, a tree walk can work 
without the PSL if we assume that all PSDs duly set that flag, which is not 
going to happen.

> The reality is that people are trying to jump through all kinds of hoops in
> support of a bad idea.

For onmicrosoft.com, it looks as if they believe that the value of a DKIM 
signature can be recognized even without referring to DMARC.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Feb 2022 12:21:22 -0800

Barry,

Your note underscored the lack of interest in engaging in discussion of 
the original substance to my posting.  So I will of course drop further 
attempts at improving the working group's documentation effort.

However your note also underscored a basic misunderstanding in rules, 
process, and professional conduct.  I think that the working group 
archive needs to include a counter, lest the casual reader think that 
you note was a constructive exercise in authority.

On 1/31/2022 10:15 AM, Barry Leiba wrote:
>> 2. Your 'for the sake of' is uncalled for and dismissive.  Please stop
>> doing that.  Attempts to be dismissive are a popular debating
>> technique in the IETF, but they are counter-productive, as well as
>> unprofessional.
> Two things here:
> First, please do not admonish participants for their behaviour: that's
> for the chairs to do, and you should feel free to call things out to
> us privately.  It's too easy for discussions to degenerate when we
> move them away from the technical arguments.

First, there is no rule requiring that someone, who is being mistreated 
publicly, is prohibited from responding publicly.

Nor should there be.

The IETF has a long track record of handling mistreatment slowly and 
poorly, or not at all.  The current case is merely one more example.

Over time, the more grotesque examples of mistreatment have reduced, 
though they have far from disappeared.  What has remained is permission 
to ignore the substance of what is said, to dismiss it out of hand, or 
to misrepresent it cavalierly.

This leaves IETF discussion groups as distinctly friendly to markedly 
unprofessional conduct.  The best that can be said about changes over 
time is that conduct has generally moved from gross, direct, personal 
attacks, to passive aggressive attacks.

In practical terms this leaves the target of the misbehavior on their own.

> Second, the chairs don't find Scott's comment to be at all dismissive,
> as the "for the sake of" sentence needs to be taken in the context of
> the subsequent sentence that explains that Scott doesn't think you've
> given a suitable rationale for the proposed change.

Taking his subsequent sentence is pretty much irrelevant.  It does not 
establish context, since the real context is established by the note he 
was responding to, which you do not cite.

It is one thing to disagree with the the reasons I offered in that 
original note, but quite another to pretend none were provided.

Casting his characterization of my proposal as 'uncalled for and 
dismissive' was precise, accurate and, frankly, restrained. It simply is 
not professional to treat a participant disrespectfully like he did.  A 
view that it is not disrespectful, again, underscores the systemic 
problem here.  It creates a hostile work environment that discourages 
others from participating.

It's also striking that my opinion of 'uncalled for and dismissive' is 
of more concern to you than his misrepresentation of fact.

> Rather, you are demanding justifications such as hard data to support
> opinions... the sort of hard data that you, yourself are not providing
> to support your own opinions.  We see *that* as being dismissive and
> unhelpful in progressing the discussion.

Since you offer no specific examples, I'm left to guess what you are 
referring to.  Tsk.

Perhaps you meant my asking Levine to explain his tautology that a PSD 
can't be an Organizational Domain?

Perhaps you meant my taking exception to the circular logic Kitterman used?

Perhaps it is my asking for detail, where broad assertions are made?

But, again, I really don't know what 'hard data' I might have provided, 
but didn't, nor what hard data I was 'demanding'.  I suppose it would be 
indelicate to 'demand' that you provide hard data of my 
unreasonableness.  So, I won't.

>> 1. For this topic, they are irrelevant. There is nothing in the
>> charter that says terminology must be preserved.  Interoperability is
>> not endangered by changes in terminology.
> My opinion is that interoperability might well be endangered by
> changes in terminology, if it results in older and newer
> implementations differing in how they handle things based on those
> differences in terminology.  To the point at hand, though, that
> opinion seems to be what Scott and John are also raising, and which
> you are dismissing.

Sure.  And while you clearly intended that paragraph to be relevant, it 
isn't.  Remember your interest in context?  You ignored that here.  Too.

First my language was not nearly as generic as you imply.

Second, the premise is that the term "Organizational Domain" is 
inextricably tied to a fine-grained technical definition, and that it 
has such deeply ingrained, established use, as to be dangerous to 
modify.  Except that premise is an assumption, not a demonstrated fact. 
It's not that the basic concern is unreasonable.  It's that the flat 
assertion of serious danger is unfounded.

And they nicely ignored my attempts to distinguish the role of the term 
in DMARC, from the algorithmic details (that they are in the process of 
changing.)  That is, the what from the how.  As you have also done.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]