Re: [dmarc-ietf] ARC questions
Michael Thomas <mike@mtcc.com> Thu, 26 November 2020 00:52 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 E0DDE3A0E49 for <dmarc@ietfa.amsl.com>; Wed, 25 Nov 2020 16:52:35 -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 BDel_ml9l2X7 for <dmarc@ietfa.amsl.com>; Wed, 25 Nov 2020 16:52:34 -0800 (PST)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 020193A0DE0 for <dmarc@ietf.org>; Wed, 25 Nov 2020 16:52:33 -0800 (PST)
Received: by mail-pl1-x633.google.com with SMTP id r2so286422pls.3 for <dmarc@ietf.org>; Wed, 25 Nov 2020 16:52:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=j5+eOemBCuD4uNdQ9bS2v2DmwQX6DGtB9IAFI/Q2xbk=; b=XaR0VL44CXcohbBoDfBsHqBt3Rn77O6k9Dt5DXAQyxpkwBLTw1HtlPQ/Fq0KGhD4Vp ceQBNi+txYvksdUJSnFrVOmS1XrFjPBMxw0SlojekHzS1POiUYyQATFGLFAGKpeNNUv4 w5MfjUOHCOj2jHVtN5VDRcUHyglYY+3mlJfK6yS87jr8Kcvh6f+c9zwr/4s23m8Zi+FH 1O1yYMp0vyjiJOj2TTC8EDlGILIqJPqHIUo3RJM1WydiP7nzpFWt1yAmWtGYrp7eSb2f wzr/WdGWgOPd6/OYaalRz5C9jOwaQ/unOK8FIwKTYvHjno1IdOdgyPdugAUZro7nOy4S Mafg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=j5+eOemBCuD4uNdQ9bS2v2DmwQX6DGtB9IAFI/Q2xbk=; b=Dj0km2xJ55MoPv/HvQiCoOYVUb+AOswYLlqZeGRHYIpUBcc1JQ2s2mi17fxbfY5aeG WaFcZJK+JFZ7HxUf8RIWplbZV1HOEuwGTPLB05msG38EYMPsWuw5Mo96acJIw+D7x68j hycDdhc4NSRhDRIzPxlP+Qp0xkXhKYEYftOangzhLdn8ksMXCN/AYe2w/3H7FIDRnhT9 KtYS9531vuzpFJxB7nFSjtcbo9LZE/YWzHbNgSiQGTQWX4qg/adYzt6UB5P9WPDdxdYE t3UoD04kSLpEgsCdr1eHLZjTR0HPd8n/kqVr7TTvjk6w8nxVA7RoWQEO+dwYNWqsUmgL KOxA==
X-Gm-Message-State: AOAM532hOTZItRw0vuVELDlIO87iCR+57poH8Ujl9aFbtOANzzS3/gLL u/ttdqf6IMvCkw4fEqsSXO1NXBz3UsMczA==
X-Google-Smtp-Source: ABdhPJym2buVXTiahURVz4Jmz90Hp0KzjTO2CCGcB0SfnOPdjkeIAYM2JxKSmgpHvVGjZQih1DDxHw==
X-Received: by 2002:a17:902:b90a:b029:da:655:4208 with SMTP id bf10-20020a170902b90ab02900da06554208mr555804plb.30.1606351952927; Wed, 25 Nov 2020 16:52:32 -0800 (PST)
Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id y5sm4153018pjt.42.2020.11.25.16.52.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 16:52:32 -0800 (PST)
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: Douglas Foster <dougfoster.emailstandards@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
References: <20201124020453.AFDC027CE5C8@ary.qy> <cd855b53-d9bd-3412-3bd5-dc4b7720dc5c@mtcc.com> <CABa8R6s0bfs87Fu9eOq_R3WH1pngauVXrw3RSPe9iWWCtf3AmQ@mail.gmail.com> <c954eadd-5c85-c0d9-2168-8a42de506b72@mtcc.com> <CAH48Zfx25_o+-j0=mEA6ib=2aKPqBDihA4rt0c9_vE+570Q+TQ@mail.gmail.com> <CAL0qLwY3fc+YP-Pw1k2XJgOM0cU1W9AhuPD+kouh8Ns9UzW_HA@mail.gmail.com> <e39252f5-12d1-cdfa-5413-30cfbf2b8a4b@mtcc.com> <CAL0qLwZzg_MzX1cRe8pYZnLQovaBZJtCuUPMZpkt+TKtc=4K7w@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <2347b5dd-54b8-a042-a435-b64c4e54d3bb@mtcc.com>
Date: Wed, 25 Nov 2020 16:52:30 -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: <CAL0qLwZzg_MzX1cRe8pYZnLQovaBZJtCuUPMZpkt+TKtc=4K7w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------AE311FBA35222659A57C80E4"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/0P4X1g9oTGWjovgDlM6fTXcj2Nk>
Subject: Re: [dmarc-ietf] 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: Thu, 26 Nov 2020 00:52:36 -0000
On 11/25/20 4:14 PM, Murray S. Kucherawy wrote: > On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas <mike@mtcc.com > <mailto:mike@mtcc.com>> wrote: > > > That's been known for over 15 years. I'm still trying to > understand the assertion that DKIM signatures are a "bad fit". I > just looked at a random message off of this thread and they look > identical except for the i= field. another field could trivially > be added to DKIM and auth-res -- since unknown fields are supposed > to be ignored -- if this binding property is absolutely needed, > which I remain unconvinced by as well. > > I'm not sure about "bad fit". The original plan was to have an > Authentication-Results (AR) clone called > Original-Authentication-Results (OAR) which was specifically the AR > content generated at the first non-submission MTA. There was some > friction (mostly from me, as I recall) about having two header fields > with identical syntax and nearly identical semantics. There was > further complication in the fact that one ADMD could apply multiple > ARs on a single message (for multiple methods, or multiple instances > of the same method, or a combination of those), or they could be > reordered, etc. To make it more resilient, things like instance > numbers were added. The work was eventually generalized to be a > "chain of custody" sort of model, and in doing that I think the > decision was made to make a new name to ensure ARC and DKIM would be > processed differently. But what about DKIM? And why do they need to be processed differently? When I first saw this, I looked at the ARC-Signature which looks identical to a DKIM signature (i didn't notice the i= at the time), and am like what is this? The i= counter could be trivially be grafted onto DKIM if it were needed, which I'm still sort of dubious (though it is a nice to have feature, I admit). That way you only need a single DKIM signature with the OAR's signed. As far as I can tell, that would fall back gracefully for non-implementing DKIM verifiers. Do you disagree? > >> If you ask me, part of the experiment should be able to show use >> cases that DKIM + auth-res (or maybe old-auth-res if needed) >> CANNOT address that ARC can, and most especially what percentage >> of email traffic we're actually talking here. As far as I can see >> ARC doesn't bring anything especially new for the mailing list >> kind of use cases since it really easy to see who the >> intermediary was that broke the signature. I have been told there >> are some vague other kinds of use cases but is unclear whether >> those use cases actually happen before or after the message >> arrives at the front door of the final receiving domain. Yes, i >> read section 7, but it doesn't tell me why this can't be handled >> with current technology. > > Obviously it's too late to include this in RFC 8617, but those would > indeed be interesting data to have. Yeah, quantifying the problems kinda seems like the first order of business if you ask me. I mean, how many of these scenarios are in reality goofy self-inflicted wounds? I can't say but there seems to be a lot more "this can happen" than "this is how often this happens" from what I've see thus far on this thread. > > When you say "easy to see", do you mean for software or for humans? Software. Only software can pry apart that ball of header spaghetti. But I think with the simple a mailing list it is pretty easy to determine, which now that I think about it I actually did back in the day when I was experimenting with recovering mailing list modifications. It didn't occur to me that that was supposed to be hard. > It seems to me that the lynchpin is whether I trust the domain > that broke the signature and resigned. That's either a previously > solved or unsolved problem depending on your perspective. If I > trust the intermediary domain to not send me spam via reputation, > I forward it along to be delivered and ignore the DMARC record. > Why do I care whether it originally validated from the sending > domain or not? If you ask me, that's the intermediary domain's > problem since they have an incentive to keep their reputation and > not send spam through. > > Suppose you're sending to a list that I'm on, I enforce DMARC, I trust > that MLM not to send spam via reputation, you have a good reputation, > and you publish a DMARC "reject" policy. That means if a bad actor > sends a message to the list as you but doesn't sign it at all, I'll > still accept it because I trust that MLM even though according to your > policy request, I should bounce it. ARC provides the missing data I > need to enforce your request. Sure, but the easier answer: to use my mailing list, you must have either DKIM, SPF or both. Sounds like a good way to not be essentially an open relay. Don't mailing lists have those sorts of policies these days? I would say that ones that don't probably shouldn't have good reputations since they are, in effect... open relays. Mike PS: it's been, what, 15 years since our interop, partner? :)
- [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John Levine
- Re: [dmarc-ietf] ARC questions John Levine
- Re: [dmarc-ietf] ARC questions Kurt Andersen (b)
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Douglas E. Foster
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Douglas E. Foster
- Re: [dmarc-ietf] ARC questions Joseph Brennan
- Re: [dmarc-ietf] ARC questions Todd Herr
- Re: [dmarc-ietf] ARC questions Dave Crocker
- Re: [dmarc-ietf] ARC questions Doug Foster
- Re: [dmarc-ietf] ARC questions Dave Crocker
- Re: [dmarc-ietf] ARC questions Todd Herr
- Re: [dmarc-ietf] ARC questions Dave Crocker
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Dave Crocker
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Dave Crocker
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Dave Crocker
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John Levine
- Re: [dmarc-ietf] ARC questions John Levine
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Dave Crocker
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Dave Crocker
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Dave Crocker
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Dave Crocker
- Re: [dmarc-ietf] ARC questions John Levine
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Seth Blank
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Douglas Foster
- Re: [dmarc-ietf] ARC questions Murray S. Kucherawy
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Murray S. Kucherawy
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Murray S. Kucherawy
- Re: [dmarc-ietf] ARC questions Alessandro Vesely
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John Levine
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions John R Levine
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Michael Thomas
- Re: [dmarc-ietf] ARC questions Benny Pedersen
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Brandon Long
- Re: [dmarc-ietf] ARC questions Michael Thomas