Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

["Brotman, Alex" <[e-mail]>]

There may need to be a bit more clarification around the use of sp= in these cases.  "We are telling you that p=reject is harmful, but sp=q/r is acceptable in many cases, where these conditions are satisfied".



--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: dmarc <[e-mail]> On Behalf Of Scott Kitterman
> Sent: Tuesday, March 28, 2023 4:01 PM
> To: [e-mail]
> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
> 
> On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote:
> > On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman <[e-mail]>
> >
> > wrote:
> > > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
> > > > NEW
> > > >
> > > >    5.5.6.  Decide If and When to Update DMARC Policy
> > > >
> > > >    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.
> > > >
> > > >    It is important to understand that many domains may never use
> > > >    policies of “quarantine” or “reject”, and that these policies are
> > > >    intended not as goals, but as policies available for use when they
> > > >    are appropriate.  In particular, “reject” is not intended for
> > > >    deployment in domains with users who send routine email, and its
> > > >    deployment in such domains can disrupt indirect mail flows and cause
> > > >    damage to operation of mailing lists and other forwarding services.
> > > >    This is discussed in [RFC7960] and in Section 5.8, below.  The
> > > >    “reject” policy is best reserved for domains that send only
> > > >    transactional email that is not intended to be posted to mailing
> > > >    lists.
> > > >
> > > >    To be explicitly clear: domains used for general-purpose email MUST
> > > >    NOT deploy a DMARC policy of p=reject.
> > > >
> > > > END
> > >
> > > [snip]
> > >
> > > How about, "... MUST NOT deploy a DMARC policy other than p=none
> > > because improper used of p=reject or (to a slightly lesser exent)
> > > p=quarantine is extremely harmful to email interoperability."
> >
> > Or, "...MUST NOT deploy a DMARC policy other than p=none because
> > improper use of p=reject or (to a slightly lesser extent) p=quarantine
> > is extremely harmful to email interoperability. Such improper use
> > includes, but is not limited to, cases where the mitigation strategies
> > discussed in RFCs 7960 and 8617 and elsewhere are not deployed for the
> > mail flows in question and cases where the domain owner deems the
> > collateral damage as acceptable loss in service of protecting its
> > domain from unauthorized usage."
> >
> > I suspect that my text above won't go over well, but the use of the
> > term "improper use" smacks, to me, of the IETF being the protocol
> > police, and I've been led to believe that's not what we do here.
> >
> > There are many things I believe, and two of them are these:
> >
> >    1. Any domain is a target to be spoofed
> >    2. The custodian of a thing has the autonomy to do with that thing what
> >    they please, so long as it's within the limits of the law. "My
> > network, my rules" as it were (or "Your network, your rules")
> >
> > DMARC is a tool in the fight against exact-domain spoofing, but some
> > methods of its deployment can cause interoperability issues. I believe
> > that as long as the risks are well understood and fully documented (to
> > include references to mitigation strategies) then a domain owner will
> > have all the information they need to make their choice as to what
> > policy to deploy. To mandate that certain classes of domains not do
> > something (and just how do we define "general-purpose" email anyway?)
> seems a bridge too far for me.
> 
> I agree with your items 1 and 2.  I'm not a particular fan of improper use either.
> Maybe instead of improper use.  Maybe just "use with such domains".
> 
> Your characterization reads more like SHOULD NOT unless ....  I don't think that
> unless [list of things that are only true in very limited circumstances and can't
> really be verified reliably] is very useful.  How about this instead (I am
> attempting to split the difference between assuming p=reject is okay is normal
> or exceptional):
> 
> "...MUST NOT deploy a DMARC policy other than p=none because use of
> p=reject or (to a slightly lesser extent) p=quarantine for such domains is
> extremely harmful to email interoperability.  Mitigation strategies are discussed
> in [RFC 7960] and [RFC 8617]."
> 
> I don't think we need to reiterate what p=reject does here, that's extensively
> addressed elsewhere in the document.  I don't think we have enough data to
> opine either way about the effectiveness of such strategies, so it's enough to
> point at them here.  We don't currently list RFC 8617 as a reference.  I think
> introducing an informative reference here is useful.  It's experimental, so we
> definitely don't want to put any normative language around it.
> 
> I suspect that's probably not what you would find ideal (it's not what I would find
> ideal either, but I can live with it).  Can you live with it?  What do others think?
> 
> Scott K
> 
> 
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!DQk5uxtCLX2CY35SAENNOFCA8Q1HtPphfxqGdOAYwly4Hk1ZvVvI
> h4pShpcVde6DoPy_ZlUm7N8WWQe3bUhg$