Re: [dmarc-ietf] DMARC and ARC

Dotzero <dotzero@gmail.com> Mon, 07 December 2020 11:41 UTC

Return-Path: <dotzero@gmail.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 CA4D03A1341 for <dmarc@ietfa.amsl.com>; Mon, 7 Dec 2020 03:41:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SakqZBGrjOHL for <dmarc@ietfa.amsl.com>; Mon, 7 Dec 2020 03:41:13 -0800 (PST)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 135063A133E for <dmarc@ietf.org>; Mon, 7 Dec 2020 03:41:12 -0800 (PST)
Received: by mail-qt1-x829.google.com with SMTP id z9so9108564qtn.4 for <dmarc@ietf.org>; Mon, 07 Dec 2020 03:41:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T808G1BZNG86EH9JcFkHLh0uyxQRYH9rd7/1JbKrdY8=; b=IfwbkzM0dIYpTAlciqBWU/32rQJBArqmYIpK4dqbmvytQim2M8AIxChNK5CoCz9Jv0 mR9mCeKbWKRxyfomSJN6W0xj1EkqCygpEnjDwzfWNWjM6gvigbWE19z+IrUxJtxKI+Rg xZaDEYgZnhJEAwKDmPc8pVG11j8q/wR1jW5Rg97uy/0NM3wqn1pAfe2OEUj2C9IS04UX ZmWIkJQiwy0B3G9+rno9Ra9OZI/QXwAA1bgI+vnu/Jl29C8JaOr9tlrux417mEnvme5y KjxqZx15CdH9B3ET5Y5WFQjv35353dTs2qunzecGar3QUXfE0B8ShSWqetVQF8gpSvYI Pu5A==
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=T808G1BZNG86EH9JcFkHLh0uyxQRYH9rd7/1JbKrdY8=; b=WEoqDsYPvL83JlWFE/xDph5gsACmCC8zApfDRmfz3jDL1NWVtbui7eAAUNB1RADP/G lirBA/ZrR0mQaCLGBzn82BNHeNcxoyDkWNK5UHr9x3CIu0HfZJbUe/tD62kM0VZwmAhr DnoWpvQoKRAol6u1UfD8S3jZe+Xou1gvXV3LKUKjV3AWnQ0CdNl+lRZYmjnzjSP78rgR BF58g0hkMLoA499dAFj1V0bWBCSsie2HipPSfRJzwpTkUcOfz5nbgp9r51j3qYe5xW7m fBaBe9KXj5tWC3IFJM8oUfiHiB5eVxqdP/1BbcIJZdKUcoh3RDOwViVujx7rpo//4VIL J0yA==
X-Gm-Message-State: AOAM531d6q5pcMtT0QcA/XKCa1SNNkZN0wACcjZcOTCHCd+puaoq7tyk A+mQBnalPVBGnJwzGDPcdS55QZPszrWpl69RUSk=
X-Google-Smtp-Source: ABdhPJx5lFmjLbFb5XzULjuNpyDs58xrpn+NyX0FrAOjT2IDZxZ9G641GtjDX/jOaMPDje96VlDBWEZGpKO1PjPKkxo=
X-Received: by 2002:ac8:5c05:: with SMTP id i5mr23402826qti.34.1607341271843; Mon, 07 Dec 2020 03:41:11 -0800 (PST)
MIME-Version: 1.0
References: <CAH48Zfx1gL-rnqWWaJODi72Sgp6F70Bm_kAYL5rwSmVmopQ9qg@mail.gmail.com> <CAL0qLwbgGvwBiu=MBsbhQ_HRdSQ7jDABgicd1Od_wyLGttp6Ug@mail.gmail.com>
In-Reply-To: <CAL0qLwbgGvwBiu=MBsbhQ_HRdSQ7jDABgicd1Od_wyLGttp6Ug@mail.gmail.com>
From: Dotzero <dotzero@gmail.com>
Date: Mon, 7 Dec 2020 06:41:00 -0500
Message-ID: <CAJ4XoYeB-4QDw2z6cGMgivqtsQHW-QE785YiNnAtJBmqiz1u=g@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: Douglas Foster <dougfoster.emailstandards@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008a864b05b5de4d98"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/9z8nNfh3qStenlYSDmrb11uydeM>
Subject: Re: [dmarc-ietf] DMARC and ARC
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: Mon, 07 Dec 2020 11:41:15 -0000

On Mon, Dec 7, 2020 at 12:15 AM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> On Fri, Dec 4, 2020 at 7:58 PM Douglas Foster <
> dougfoster.emailstandards@gmail.com> wrote:
>
>> First, lets begin with the obvious:   malicious messages come from
>> enterprises that are in the malicious message business.   They rarely send
>> just one message, and their content changes continually.   Therefore, my
>> priority is to block malicious sources.   Messages that are correctly
>> blocked on content, rather than source, are the canary-in-the-mine which
>> warns me that my sender blocks need to be tightened.
>>
>
> I was under the impression from my work in the anti-spam world that
> sources also change.  It's trivial to come from a new IP address or sign
> with a new domain name when I think you're blocking me.  Thus, negative
> reputations are generally not useful to accumulate long term.  On the
> contrary, the thing that's mostly reliable is static sources that have good
> reputations, because they tend to remain (mostly) static, and they work to
> preserve their reputations.  I tend to give them preferential treatment.
>
> If a message is not forwarded, every organization involved in its delivery
>> is assumed to have a relationship to the sender and therefore a shared
>> responsibility for the final product.   DMARC, SPF, and many spam filters
>> assume that the adjacent MTA is the only source that needs to be evaluated.
>>
> This seems overly general.  A message going from A to B to C to me here at
> Gmail means Gmail has a relationship with A?
>
> Forwarding introduces an intermediary organization which presumably
>> operates on behalf of the recipient, rather than the sender.   It is not
>> involved in the creation of the message and has no economic relationship
>> with most of the message sources.   More importantly, because it will be
>> forwarding messages from sources with a variety of reputations, the
>> forwarder will be perceived as having a very unreliable reputation –
>> sending both very much unwanted content and very much wanted content from
>> the same or overlapping identifiers.   SPF and DMARC force the forwarder to
>> reliably identify itself, but in this process, they force the forwarder to
>> hide information that the receiving MTA needs for proper message
>> filtering.  This aggravates any effort to filter based on original-source
>> identity.
>>
> I'm also confused here, because it's ambiguous what you mean by
> Forwarder.  Some forwarders simply replace the envelope and send the
> message on its way with no body modifications and only trace header field
> changes.  They don't meet the definition you're describing because no
> details are hidden.  Others, like MLMs, may mutate the message and re-post
> it, but I would argue that's not forwarding, that's a new message; the list
> is the originator.
>

If there were truly a consensus on the list being the originator then the
>From would/should be from the list domain and a lot of the list as
intermediary issues would go away. As past discussions have shown, there is
not such a consensus.

Michael Hammer