Re: [dmarc-ietf] 5.5.4. Publish a DMARC Policy for the Author Domain - dmarcbis-06

[Scott Kitterman <[e-mail]>]

On Tuesday, March 22, 2022 11:16:13 AM EDT Scott Kitterman wrote:
> On Tuesday, March 22, 2022 5:54:33 AM EDT Alessandro Vesely wrote:
> > I think we need something like the following.
> > 
> > On Mon 21/Mar/2022 21:50:42 +0100 internet-drafts wrote:
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
> > 
> > OLD
> > 5.5.4.  Publish a DMARC Policy for the Author Domain
> > 
> >     Once SPF, DKIM, and the aggregate reports mailbox are all in place,
> >     it's time to publish a DMARC record.  For best results, Domain Owners
> >     SHOULD start with "p=none", with the rua tag containg a URI that
> >     references the mailbox created in the previous step.
> > 
> > NEW (add or replace)
> > 5.5.4.  Publish a DMARC record for the Author Domain
> > 
> >     A DMARC record MUST be defined at the Organizational Domain, that is
> >     the
> > 
> > shortest domain that belongs to the organization, see Section 3.2.7.  This
> > domain determines the alignment of the identifiers.  The domain part of
> > the
> > aggregate reports mailbox also needs to be aligned, otherwise an
> > additional
> > DMARC record for external destination verification has to be defined.  If
> > any subdomain of the organization is used as an Author Domain, a DMARC
> > record for that subdomain MAY be defined.  For example, the subdomain may
> > want a different policy or different reporting mailboxes.
> > 
> >     If a subdomain is independent from the organization, that is if the
> >     organization delegated control of the subdomain to another
> >     organization,
> > 
> > then the former organization is a PSO.  In that case, it is necessary to
> > use the psd flag to break alignment, so that an organization cannot
> > impersonate another one.
> > 
> > 
> > Is that obscure enough?
> 
> I think we need something here.  I agree with your core point that
> Organizational Domain has to have a DMARC record and we should say that.  I
> would spend the words on more PSO description here.  Almost no one is a PSO
> and we shouldn't over emphasize it.
> 
> I need to take another turn on the words I've been working on based on other
> comments.  I'll include something along these lines in that update and then
> you can see what you think.

Somewhat later than I had hoped, I've taken a shot at this.  Please see the 
attached proposed update from dmarcbis-06 and rfcdiff.

I suggest several changes here:

1.  In the tree walk description, update the step descriptions so that the 
entire tree walk is performed if needed.  Just because we find a DMARC record, 
we can't necessarily stop.

2.  In the policy discovery section I added a few sentences on which policy to 
use once the policy record is identified.  This doesn't change anything 
relative to what's currently defined, but it seems to me that if we are going 
to have a discussion of policy discovery we should take it all the way to 
determining the poilcy and not stop at the determination of the record to use 
to determine the policy.

3.  Added 'u' as the default for the psd= tag.  I believe I've captured the 
discussion from the working group on this.  If I didn't, I did not 
intentionally innovate.

4.  As discussed above, made it explicit that the Organizational Domain needs 
to have a DMARC record.

Scott K