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

[Scott Kitterman <[e-mail]>]

I think it's much closer to acceptable in theoretical cases which are unlikely to exist now, but may be okay in the future, but it will be difficult to know.

It's perfectly fine for a domain owner to accept this and take the risk, but we shouldn't even try to pretend there aren't issues.

Scott K

On March 28, 2023 8:21:43 PM UTC, "Brotman, Alex" <Alex_Brotman=[e-mail]> wrote:
>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$
>_______________________________________________
>dmarc mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dmarc