Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

Dotzero <dotzero@gmail.com> Fri, 14 August 2020 14:31 UTC

Return-Path: <dotzero@gmail.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 A148A3A1147 for <dmarc@ietfa.amsl.com>; Fri, 14 Aug 2020 07:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 SY7CKFjkEWJC for <dmarc@ietfa.amsl.com>; Fri, 14 Aug 2020 07:31:48 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 C3CEC3A1146 for <dmarc@ietf.org>; Fri, 14 Aug 2020 07:31:47 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id 88so8557054wrh.3 for <dmarc@ietf.org>; Fri, 14 Aug 2020 07:31:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w/BAT0FyRv6Xi+zh4mTZAXOAxlLHk2esjRN5U8bvxpI=; b=jrKVv6pi3QwEE+ox5/Zpe6WaKpwLLrvWstWSfGmdR41nPYZUGsFs9WRVvMSEkJ8odp LNDa36aNqVjxpEsUtfFpjeHM9I50NDK51lHc32QiN4TvOESRWTkUBvcQ2OLBnNXmeXgR 4wWWtJ9qUJx2TC/iX6zgf1rcJk403dRlRggzowqaSLuRD4ijrg7i3FhfWZ6+yB8hVoJk i4/5wPRDR+bRKMGf8FJpgZ1bcfOoezKZJQQO3kFlI/YmucM29TRW69nMGNCqBtykZ7FT mkVTt2t0U3N3PcBfAL75SBWyNZL1agJIhfbKOSu2cUm1ZXSfxk4mUIDUdVexmtc2zbtZ 3XRA==
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:cc; bh=w/BAT0FyRv6Xi+zh4mTZAXOAxlLHk2esjRN5U8bvxpI=; b=WC2QTooEZR4bnJe0BKMkUXhM9rc2jGVsxg7KxoWjOhCs3Q1leo76tPnD0SKDiLFIwx gs5QkpVUCO1R1n2hkvzfajwm5Z/4kBgJhp5WJnLPdFn8pZBySy1xE4w+Dkx4m6XMx/A4 COMMrWVS4MI96XMVCwpa32W98BDhTaGv3+l/JmWh55h4ZA6Vbrb3+inSAhyF5Vt8vCGb yl6k7xfoMTYpeccxWCfDgNJwMAerEAiBAZ1MHL7Qi80L/Vjq75S9zUoO+YmCIKRl5bKo riDLBShkbpEg8Tm/lGHy/hctzZdwyC4vLy0yV7VDS9sunW6eZltCNvN8aicuGqzxL5F/ Hfjw==
X-Gm-Message-State: AOAM533tLbxbOqI1kvKwrfv95+ZqczqljCpju3W07AviRUShATCfL2ty 72AvwB4d/Lnu52OG1wZOOVEfle92lWSwo/+HGJMgc1UN
X-Google-Smtp-Source: ABdhPJzGiHWe7uXf0wrOk0Lbh+h6qBhyK11mx3cQ594EtSuUV7LnNvLFM7y6E2eG6soOVUI9BcEm8JY3P4qSy06d5Jk=
X-Received: by 2002:adf:edc3:: with SMTP id v3mr2967161wro.193.1597415506269; Fri, 14 Aug 2020 07:31:46 -0700 (PDT)
MIME-Version: 1.0
References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com> <99810a58-3809-bfd2-3571-bac54430f9e8@tana.it> <CAOPP4WHWoVkA+ZWZ+2AFnH8_nKBxO+t3Z4trz347JV0fsEy83Q@mail.gmail.com> <003501d671b9$467c0670$d3741350$@bayviewphysicians.com> <CAOPP4WG0Az02DJ0TvWfnaWSfCjnqW3tLh3TTGOJu4BC4zNuQBA@mail.gmail.com>
In-Reply-To: <CAOPP4WG0Az02DJ0TvWfnaWSfCjnqW3tLh3TTGOJu4BC4zNuQBA@mail.gmail.com>
From: Dotzero <dotzero@gmail.com>
Date: Fri, 14 Aug 2020 10:31:35 -0400
Message-ID: <CAJ4XoYeQxgu5Yj+Aag9kYY3HXMrXV8DPNczXP5L_BLoVaAv0Gg@mail.gmail.com>
To: Neil Anuskiewicz <neil@marmot-tech.com>
Cc: Doug Foster <fosterd=40bayviewphysicians.com@dmarc.ietf.org>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cf633605acd74759"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/uaEzPXX3W9p-UZy0d3NHWNC-FiU>
Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
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: Fri, 14 Aug 2020 14:31:50 -0000

On Thu, Aug 13, 2020 at 6:53 PM Neil Anuskiewicz <neil@marmot-tech.com>
wrote:

>
>
> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster <fosterd=
> 40bayviewphysicians.com@dmarc.ietf.org> wrote:
>
>> If I followed Neil’s discussion of MajorCRM:
>>
>>
>>
>> The current DMARC architecture supports authorizing a vendor to mail on
>> behalf of their clients if the client includes them in their SPF policy or
>> delegates a DKIM scope to them and they use it.
>>
>
> And client's domain is only in the Mail from uses the vendor's domain (
> somevendorxyz123.foo.com). It passes SPF in but it's not in alignment
> with the organizational domain name (example.com) that the client uses in
> the header from.
>
> This is super common and, as a practical matter, it works... except if you
> ever want to use DMARC's policy for anything other than reporting. The vast
> majority of people think that if you add include:bar.com (whatever vendor
> KB says) in the SPF that they are good to go.
>

"Vast majority of people"? Can you please provide data that supports this
assertion?


> So many businesses have several entries in their organizational domain's
> SPF record yet the RFC5321.from is the vendor's domain. The client
> sometimes goes over the 10 DNS lookups with includes that aren't doing
> anything for them. I'm not sure that 10 DNS lookup limit. There are some
> prominent services of various sorts for which the single include will do
> over 10 DNS lookups and hat's just one of many includes a client might have
> (I know this isn't about SPF per se).
>
> Yes, I can usually quickly set up a subdomain to use instead of
> somevendorxyz123.foo.com but this isn't always possible or it requires
> pushing to get it done.
>

So you are saying "Email authentication is hard. Let's go shopping"?

>
> This makes DMARC a sketchy tool to use for any policy above none which is
> in and of itself useful.
>

Not at all. It simply means that the people/organizations involved have
some problems. Please consider the following joke:

How many Psychiatrists does it take to change a light bulb? Only one but
the bulb has to want to change.

I've been involved in setting up DMARC with a policy of p=reject for
somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
in getting buy-in across the organization that it is a worthwhile effort,
getting control of your organization's mail flows and ensuring policies and
procedures are communicated and followed. For complex environments there
may need to be some automation required for creating and maintaining
private/public key pairs and DNS records but that is much more
straightforward than the aforementioned heavy lifting.

Michael Hammer.

>
>