Re: [dmarc-ietf] Proposed text to close out Ticket 96

[Scott Kitterman <[e-mail]>]

My understanding is that the IETF doesn't do implementation specifications.  I'm not sure what problem that's related to interoperability this is meant to address.

I think the ticket should be closed without action 

If you really think we need this, I think the Enforcement definition needs something about the domains (and subdomain) at issue either aren't affected by the interoperability issues discussed in 5.5.6 or has accepted the associated interoperability risk.  It needs to be Barry's version of 5.5.6 that's the starting point for the new definitions (if we are going to have them at all, which I think we shouldn't).

Scott K

On April 5, 2023 9:34:51 PM UTC, Seth Blank <seth=[e-mail]> wrote:
>https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/96
>
>I tried to write up an INFORMATIONAL paragraph, for ticket #96, and it kept
>on coming out strangely and did not feel appropriate in the document as a
>section unto itself.
>
>However, I think we can meet the intent of this ticket by condensing it
>into two definitions for section 3.2, an added sentence to 5.5.4 and a new
>paragraph in 5.5.6 (that stands regardless of the output of the other
>thread in process on 5.5.6), as follows:
>
>3.2.
>
>Monitoring Mode: At p=none with a valid reporting address, the domain owner
>receives reports that showcase authorized and unauthorized mail streams, as
>well as gaps pertaining to authentication information pertaining to both
>streams.
>
>Enforcement: When the Organizational Domain and all subdomains below it are
>covered by a policy that is not none. This means that the domain and its
>subdomains can only be used to send mail that is properly authenticated,
>and mail using the domain name that is unauthenticated will not reach the
>inbox of a mail receiver that validates DMARC.
>
>5.5.4 OLD
>
>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 usually
>start with "p=none", (see Section 5.5.5) with the rua tag containing a URI
>that references the mailbox created in the previous step. If the
>Organizational Domain is different from the Author Domain, a record also
>needs to be published for the Organizational Domain.
>
>5.5.4 NEW
>
>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 usually
>start with "p=none", (see Section 5.5.5) with the rua tag containing a URI
>that references the mailbox created in the previous step. This is commonly
>referred to as putting the Author Domain into Monitoring Mode. If the
>Organizational Domain is different from the Author Domain, a record also
>needs to be published for the Organizational Domain.
>
>5.5.6 OLD
>
>Once the Domain Owner is satisfied that it is properly authenticating all
>of its mail, then it is time to decide if it is appropriate to change the
>p= value in its DMARC record to p=quarantine or p=reject. Depending on its
>cadence for sending mail, it may take many months of consuming DMARC
>aggregate reports before a Domain Owner reaches the point where it is sure
>that it is properly authenticating all of its mail, and the decision on
>which p= value to use will depend on its needs.
>
>5.5.6 NEW
>
>Once the Domain Owner is satisfied that it is properly authenticating all
>of its mail, then it is time to decide if it is appropriate to change the
>p= value in its DMARC record to p=quarantine or p=reject. Depending on its
>cadence for sending mail, it may take many months of consuming DMARC
>aggregate reports before a Domain Owner reaches the point where it is sure
>that it is properly authenticating all of its mail, and the decision on
>which p= value to use will depend on its needs.
>
>Some Domain Owners may wish to ensure a policy exists for the
>Organizational Domain and all its subdomains, which is known as the
>Organizational Domain being at Enforcement. This prevents the entire
>Organizational domain's hierarchy from exact-domain spoofing. This is
>difficult for many Domain Owners to achieve, as they must repeat the above
>process to ensure mail is properly authenticated for each subdomain. Being
>at Enforcement means an Organizational Domain has no recourse if Mediators
>modify authentication information as outlined in section 8.5.
>