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

Todd Herr <todd.herr@valimail.com> Tue, 28 March 2023 19:14 UTC

Return-Path: <todd.herr@valimail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFD2C151B34 for <dmarc@ietfa.amsl.com>; Tue, 28 Mar 2023 12:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_5durnJ72C1 for <dmarc@ietfa.amsl.com>; Tue, 28 Mar 2023 12:14:55 -0700 (PDT)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A26C151542 for <dmarc@ietf.org>; Tue, 28 Mar 2023 12:14:55 -0700 (PDT)
Received: by mail-pj1-x102a.google.com with SMTP id lr16-20020a17090b4b9000b0023f187954acso13709122pjb.2 for <dmarc@ietf.org>; Tue, 28 Mar 2023 12:14:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; t=1680030895; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Ajp9oU0donX4w9KhwFvBOWV/o74qJjrURL1tNg5VsoI=; b=Q8cGIwbdUQ1GGn5ETvk2vtbJ/nM4SWz0XLsYXaSeBAOsnESfqTe1e1Ip7b6YSU2N4H L30SLTJQp/nH0ObA7rMvR2ZU8qVoLOXPBCc13RvaBxTaZOZ+UzpAgVfhWscEWh0PvEu+ XqZo5l06MXCLAcgx8qMtoqDUukDzjPqd1Io+05aGdE7Nri1Gs54oTvd11UfK4x8uopbg YmVGOh9JhsWgouKfW4YkXDlRR5sa0F/Vjb0s2MJRBPquGwtZjp9RUDJZZKu4PTv1iz+R mX1u3XtQFLFRNIeEbe7klzKxzJhvH43wyg/mTHGfEcQud2BO3mSo/hmt+LIlSVAgX4UL myYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680030895; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Ajp9oU0donX4w9KhwFvBOWV/o74qJjrURL1tNg5VsoI=; b=wj0jjINIOMALaV8wmo8kO/qa35PtW8VEFsfR/QOua4pV0FNJ1nfPz/v+f5HGh3Zf0U QYVUkG6lWRDLp4cTEaaBjEZZFrudV22mLWOhS1hMiSJEDqVBVnXdxCCwjUu0K3N6mUsC DVlm+l2QLDiZYfhUl7u9J/4dRjy0eRqM3khLBJj/ipoFG4kMhPccjgeGykHeZycpPvCh IwzFR3cxH/7HWBlsWbsBmjnVXJMATruo/2l0tM3hALcBXISF5OfcfA/ZFCuTBMzRUOvb FDsjPoXVVgJOMABnApmUgeA4yCwQ/jQO6sKuaIv7RWYwmYM98I8RRs3DL2gYdS9NnhwA HKYA==
X-Gm-Message-State: AAQBX9cqJwMt+hVyWxIB61L6amzPYsemLmwmyNKAYNCZZlQF8xnH5P2t drs5n6JzJsXXSmv9ptP+0gAMwRYuBfNJWGP6+nzp9PXmybX2FecJ
X-Google-Smtp-Source: AKy350bT0iXO0EKgKYExjk+9zgC0YGMVWo9A43SXb7lg0LEHdjHBbq/H4UyQrVCITOzFGCy8Be7iL19y4umlrxBpDZ0=
X-Received: by 2002:a17:90a:9295:b0:23c:fb7d:de70 with SMTP id n21-20020a17090a929500b0023cfb7dde70mr5290924pjo.7.1680030894760; Tue, 28 Mar 2023 12:14:54 -0700 (PDT)
MIME-Version: 1.0
References: <CALaySJ+NBg9vzqa0_t-sBf7EKXQ3A=DTyy-Vc7M-ZK9-vfJxmw@mail.gmail.com> <6319292.vCqnBZbX7o@localhost>
In-Reply-To: <6319292.vCqnBZbX7o@localhost>
From: Todd Herr <todd.herr@valimail.com>
Date: Tue, 28 Mar 2023 15:14:38 -0400
Message-ID: <CAHej_8nd1xyAgwASLJbuJHyXEAfHbjqxNH1XtJxKFyfyOneyug@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b1c0da05f7faac7a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/QCdov0U35WwXxDwrU3VhthhG2Qw>
Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2023 19:14:59 -0000

On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman <sklist@kitterman.com>
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.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.herr@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.