Re: [dmarc-ietf] Reversing modifications from mailing lists
Douglas Foster <dougfoster.emailstandards@gmail.com> Wed, 24 November 2021 12:11 UTC
Return-Path: <dougfoster.emailstandards@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 8B2A93A0DF2 for <dmarc@ietfa.amsl.com>; Wed, 24 Nov 2021 04:11:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 FgfqbgWZCwRD for <dmarc@ietfa.amsl.com>; Wed, 24 Nov 2021 04:11:27 -0800 (PST)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 066043A0D79 for <dmarc@ietf.org>; Wed, 24 Nov 2021 04:11:26 -0800 (PST)
Received: by mail-ot1-x32e.google.com with SMTP id h19-20020a9d3e53000000b0056547b797b2so3905134otg.4 for <dmarc@ietf.org>; Wed, 24 Nov 2021 04:11:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Z5WN69K59tAvG+87P1ylARPU7/EtlyRAWP8lWy+yXMs=; b=DhOthfHa2PmNdFeQPQf0L0kfesePddFsGJwTZXmFznzh0Gy9AIo2kuGDxAA+0Z3OIR qWV5vAwwQBSMGkNLrpYkEC4MKKv7/sGtBv+P1bg4wxsC0Np23Y4j2mXydtNDe13XpAzA vNtPvCmBtBllgpFO2B7kOa4PO1dOpEQIlBoL3KZui5zASnfCyPBbF7UKJMn/o5CLe2+8 PlC2EgIaYhpNF2QKI4UI+Z0g/mT/rfuGo6ZXTZv71OwE5d4tTpsWrRCo2Hr/nRdzpOgR nGG+5LF9hq7BlVs9s4tEEZmDMglcE3Ec7PFFuY+VQ8cmliEvTxkyACTjhx/00t+QfkCJ eErA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Z5WN69K59tAvG+87P1ylARPU7/EtlyRAWP8lWy+yXMs=; b=Mzrnj7ZY98KXoXYo2Dsbqx1aP6Lrd2XZkqe6l6HZawZO4q10hR6b4yoKY3gMVtsBJU iaFH/yCE8nI0J/ZUTW9nY4i1tpK5qbjT4nJBIdXPam17W+52kWwqHE2AxTBFCkaUMReg 2krraE0Ll2u7SrXQnfY+ImD6bdwoxbpWljtm30RfYj/KAU+NXOM5mEZhkE9Ujig6YV5l 3QErdyJVZCPbYNy67BlDVWPfbCweF3fj8JDgNmYs/MXpLkYjHc2/5iX1LjlfdccD0CQm Okxcl4dG9lt330Aqo3DEyhHBzLZPAMVIbUJwKZfURIYGPrTaFi2+55Vx7DkFPUaVDluK aaRQ==
X-Gm-Message-State: AOAM531hmluOqXkk2JM2zmxtY6AWA2EHarSQc9Yf3nkCd+uu4KarSA9c 8SbvdHimBgYLyFQAdhoBIwW87CyjYJsuBsZayE4NFVaV
X-Google-Smtp-Source: ABdhPJzj/gkgD98fudu8PUd9aEmT+e+BsE5tiEwb5TMwdL2AI1NCj+Ha/Uhw3AP0gi7d2UDGECkGfv+4upwjBTuO+/U=
X-Received: by 2002:a9d:7596:: with SMTP id s22mr12212039otk.153.1637755885010; Wed, 24 Nov 2021 04:11:25 -0800 (PST)
MIME-Version: 1.0
References: <CAAFsWK3qshdYDeeTOLPJEnk=gHFrRp==QJLvoG6RAYHau6Fy8g@mail.gmail.com>
In-Reply-To: <CAAFsWK3qshdYDeeTOLPJEnk=gHFrRp==QJLvoG6RAYHau6Fy8g@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Wed, 24 Nov 2021 07:11:16 -0500
Message-ID: <CAH48Zfxsk0Ne3KVMznZOYod95mpN2vK=z9h0kndqccsJnsz1Ew@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c1444505d187c170"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/mXjynQsSNrjJQtIoqA2kMc3Yhz8>
Subject: Re: [dmarc-ietf] Reversing modifications from mailing lists
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, 24 Nov 2021 12:11:32 -0000
If you are evaluating messages, you are free to use any strategy that seems worth your effort. However, if you are the sender of messages that cannot produce DMARC PASS, you have a bigger problem. You need an algorithm which can be trusted to usefully distinguish between malicious and non-malicious senders, and has an expectation of widespread implementation. I don't think such an algorithm exists. For the evaluator, we need to consider diminishing returns on effort. First, I discard any messages from senders with bad reputations, then I discard messages with bad content, then I allow messages that pass sender authentication. What is left is a set of messages which have no visible problems but which might (or might not) represent malicious impersonations of a legitimate sender. How much additional processing power is required to achieve how much improved decision-making? It might be useful to parse the RECEIVED chain to look for known-bad IP addresses or DNS names, but it is not an easy algorithm. It might be possible to develop a reliable NP rule that blocks messages with domain names that are unregistered or not used for email, but we are not there yet and those messages are likely to be a small subset of the problem. Attempts at additional granularity will encounter problems like "Can I reliably identify messages that were forwarded?" and "Can I reliably identify messages that come from a mailing list?" Not easily. Of course, one can choose "Always Block" as AOL has done, or choose "Always Allow", as I suspect many others have done. Neither approach is optimal. At some point, the best answer comes from actually looking at the message to answer the question, "Is this a message that I want?" Once an answer is obtained, I need to create a local policy rule which implements my answer for all future messages that have the same fingerprint. We have never described the exception process, and as a result many products have exception mechanisms that are inadequate and inappropriate. I believe that a document which describes the exception process will be the best that we can do and will be a big step forward. I have begun experimenting with drafts, but am not ready to submit one yet. Doug Foster On Mon, Nov 22, 2021 at 6:28 PM Wei Chuang <weihaw= 40google.com@dmarc.ietf.org> wrote: > Hi all, > > [Standard disclaimer, that the comments below are my own and don't > represent my employer at all] > > I saw Ale's draft draft-vesely-dmarc-mlm-transform > <https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform> > in the ARC list, and wanted to discuss some of the ideas. Just to put in > context my points- My understanding is we have to trust the forwarders to > use the ARC authentication results, which we might not have because the > forwarder is new, or has low volume. Moreover mailing lists do much of the > modifications that break DMARC. This is a common enough scenario that I > think it's useful to consider alternatives such as the ideas found in Ale's > draft. The numbered bullets are ideas summarized from Ale's draft, and > asterix * bullets are my comments about that. > > 1. Ale's draft suggests not reversing all possible transforms, and rather > focuses on a subset caused by mailing lists that are reversible > * Could ARC be suitable for those other scenarios? Could we expect that > forwarders that do more substantial irreversible rewriting such as > modifying URLs in a spam/phishing filter MTA, already have a strong > relationship with the receiver? Presumably, might they be trusted by the > receiver and their ARC result could be used? > 2. Footers must only be added with as a) append on single text/plain part > b) mime part appended to multipart/mixed c) mime wrap where a footer is > added in a new multipart/mixed. > * It's not very clear to me how Ale's draft handles the b) and c) > scenario. (There is mention of "reason="transformed"", but this still > seems incomplete) I saw that Murray has a draft > draft-kucherawy-dkim-list-canon > <https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon> that > identifies addition of new mime parts that could be helpful there. > 3. Footers added to text/plain must be identified with at least four "_" > as a separator. > * Would the DKIM length "l=" field be helpful? Understood there are > abuse risks. > 4. "quoted-printable encoding must not be used for... single-part > text/plain messages, as it is impossible to guess original soft line breaks > after re-encoding" > * Are you suggesting quoted printable encoding aren't fully > reversible? Actually, could the RFC2045 canonical encoding of the message > be used as the source for doing the DKIM content hashing? This would > bypass having to worry about additional transfer re-encodings by > forwarders. > 5. Finding the original FROM by looking at From, Author, Original-From, > X-Original-From, Reply-To, and Cc. > * Can this be standardized to a fixed location such as Author? (Sorry > I'm unfamiliar with the discussion on Author) > 6. Subject > * Agreed that some simple heuristic as proposed in the draft is a good > approach. Perhaps the original subject suffix length also might work here > too. > > Comments and discussion are very much welcome. > -Wei > > > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
- [dmarc-ietf] Reversing modifications from mailing… Wei Chuang
- Re: [dmarc-ietf] UNCOL and Reversing modification… John Levine
- Re: [dmarc-ietf] UNCOL and Reversing modification… Alessandro Vesely
- Re: [dmarc-ietf] Reversing modifications from mai… Alessandro Vesely
- Re: [dmarc-ietf] Reversing modifications from mai… Douglas Foster
- Re: [dmarc-ietf] UNCOL and Reversing modification… John Levine
- Re: [dmarc-ietf] Reversing modifications from mai… John Levine
- Re: [dmarc-ietf] UNCOL and Reversing modification… Alessandro Vesely
- Re: [dmarc-ietf] Reversing modifications from mai… Alessandro Vesely
- Re: [dmarc-ietf] UNCOL and Reversing modification… Baptiste Carvello
- Re: [dmarc-ietf] UNCOL and Reversing modification… Douglas Foster
- Re: [dmarc-ietf] Reversing modifications from mai… Wei Chuang
- Re: [dmarc-ietf] UNCOL and Reversing modification… Wei Chuang
- Re: [dmarc-ietf] UNCOL and Reversing modification… John R Levine
- Re: [dmarc-ietf] Reversing modifications from mai… John Levine
- Re: [dmarc-ietf] Reversing modifications from mai… Alessandro Vesely
- Re: [dmarc-ietf] Reversing modifications from mai… ned+dmarc
- Re: [dmarc-ietf] Reversing modifications from mai… Wei Chuang
- Re: [dmarc-ietf] Reversing modifications from mai… Dave Crocker
- Re: [dmarc-ietf] Reversing modifications from mai… John Levine
- Re: [dmarc-ietf] Reversing modifications from mai… Alessandro Vesely
- Re: [dmarc-ietf] Reversing modifications from mai… John R Levine
- Re: [dmarc-ietf] Reversing modifications from mai… Murray S. Kucherawy
- Re: [dmarc-ietf] Reversing modifications from mai… Murray S. Kucherawy
- Re: [dmarc-ietf] Reversing modifications from mai… Alessandro Vesely
- Re: [dmarc-ietf] Reversing modifications from mai… Wei Chuang
- Re: [dmarc-ietf] Reversing modifications from mai… Wei Chuang
- Re: [dmarc-ietf] Reversing modifications from mai… Wei Chuang
- Re: [dmarc-ietf] Reversing modifications from mai… John R Levine
- Re: [dmarc-ietf] Reversing modifications from mai… Scott Kitterman
- Re: [dmarc-ietf] Reversing modifications from mai… Alessandro Vesely
- Re: [dmarc-ietf] Reversing modifications from mai… John Levine
- Re: [dmarc-ietf] Reversing modifications from mai… Alessandro Vesely
- Re: [dmarc-ietf] Reversing modifications from mai… Wei Chuang
- Re: [dmarc-ietf] Reversing modifications from mai… John R Levine
- Re: [dmarc-ietf] Reversing modifications from mai… Benny Pedersen
- Re: [dmarc-ietf] Reversing modifications from mai… Murray S. Kucherawy
- Re: [dmarc-ietf] Reversing modifications from mai… Alessandro Vesely