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

Seth Blank <seth@sethblank.com> Wed, 17 July 2019 05:55 UTC

Return-Path: <seth@sethblank.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 1617412015B for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2019 22:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94KbmYzqnCb9 for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2019 22:54:58 -0700 (PDT)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E97A120140 for <dmarc@ietf.org>; Tue, 16 Jul 2019 22:54:58 -0700 (PDT)
Received: by mail-ot1-x331.google.com with SMTP id z23so23708013ote.13 for <dmarc@ietf.org>; Tue, 16 Jul 2019 22:54:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <1808303.aIhlromXIS@l5580> <CAD2i3WN42v0RHzu+2=+_mjX5kmxw6B-0F3-=bY-bTEsJM1qLvA@mail.gmail.com> <1692123.ljdY5SVR4M@l5580>
In-Reply-To: <1692123.ljdY5SVR4M@l5580>
From: Seth Blank <seth@sethblank.com>
Date: Tue, 16 Jul 2019 22:54:41 -0700
Message-ID: <CAD2i3WPGWe8Z3av1Jua6sazsoStc7VTOLBve7psVo=K4VGTgig@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000f92fc058dda2257"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/AgLo7qagk3xZSJBtr3N8p86odmw>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 17 Jul 2019 05:55:01 -0000

On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman <sklist@kitterman.com>;
wrote:

> 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?

Thanks!

S