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

Alessandro Vesely <vesely@tana.it> Wed, 25 November 2020 17:30 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 6AFEA3A1AD3 for <dmarc@ietfa.amsl.com>; Wed, 25 Nov 2020 09:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level:
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=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=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1152-bit key) reason="fail (message has been altered)" 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 g6VesrJ1DIqd for <dmarc@ietfa.amsl.com>; Wed, 25 Nov 2020 09:30:26 -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 18F093A1AD1 for <dmarc@ietf.org>; Wed, 25 Nov 2020 09:30:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606325422; bh=iKLTaEaC5JrQJ2PKAvdwlDOp3w6YZj3ug6V5camTEh4=; l=1627; h=To:References:From:Date:In-Reply-To; b=BD/8bUs2vFCcYmXeSn+dbO1cMomMHXW6WhvlrOYlhPIaczOeXHty4h8c9bRhOceTh iAxDTtpQ26plHDxU38tKCBnakeERpRHgZgYOIpiID7xHfU7XiQtG9Rz7ji6UaIQf1n VqQgweVwAPUi9xQBub79Tf98+l+tPNBoSBp5wshgJWCbNK+a1xLnsS9loykLw
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 00000000005DC07C.000000005FBE94AE.00006ECB; Wed, 25 Nov 2020 18:30:22 +0100
To: "Douglas E. Foster" <fosterd=40bayviewphysicians.com@dmarc.ietf.org>, dmarc-ietf <dmarc@ietf.org>
References: <e9166148b9564102a652b4764b4f61ff@com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it>
Date: Wed, 25 Nov 2020 18:30:22 +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: <e9166148b9564102a652b4764b4f61ff@com>
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/jN507npMuVrcLolIUc7JfNSX92o>
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 17:30:27 -0000

Hi,

On 25/11/2020 13:57, Douglas E. Foster wrote:
> Indirect mail flows are difficult to detect.   SMTP address rewrite is already 
> common practice for forwarding.


Return address rewriting is a Good Thing™, unlike From: rewriting.  I'd welcome 
forwarding my email, even if modified (I'm not a bank).  At the same time, I'd 
stop spam pretending to be coming directly from my server.  SPF -all yields 
such possibility, except that it sometimes stops internal forwarding at 
uncoordinated admds.  My proposed dp=reject would ameliorate spf-all while 
still being more permissive than p=reject.  A midway policy, which tackles the 
"mailing list problem" from the other side.


> More to the point, John's interest is finding ways to increase the trust level 
> for forwarded mail, while your idea says that direct mail is more trusted than 
> indirect mail, which is the problem he is trying to overcome.


Yes, they are two different problems.


> We need to be able to evaluate indirect mail based on both the submitter MTA. 
> and the originator MTA.   ARC gets us started in that direction.   I think more 
> filtering data is needed and am working on a proposal to that effect.


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.


Best
Ale
--