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

Brandon Long <blong@google.com> Fri, 21 August 2020 21:05 UTC

Return-Path: <blong@google.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 2FD593A1278 for <dmarc@ietfa.amsl.com>; Fri, 21 Aug 2020 14:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 U5dsIFuD2vPF for <dmarc@ietfa.amsl.com>; Fri, 21 Aug 2020 14:05:17 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 9E5263A1269 for <dmarc@ietf.org>; Fri, 21 Aug 2020 14:05:17 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id h4so3076689ioe.5 for <dmarc@ietf.org>; Fri, 21 Aug 2020 14:05:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MxHvCvCVKlUm8F1SxiXHETwFh3MyxkJTk33nuGTDQ0o=; b=TWlM4Yyyv2X2Vr13zEzFEcFXjEir5L9j4UFIQ5xnlophjZ0uOMNAZn7d85feY5D03r l6el1mvrNhf8petP5LOIEFVX6Ng/w5eHzVAwKt1uOYELxQYQ1t+W4TObhKXeteAPTkRF 69Tpbl39rpbb0WphIsVSOy2gDWky4WRoypzrs50ACDKWD/eAIz9uhXwWdNo+SxSPnTkW Ty2PdbUH7xSb8yID1QpH3TLFKABLYo0uNfihilWUVvYny2vQFqnzYUjPS9V3sZrQFTpi RCu+KTPGoiGXYZGGtbVOXaARG1v1ZkXhBOuwSAyApc/7OW4VZl4c8kSTKL+VtCk0Bu72 VU0A==
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=MxHvCvCVKlUm8F1SxiXHETwFh3MyxkJTk33nuGTDQ0o=; b=j2z1+en3iwlvsBP/Gt9Nr3J0li9pU6/FgRhgJySBQF15lvCzPH3gB2O0jIML750zqA x1eGR7Fl8lPdS5XtjuwMxdY02gOxNVcoLTv4OBUjIx90PqzWXPjzHpl7pLTItpp+xtHe OjCZmAL34OdT7Iqrzg6RjXDbiL2ny4PLH3rPKPi0rkYDqWJaLyrKOAxtg46fk5STljMT Gs2ANbarUZWKbU+sudBd9RG9JEk5owxxTHKz1DmGrAkyC1PwFkAz2Lve/Aa/OqW8qn5F vYpVoYAPRmrn84sdKs42Ath9qui9WSCgi7vEdj4usDngmVVED6E08qgFAoqWFWXBd030 vxIQ==
X-Gm-Message-State: AOAM5313Ccr0+EHdEYfQ/0AFLYFIhMj5RB7szeVS7F8d2ScXh2pAWuU6 O/nprjx6lV/YdFtd+dB1qC263Ez9T14u4iEJyrGX+xM+Gg==
X-Google-Smtp-Source: ABdhPJz3lmQM9Hw7fCgTqoz9s0SNsvCOPgPOjtgaRzvIpq42rsss1FZ/9o+8NECZ1RysOfNTJUbCpOXHY4SFG+a4oRg=
X-Received: by 2002:a6b:b74b:: with SMTP id h72mr3795478iof.52.1598043916411; Fri, 21 Aug 2020 14:05:16 -0700 (PDT)
MIME-Version: 1.0
References: <20200807191216.43E971E4014E@ary.qy> <B5271A94-7B89-4226-BE77-471E698E1284@marmot-tech.com> <BY5PR13MB299920E15CC75E9D72F67170D7430@BY5PR13MB2999.namprd13.prod.outlook.com> <4fa0afc4-d3cd-994a-f02-f38da4cb1543@taugh.com> <7ce20245-5942-14f3-3220-1faaa2c8ccbb@wisc.edu> <4d13611d-e6e7-a6f8-d48a-2a11a74f5d51@bluepopcorn.net>
In-Reply-To: <4d13611d-e6e7-a6f8-d48a-2a11a74f5d51@bluepopcorn.net>
From: Brandon Long <blong@google.com>
Date: Fri, 21 Aug 2020 14:05:03 -0700
Message-ID: <CABa8R6sz=UL81szmM-q_aRqCSbsfwBYovYrteKcXhJj7LxyD1Q@mail.gmail.com>
To: Jim Fenton <fenton@bluepopcorn.net>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f9b9c705ad6997db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/4Dk9IIvmgh8oDbggY3hizQA4pfU>
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: Fri, 21 Aug 2020 21:05:19 -0000

On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton <fenton@bluepopcorn.net> wrote:

> On 8/17/20 3:52 PM, Jesse Thompson wrote:
> > With a complex organization the only way to get people to change is to
> publish a restrictive DMARC policy and then see who comes out of the
> woodwork sheepishly admitting that they've been ignoring us for years.
> >
> > Normal people sending email (especially those who are working with an
> ESP, most of which happily send email without any DMARC alignment) do not
> comprehend the notion that they should be using a subdomain for their
> transactional messages; even when we directly communicate this fact to them
> repeatedly.  They just don't understand the nuances of email.
> >
> I thought the DMARC reporting mechanism was there to allow such
> organizations to detect those behaviors and get them corrected without
> actually causing the damage of a restrictive policy.
>

One thing we've found useful in this case is controlling the organization
from spamming.

Which is to say that the org has a policy on approvals and what is allowed
to be sent marketing wise, in some parts of the world to comply with laws
on such topics,
or to be sure the entire org follows the principles and someone new doesn't
just poison the pool for everyone else.

There are always people who route around restrictions or sometimes don't
even bother to look for anything, they'll just hire a third party ESP and
spam away.

DMARC helps in this case to reduce the success of that and force them back
to internal compliance, which relieves the legal burden as well as the
negative impacts
on delivery and public perception.

For folks who just register a new domain name and spam anyways... yeah,
well, there are other consequences down the line and other anti-phishing
restrictions that
kick in at least on our inbound systems..

Brandon