Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

Michael Thomas <mike@mtcc.com> Tue, 01 December 2020 18:07 UTC

Return-Path: <mike@fresheez.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 271083A1423 for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 10:07:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.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 iPdbCM4dUigL for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 10:07:31 -0800 (PST)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 1403D3A1420 for <dmarc@ietf.org>; Tue, 1 Dec 2020 10:07:30 -0800 (PST)
Received: by mail-pj1-x1029.google.com with SMTP id r20so1707830pjp.1 for <dmarc@ietf.org>; Tue, 01 Dec 2020 10:07:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=QmKQN1M3UQJWU4PcSnftSIcqpwpLoaBdyhFDrBASu9Q=; b=RUG3peS9rn59+OXolhXKkbPSWNvXTvJXLusBRD6ZrHnaWAiufiHAxKg+NzihooLx/a Oj8TPXrn5pgnDGD4cPZEEgHxL0UQzac3uJAzvTDs/XbJNW63b7VWVR1NoMERuEf20BfQ PtcyG1tvk9yxAs5xfA56BAoz4aCJ8g7DHbPu8qMfuCzsH4Au3U+xn/MYmlIB3TjjbyyU Ud48RocpUILddLWwOMOdKTsZ07fI4mqSq4cW+0wZbQkHWSmS8E8KHtmy47F79Jlzu6EZ iEmwU4KhVO/MxC5OdwYFjP0NEws6pnAV4MAyUt7uUuNwRd6k4mW89Np+HUJgXozCMBfw Je+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=QmKQN1M3UQJWU4PcSnftSIcqpwpLoaBdyhFDrBASu9Q=; b=WJ1bxTxAMNeI+jfAlsBL5AB414gVqAqn8LaDLJb+0+2hU0CmN7YcO4n5+ioQEYFcB1 oaALJ8fX9tJqDAShPNV04tUYogf1sc94sXYWv7OdMg1yY4D3nY9Kt9uS/VQSOfPxujpk +8jhjw3lqwAEnagl+2uuSoie3ZC9FSI3WANBReygCN+OQq8+aqRpVIm9PYAzsEFwlXRq UI6HIPhxUzl+olqn6c0LgyGHyLhU8+xIiEGLswnkvLJY/Qo0eqdwbVAKIjIODiylEQdM NcJUmk9kVN9xRmmH/DgAFkFU5VLmQTcQ2slj/T7GwlXxuY9gmA/wmyJYwEfjThcOY2hT ifnA==
X-Gm-Message-State: AOAM530KBe3CCvAG26LplgUBEQ12idya4GRJSz4GRbndf0/qpdk6A/57 uUa7sZ38k0zJA8VnF81J7FxnzUg+B0I2SQ==
X-Google-Smtp-Source: ABdhPJwjwdWb3FbRVXZ1p1rHe+1YE8NPrWXEcuNa6PvTgCpiXJ66dSKl/uQznj3A/Ab/1OCehlcRcA==
X-Received: by 2002:a17:90a:664c:: with SMTP id f12mr3906309pjm.94.1606846049697; Tue, 01 Dec 2020 10:07:29 -0800 (PST)
Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id y19sm422256pfp.211.2020.12.01.10.07.28 for <dmarc@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Dec 2020 10:07:29 -0800 (PST)
To: dmarc@ietf.org
References: <e9166148b9564102a652b4764b4f61ff@com> <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <b0f72407-81ce-9990-4a5b-7b0e5b76e3d7@mtcc.com> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> <CABa8R6sV0x8wWmggp98JfXz8jh0GfAmZ+tNkvqnMPnVK534uPQ@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <8353c6ab-adac-d0c2-a809-1384aac9b39f@mtcc.com>
Date: Tue, 1 Dec 2020 10:07:27 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <CABa8R6sV0x8wWmggp98JfXz8jh0GfAmZ+tNkvqnMPnVK534uPQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------CF703D79931BD969D5951E0D"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/cRnXmv1Fb7Hu_B9j5hu7GAEecVY>
Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions
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: Tue, 01 Dec 2020 18:07:33 -0000

On 11/30/20 8:56 PM, Brandon Long wrote:
>
>
> On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely <vesely@tana.it 
> <mailto:vesely@tana.it>> wrote:
>
>     On 25/11/2020 20:16, Michael Thomas wrote:
>
>     > When I was at Cisco, with l= and some subject line heuristics I
>     could get
>     > probably like 90+% verification rate across the entire company,
>     a company that
>     > uses external mailing lists a lot. Definitely not 100% though.
>
>
>     DKIM itself is not 100%.  You always have lines beginning with
>     "From " or
>     occasional autoconversions.
>
>     l= doesn't cover multipart/alternative nor
>     Content-Transfer-Encoding: base64.
>     In addition, the DKIM spec discourages its usage and suggests that
>     "Assessors
>     might wish to ignore signatures that use the tag."
>
Nobody said it can fix everything. It's just that those things are in 
the long tail. And that admonition sounds like it crept in there after 
rfc4871 when i wasn't paying attention. i find that a ridiculous 
overreaction and begs the question why.

Being able recover 90%+ signatures going through mailing lists made our 
scheme of spear-phish alerting very close to viable. We never got to the 
point of having to make that call because there was just too many crufty 
email servers in the company that didn't use the centralized email path 
to insure their messages were signed. That had nothing to do with 
whether our scheme could work or not.


>
> Right, some of the other dkim-light or diff concepts we discussed 
> would be better than using l=
>
> We again got hung up on the 100% solution, though... something that 
> handled subject-prefix and
> footer in a transport agnostic way might have worked. The fact that 
> DKIM isn't transport agnostic
> is an achilles heel to even that, though, since we'd have to come up 
> with a new canonicalization
> and get it to widespread adoption before the simple diff could work.  
> Or require mailing lists to
> be a lot more strict in how they do their email rewriting, but I 
> imagine that's harder work than
> even ARC.
>
>

Frankly all it would take is a google or another large mail provider to 
publicly state that unless a mailing list supports BCP XYZ, your mail 
will be subject to very strict scrutiny and likely not delivered to get 
the attention of mailing list providers. That was my suggestion back in 
the day but it was scoffed at because people could point to some edge 
case that generates .001% of list traffic and thus invalidating the 
entire approach. The best is definitely the enemy of the good here.

People really need to keep in mind that service provider email is not 
the only game in town. That point keeps getting lost.

Mike