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

Alessandro Vesely <vesely@tana.it> Wed, 25 November 2020 19:11 UTC

Return-Path: <vesely@tana.it>
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 6255E3A15F1 for <dmarc@ietfa.amsl.com>; Wed, 25 Nov 2020 11:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 FfEcYTOfOeU0 for <dmarc@ietfa.amsl.com>; Wed, 25 Nov 2020 11:11:28 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B823A3A15F0 for <dmarc@ietf.org>; Wed, 25 Nov 2020 11:11:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606331486; bh=ekWM7hV/pVzjxu5VpZxk5GF9EVZFZQp9IZf20/BDQKo=; l=2496; h=To:References:From:Date:In-Reply-To; b=BIh2wGgKdbyZL9jNWI/7yZehbKm7L0cvIcgcLNTsSHZnVvGjm5ouS1LHkn9Q7ko/z Kb9IASxNKdggroDJPUwdy7QjmFJ4TsTnSla3VpZBIQ8Lhsyv6HJdz4Ghl3lbLukOty IRbXc78nmu7drW7pTOMs4ZP0qlabs83eU/zNtvh3jGzSZVOlYe7loMgdUCY1+
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0CE.000000005FBEAC5E.00007971; Wed, 25 Nov 2020 20:11:26 +0100
To: dmarc@ietf.org
References: <e9166148b9564102a652b4764b4f61ff@com> <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it>
Date: Wed, 25 Nov 2020 20:11:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/9i9BCt4yfaCJVqcZ0XXDtveOGG0>
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: Wed, 25 Nov 2020 19:11:30 -0000

Hi,

On 25/11/2020 19:24, Jesse Thompson wrote:
> On 11/25/20 11:30 AM, Alessandro Vesely wrote:
>> Without resorting to ARC, it is still possible to validate author domain's signatures directly if the MLM just adds a subject tag and a footer, like, for example, this list does.   While ARC solves "deep" forwarding problems, which may arise in the context of email address portability, MLM transformation reversion solves the simpler mailing list problem, including reverting munged From:'s.
> 
> I agree that ARC isn't really needed to do this (trust the last hop from the MLM and determine the original authenticity from the MLM's perspective)


I didn't mean to trust the MLM.  I meant remove the subject tag and the footer, 
then the original DKIM signature verifies.  See:
https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/


> Plus, if it eventually solves the "deep" forwarding issue, then ARC is certainly better than trying to follow received header chains, etc.


IMHO, that's where the real value or ARC lies.  Large mailbox providers forward 
lots of messages to one another, as set up by users, and they seem to prefer to 
forward messages anyway rather than filter before forwarding.  That's what John 
reported in:
https://mailarchive.ietf.org/arch/msg/dmarc/OmTzwzP9GuE1oF5m1TvUZVA799c


> Anecdotally, after much debate, our team is leaning more towards *not* reverting munged From:'s from our own MLM
> 
> 1. Until ARC has a reputation model that is commonly adopted, header munging isn't going to subside.  I still find MLM operators who are just now realizing that they have to munge messages.  We need to tell users that this is the new, growing, reality.


Yup.


> 2. If we only unmunge for our own domains' users' authoring messages to our own MLM, it has limited overall effect, and it distorts the user-reality story from point #1.  We would have to unmunge for all domains' authors sending to all "trusted" MLMs in order to give the users what they expect from their prior reality.
> 
> 3. Since we can only unmunge for our own recipients, it just creates an inconsistent experience on top of the already inconsistent experience of the conditional munging most MLMs do based on the authors' DMARC policies.


If the original signature verifies, each MDA can restore the unmunged From: 
right before committing to local storage.  That way, the rewritten From: 
becomes a transfer artifact, not seen by users.


Best
Ale
--