Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

Seth Blank <> Wed, 17 July 2019 05:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1617412015B for <>; Tue, 16 Jul 2019 22:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 94KbmYzqnCb9 for <>; Tue, 16 Jul 2019 22:54:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E97A120140 for <>; Tue, 16 Jul 2019 22:54:58 -0700 (PDT)
Received: by with SMTP id z23so23708013ote.13 for <>; Tue, 16 Jul 2019 22:54:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CL5QSqZXjs2xEMZP+4XW03fXt3Nw7EkVS8giwHAqjyY=; b=PJlJlKTJDWED0xR+fKgkaxURwmwEC0DNYLiziyu4tlbLS+WjdYPtAeRZl764+aIqPB Pi8iUUWoSQZhhraWpv2dcJEPeM/8xxcEYti+hANbpezbOOVOrkFPAJXc+FZ86AHF/6Kj ATm2s42l6DoarczEWvSSLq8l2/6XJhz2kmCVf4g1WDwR7xkTLXWAUGJdByp0DKq/uMeO IgqW4TalboB/cmDaKtcW8psejwRniKYHRhP/Y1wWyoaISb6f/7FJwsj4irBmPTOIyuoS 9WAXre5eOUATwokAYJ6UwSRKSRanH0QrIQzwDdJLgMdnx9GCstr3dvRjdgZqvZ4k3J6G McAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=CL5QSqZXjs2xEMZP+4XW03fXt3Nw7EkVS8giwHAqjyY=; b=nrkNhfAJzsstEx6o01fuLW1oVzpaydvDt67On37HnMohP5HwpcBCo+OtZJkP+Fy0Gb OZYd47Ff7vyJkNxJIxkV17o1XpS+DGSsqknUCgcMZeyd7fIG+ufJ9LsUc8SHBqhHHsNF /Z8J6I70M9aPd7upVY33a3vKlcBCeRrQrieBPa22MQxj++3xVwZ5AJkT1CUJ+X8Fwcda cN/XcZovDTLyThr1pnIIZwUCCqYJXiZLtj1gKu7RXpPkrRMDkNtF1/A3Jc1alrxtXQO/ 4zIljNHhCgjvKSEuqsmjbr6lPSdYLZP4ymfbyIpB67Nl/6HX5Q+V+XwE0HmDHLkZ7l0d cpaA==
X-Gm-Message-State: APjAAAVFKooXD/FpjhPsDuffJafL+rERAop+LWyCFc8IO7Bb48jcNGRF 1ToZZXfHBzjBToNK5vr7UoSNs77DyRpWDWoQvvfEoJbQ
X-Google-Smtp-Source: APXvYqwtq6F5xKXEOShPcScIFxdDgsfiMkPzVss/y3MR7gT641ZrBM1k1hIBVBUGvpM3YDnyAMdv1y8uKqQt+u/LYzA=
X-Received: by 2002:a9d:7643:: with SMTP id o3mr26013335otl.49.1563342897361; Tue, 16 Jul 2019 22:54:57 -0700 (PDT)
MIME-Version: 1.0
References: <> <1808303.aIhlromXIS@l5580> <> <1692123.ljdY5SVR4M@l5580>
In-Reply-To: <1692123.ljdY5SVR4M@l5580>
From: Seth Blank <>
Date: Tue, 16 Jul 2019 22:54:41 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000000f92fc058dda2257"
Archived-At: <>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Jul 2019 05:55:01 -0000

On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman <>;

> Yes, the point of 'np' is to allow for a stricter sub-domain policy, but
> that's to support early deployment of strict PSD level policies without
> breaking org domains that are still deploying/have not deployed DMARC.

I absolutely agree with this.

> Case:
> PSO mandates all orgs deploy DMARC, but that's not done yet.  PSO wants to
> deploy PSD DMARC for reject at the PSD level and for non-existent domains,
> but
> leave non-DMARC deployed existing domains at none.  PSO publishes these
> policieis for the PSD:
> p=reject, sp=none, np=reject

Ah, I see what you're saying here. I honestly couldn't understand why you
were talking about sp=none at all within a PSD context. I thought the
solution to this scenario was to do as the PSO p=none; np=reject. I
actually like p=reject; sp=none; better here, because that lets the PSD
lock itself down as a sending domain. But to me, this also makes it clear
that np= should use the p= not the sp= as its default.

That said, I feel less strongly about this now, and can see merit in
inheritance from either side (or from a hard default of none, for that
matter, although I'd strongly argue against that personally...).

> Having 'np' fall back to 'p' doesn't actually solve the problem you claim
> to
> be solving since it only affects non-implementers.

This I don't understand. The results you outlined are exactly what I think
should happen.

> I believe that's the exact requested case and the changeset I've provided
> supports that without creating a situation where every implementer of the
> experiment suddenly starts processing existing DMARC records differently
> (which
> I think would be very bad).

I don't think I properly understand what you're saying. Can you clarify
this point?