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

Neil Anuskiewicz <neil@marmot-tech.com> Wed, 12 August 2020 22:17 UTC

Return-Path: <neil@marmot-tech.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 94D083A0C1B for <dmarc@ietfa.amsl.com>; Wed, 12 Aug 2020 15:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=marmot-tech.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 sa7yxY--6PcV for <dmarc@ietfa.amsl.com>; Wed, 12 Aug 2020 15:17:19 -0700 (PDT)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 2E5AE3A0C0C for <dmarc@ietf.org>; Wed, 12 Aug 2020 15:17:19 -0700 (PDT)
Received: by mail-pj1-x1031.google.com with SMTP id mw10so1817897pjb.2 for <dmarc@ietf.org>; Wed, 12 Aug 2020 15:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marmot-tech.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=LOr2rOBLCr6nX8TFKwYRZAS4fKFdC+tPEwiQBf8pwqA=; b=VlFwQNi8JOcLUuTBtamR8tqGjkLd+f2z2K07gVl3hECog39hzun3toQ0xBkGFdyHQ5 EQbgRA4EKxwxuVdKYG5FWBoGwcQWJ7xb3DvBk0E+Gr0hsCX+KyTEOIy37ahgSF4iSuYi +DsV+Qaf5+Yz7hcVlzpRZFpDl4UZ+PMj26XgY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=LOr2rOBLCr6nX8TFKwYRZAS4fKFdC+tPEwiQBf8pwqA=; b=hymDGS4y/ZRJ15YEs5mgNPEWhM6USyvRSMfC3bZxezf36DU7R8wzcrsifHIsQlOaKU mlw1EXo/2VgQ3ANIwBPhfwkflN9Rc6O0iTtPkQIgyueOZPnPilCGh6qfvpWgTDQ26qky K48CuwjM7OP9T6jp5vdxxe8bWatRc8GlazyTSJyDa8CtddHqJAXaGL4l86aEKl+a7R1M MhcqKim1Conz7iPDu8Z62TQOupH/8ChnmHUT5lP9mGLGCfMGAWleWAxXNg493A2ECMzy LX93dNsUJQYqzPz+vInlhGq0q0epnsTBfmQR3wYyCOQMzL3AUvBLCohizFVPBA3YN1Dt g26Q==
X-Gm-Message-State: AOAM530G742u2ND8JNctUH0VxjkHcuFfrRu/KTde8RERSjngcGhe7lV9 DHf9NiDm3sNyj5g0C9NFjCyiUg==
X-Google-Smtp-Source: ABdhPJyyCvxFNN+0WlTWJUvzjOyhdyKz61jojCza+CccR1boYxKH+o4n6KsM76gbihdBjMkP4jklXQ==
X-Received: by 2002:a17:90a:fc90:: with SMTP id ci16mr2068756pjb.229.1597270638266; Wed, 12 Aug 2020 15:17:18 -0700 (PDT)
Received: from ?IPv6:2601:1c0:cb00:7680:85c4:bfe1:ff19:12f1? ([2601:1c0:cb00:7680:85c4:bfe1:ff19:12f1]) by smtp.gmail.com with ESMTPSA id b20sm3437639pfo.88.2020.08.12.15.17.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Aug 2020 15:17:17 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Neil Anuskiewicz <neil@marmot-tech.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 12 Aug 2020 15:17:17 -0700
Message-Id: <B5271A94-7B89-4226-BE77-471E698E1284@marmot-tech.com>
References: <20200807191216.43E971E4014E@ary.qy>
Cc: dmarc@ietf.org, atyrsalvia@agari.com
In-Reply-To: <20200807191216.43E971E4014E@ary.qy>
To: John Levine <johnl@taugh.com>
X-Mailer: iPad Mail (17G68)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/kMf49RFgaGm1DBt2SgWD-rxyLr0>
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: Wed, 12 Aug 2020 22:17:21 -0000


> On Aug 7, 2020, at 12:12 PM, John Levine <johnl@taugh.com> wrote:
> 
> In article <BY5PR13MB2999AD95B4BD7C80971FDA4FD7490@BY5PR13MB2999.namprd13.prod.outlook.com> you write:
>> I feel like what is happening sometimes is that central university IT is trying to drag their whole institutions into a
>> more secure posture before anybody in a position to stop them fully understands what's going on lest they be told to
>> stop because it might make things a little inconvenient.
> 
> I was with you up until that sentence, since it trivializes the real
> problems that overly strict DMARC policies cause.
> 
> Just yesterday I was sorting out a problem with people trying to
> finish editing a revised IETF standard about real-time web
> applications. Some of the authors' messages were disappearing,
> apparently at random. I saw what the problem was, one of the authors
> is at a big company whose IT department insists on p=reject (and has
> blown off complaints from fairly senior people about the problems it
> causes), the other uses an MIT alumni address that recently moved its
> hosting to Microsoft without telling anyone that the new host enforces
> DMARC policy while the old one didn't.
> 
> My guess is that MIT figured Microsoft will host this for free, that's
> great, totally unaware that some of its users' mail would silently
> break.
> 
> I told them as a workaround they needed to directly cc each other when
> they send anything to the group list, but the whole thing is a
> self-inflicted wound.
> 
> R's,
> John
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

When mail breaks it’s more than an inconvenience. In business it can materially affect people’s livelihoods.

 I do think that sometimes people don’t take p=reject seriously enough, and don’t realize how much time and monitoring and prep it takes. I mostly work with smaller entities but I advise staying at  p=none of the time unless there’s spoofing. Otherwise, it’s reporting only, watch the reports, and take action if and only if there’s a problem. 

I do get the instinct to be proactive but if you’re going to be proactive, get ready to take the time and, if outside help needed, the money to do it without breaking legit mail.