Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication

Alessandro Vesely <vesely@tana.it> Wed, 12 June 2019 08:54 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 20E7B1200C5 for <dmarc@ietfa.amsl.com>; Wed, 12 Jun 2019 01:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 bL3ScMWpDIbR for <dmarc@ietfa.amsl.com>; Wed, 12 Jun 2019 01:54:48 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BBA1200BA for <dmarc@ietf.org>; Wed, 12 Jun 2019 01:54:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1560329686; bh=bNc0CJ34OuMWjICzpOh4ujbjkNcUyzbzPjHU7C81G5A=; l=1790; h=To:References:From:Date:In-Reply-To; b=AYrRlbQx2DXvj2OM5mpUPyZzxsdq21KIs1DD/O09noSfOpEK65OHfs52IxfkUf3gm JFI6LIfwMNYfEU5egLPg7seYlu0sdkLXfyFJ8FqcGmTZ3lSXorTRser8uUpJE2t0sG FHGpuucmk+MsN90XXpCs+rQcfrwcceGRCQb+N5T2UJBBPkbkHBnhpnoYvm2zF
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 12 Jun 2019 10:54:46 +0200 id 00000000005DC02F.000000005D00BDD6.00003B78
To: dmarc@ietf.org
References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> <5CFFD8F7.9030109@isdg.net>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <d465f99e-04ab-4c2f-0c0c-639d0e775ef7@tana.it>
Date: Wed, 12 Jun 2019 10:54:46 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <5CFFD8F7.9030109@isdg.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/20zsWDN8EoUjRChaZUSbaHa4eeA>
Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication
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, 12 Jun 2019 08:54:50 -0000

On Tue 11/Jun/2019 18:38:15 +0200 Hector Santos wrote:
> On 6/11/2019 11:12 AM, Alessandro Vesely wrote:
>>
>> Section 12.4 seems to have some problems.  The first bullet should be reworked,
>> because it can be understood as suggesting that in cases like, for example:
>>
>>      From: "user@example.org via Bug Tracker" <support@example.com>
>>
>> a _MUA_ should "execute the DMARC mechanism on the domain name found there
>> rather than the domain name discovered originally."  That sounds nonsense,
>> first, because MUAs should rather base on A-R records added by the MX.
> 
> This is what I meant above.  You are proposing a trust concept for the MUA on
> which A-R record to "believe."
> 
> The MUA needs trust on the meta-data headers it sees.  In theory, it could
> trust (with higher confidence) the headers added by the user's mail hosting
> provider or the server the user logged into, or basically the last processing
> machine at the hosting provider.
> 
> Maybe Murray can comment on this, I don't recall seeing a discussion where the
> A-R verifying.domain was tied to some trusted hosted domain we have confidence
> in.  Can the MX or MDA domains be associated with the A-R verifying the domain?


To verify domain hierarchy might be possible, but cumbersome.  Section 1.6 of
the rfc says "valid use of the header field requires removing any occurrences
of it that claim to be associated with the ADMD".  IMHO that is the minimal
requirement.  I find it handy to remove /all/ existing A-R fields[*].  That
way, you can tell the MUA to just trust A-R in the messages retrieved from such
account.

[*] Actually, the server renames them Old-Authentication-Results, so they're
visible when you manually watch the headers.


Best
Ale
--