Re: [dmarc-ietf] non-mailing list use case for differing header domains

Jim Fenton <fenton@bluepopcorn.net> Thu, 30 July 2020 22:53 UTC

Return-Path: <fenton@bluepopcorn.net>
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 CC61D3A0C6C for <dmarc@ietfa.amsl.com>; Thu, 30 Jul 2020 15:53:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-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 (1024-bit key) header.d=bluepopcorn.net
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 uK6N0ODvMugz for <dmarc@ietfa.amsl.com>; Thu, 30 Jul 2020 15:53:05 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88103A0AEE for <dmarc@ietf.org>; Thu, 30 Jul 2020 15:53:05 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:b4e8:628f:2119:e45a]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 06UMr3id016674 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for <dmarc@ietf.org>; Thu, 30 Jul 2020 15:53:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1596149585; bh=eaTQ1VCAYW1esjd++FCGR8sUCc63ap/w0EPYv+HHMtA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=T+vkUelEKsgVLAHo1qFatBNwl1GUDcmGMX4uPr/GYKm4tShjODz9+7m7+vjN6/VIW 9O7LgBDSYQr+ismNUZGcfOyQH3TBeu9uT4VUHh/EJCsQeQw8KWCt4DNhktVtD4HT2u 7889qc3YELJkrru1uxBZOzqKNWWAFHWC4wqKfDc0=
To: dmarc@ietf.org
References: <BY5PR13MB29998094418C8A6C25902569D7730@BY5PR13MB2999.namprd13.prod.outlook.com> <c0361cb2-b25b-5d75-cb1f-f9c87e3ecccc@tana.it> <AE9A3A9F-27FC-4935-B8E6-AB0CE1A6D5E2@wordtothewise.com>
From: Jim Fenton <fenton@bluepopcorn.net>
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXxoIpQUJEI6gYAAKCRAbJaiwFdCf voc0EACDpkdX086xmst9QgccOX2qKPnzbaAa0/NpFtJN860Us5gbv8gf+9Wfkz0UVqmExp3a 7CMzJnH5CLNb4jOXMMMoFCzJ8UioTGL4jwN23wXHdhOEycnKMl2i2bN13DwEWdrqVHzF2ds8 did+0Ep1deFCGAEXTS5QMc2LyPynMGScHcLTZJ6IIBK9sQqGn9IPR4UjiZOV4382RG86jxam G8EhKTahaJF+srqXsmKdfg1xGDUr0aFfPZQcdpE/cBePMqe4+H6py4eEobcuVD61RL8KTj3D F78TkoR7+RJcPvTGEA3I5kNPLQrqtSFhds327Mr6MzDkC4gg5nIhvWb/j2zn4tfckBY+e9vS nq6Hfo0NYbqWYaHSdvA0bF7D9CPJ4sXco7MCx1/nLYYLNHpxnSMAFPZmI3lMQBGcR89c/sBm K7BA4aotgbxfm/fZNngZB0xFolkXyPIBfR9rzgIY2llSdd+KlN5tjZnQ7QkShWp0iG2YI6nC Zr7HaObdp+aRB5UmkD5GOdPMcv7s5esouysTKu2R2nzPQG0atMiSRtS6QEDmp372TG7L2w4V HVLx5wlrWpoTiKAMwg7VtFjD7Xbyho6NgRrrmhiW7KnIQxYrb6evg4v316E+H0w0ogU/fDMF x3ZnZDC6npTuPT4GojlxIANBQmSKHYX66HD291b7WrkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQgAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJfGgilBQkQjqBiAAoJEBslqLAV0J++j7cP/jEq8IXTyahDSPJxQpMKVDL24OBhgZZdmt8B AWFUIrlnaucZ8BXW8wYFnFr+76gSKkfArAXcxSol32aMKS3fW8EdIDw7nkdPuKJGY6dhzIZ5 HDRq/jNMLYHcqXB+0YuqpZ4VNGL3/gmgduBgyTx/cnfqOe7WG13V4qFRMNIrdsf2QdAeFl93 MirVJpokH3anHeh8fQkpWSCiIP7ejGN3Lld1pWdGXqpubj5z6R5208/acSpVs79JiQfaH3q0 cau9oYX0JRoW6iQpGNXlkfLFehCzsKks/m4CtMXMXtajakBmWuHxuebcfHpmz6F+9B3rHvai 5TjSmZe9KfjlDAsuksq4CP1kJOqTxg+e0Sup38b0C979lHpRIhwwl0znobT9EPnrjMd5yDZt 2CZGEAE0bzXWLSHcRDJnHu+jscCnowC18S7LL3X9Gmw8r+WUYmMQ0A8ZDDOB8Z5p9PIs2OAQ kBBsBWFb59KGjtAvFWFEm6/DRDlzXmANICwHC2G4aqn1G3DLSDzwfBfSYLs31dK5mDyzv51G ZJfgxbwTKcdoy6AEkUrzM3A1GP+NVfb/I2LCui+QOHfhfPFmV1OPpTPL77AsTXviA7l1iYMd BADv28GwZyay6Fd1Hp7rOXFI/Qx87++GwpEjpuSKcZihfnh2754ZSyZxim2wmMs6k12nYwvE
Message-ID: <d446c074-bbcf-a824-041c-e45958e0b0a2@bluepopcorn.net>
Date: Thu, 30 Jul 2020 15:52:58 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <AE9A3A9F-27FC-4935-B8E6-AB0CE1A6D5E2@wordtothewise.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/oULnLm2LxmGepV2TocPjGk2q8UE>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
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: Thu, 30 Jul 2020 22:53:08 -0000

On 7/28/20 2:07 AM, Laura Atkins wrote:
> The underlying belief with DMARC is that mail is simple, that
> companies are monoliths with only a few brands/domains, that it is
> possible to know exactly where every message will come from. These
> assumptions are not and have never been true. Inevitably, however,
> when these types of issues are pointed out, they’re dismissed with
> “solutions” that aren’t actually achievable or maintainable. DMARC
> proponents have repeatedly failed to pay attention to folks pointing
> out the actual operational challenges and thus have never addressed
> the issues in any way. This is, fundamentally, why only 15% of fortune
> 500 companies have adopted p=reject and why adoption rates are only
> increased by 5% last year. 
>
> The indirect mail stream issue is real. But it is not the only barrier
> to getting to p=reject. The sooner folks start listening to the people
> who are presenting real issues where DMARC alignment can’t be achieved
> the sooner they’ll be able to address them. The problem with low DMARC
> adoption is that it does not adequately address how companies are
> using mail in ways that break the DMARC model. Almost a decade on, and
> proponents are still suggesting that email usage should change to
> comply with their model of how email works. This has not happened.
> Maybe proponents need to think harder about why. 


There's an underlying assumption here that I don't agree with: that
DMARC adoption equates to the publication of a p=reject DMARC policy,
and that everyone (or at least all Fortune 500 companies) should be
doing that. p=reject should only be used when the usage patterns of the
domain support that policy. I'm more inclined to say that 85% of Fortune
500 companies are savvy enough not to publish a policy that doesn't fit
their usage patterns.

As RFC 7489 says, "DMARC is designed to prevent bad actors from sending
mail that claims to come from legitimate senders, particularly senders
of transactional email (official mail that is about business
transactions)." If the statistic were instead, "only 15% of domains used
exclusively for transactional email publish p=reject," I'd agree that's
a statistic that should be improved.

-Jim