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

Scott Kitterman <sklist@kitterman.com> Wed, 17 July 2019 06:27 UTC

Return-Path: <sklist@kitterman.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 C0E3B120140 for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2019 23:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=0WgtKjsc; dkim=pass (2048-bit key) header.d=kitterman.com header.b=N2V1kvNk
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 Q0_HTjY_5549 for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2019 23:27:00 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E7012006D for <dmarc@ietf.org>; Tue, 16 Jul 2019 23:26:59 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id CE050F80045; Wed, 17 Jul 2019 02:26:28 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563344788; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=u0maflmLf6p28POLogAyignKfZ312y30A6WGNYaIKME=; b=0WgtKjsceMbuz76YiiDycwLeSWYXzz2UzMaSdSsFucOxtE9CnixUXmOK DWS3WFwhuEQuQ8asAsYet/L/Ota1Dg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563344788; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=u0maflmLf6p28POLogAyignKfZ312y30A6WGNYaIKME=; b=N2V1kvNkZK4U6wdXmNGu/ubqMJjp5S8BFDbrRASuRWBuJPkFMF7hu4QH RA+4SkJ9o/+XPslXMCXSgQDclDmhUCSKu0Jqqo6F91F60ZPiLbSWks3D7M aab00+IXPsMIzf1G+7HRnms7vo/Wet9FAoHreHUfKxZg7FYgPX9UuC0DCX PeE+qLryfUKSLWxlZ0on4Ft/qlw6fm7Fn5rwcw95au7QUDNKB2jwD6OupV ld7386pCJahtjMiQI7+7qtTN+y91RVZhsWHHWkwf478p1XDS5+kQ3/dBXe oqPGDEsVvPJ5+2qbYhzSxRo2GRBxB9X+XLJGIbb/oAYwOqHziGqivw==
Received: from [10.56.245.58] (mobile-166-170-45-222.mycingular.net [166.170.45.222]) by interserver.kitterman.com (Postfix) with ESMTPSA id D28EBF80042; Wed, 17 Jul 2019 02:26:27 -0400 (EDT)
Date: Wed, 17 Jul 2019 06:26:25 +0000
In-Reply-To: <CAD2i3WPGWe8Z3av1Jua6sazsoStc7VTOLBve7psVo=K4VGTgig@mail.gmail.com>
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <1808303.aIhlromXIS@l5580> <CAD2i3WN42v0RHzu+2=+_mjX5kmxw6B-0F3-=bY-bTEsJM1qLvA@mail.gmail.com> <1692123.ljdY5SVR4M@l5580> <CAD2i3WPGWe8Z3av1Jua6sazsoStc7VTOLBve7psVo=K4VGTgig@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <D42C419C-F02E-4B5A-BB10-E8D49000349B@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Cu6UCr7jCi_1oauOSW8epZ1m-5Y>
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 06:27:02 -0000


On July 17, 2019 5:54:41 AM UTC, Seth Blank <seth@sethblank.com>; wrote:
>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.

See if you still feel that way after considering backward compatibility ...

>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 think we agree on the goal, the difference is only about implementation details and impact on non-particpants in the experiment.
>
>> 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?

Keep in mind that senders do send from what we call non-existent domains for reasons that seem good and sufficient to them.  Let's take that as a fact, whether it makes sense to us or not.

Sender (who knows nothing of our experiment) has published a DMARC record that includes:

p=reject, sp=none

When a DMARC compliant receiver receives mail from a subdomain of that organization domain, the policy to apply is none.

If our experiment has 'np' fall back to 'sp', then the non-particpant gets the same result.  An experiment participating receiver would use 'sp' directly (none) for an existing sub-domain and also use 'sp' (none - 'np' fallback) for a non-existing sub-domain.

If our experiment has 'np' fall back to 'p', then the non-particpant gets a different result.  An experiment participating receiver would use 'sp' directly (none) for an existing sub-domain and also use 'p' (reject - 'p' fallback) for a non-existing sub-domain.

Keep in mind, this isn't just about receiver processing.  The policy applied is also in the aggregate reports.

I think changing existing defined behavior for non-participants in an experiment is not appropriate.  It's even more unacceptable in a case like this where we absolutely don't need it to achieve the desired behavior within the experiment.

Scott K