Re: [dmarc-ietf] Sender vs From Addresses

Hector Santos <hsantos@isdg.net> Wed, 24 March 2021 18:17 UTC

Return-Path: <hsantos@isdg.net>
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 230D83A327C for <dmarc@ietfa.amsl.com>; Wed, 24 Mar 2021 11:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=MrcN30TL; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=UBqaUxuO
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 2YCD0aaluGgJ for <dmarc@ietfa.amsl.com>; Wed, 24 Mar 2021 11:17:19 -0700 (PDT)
Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (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 4CE573A3279 for <dmarc@ietf.org>; Wed, 24 Mar 2021 11:17:19 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2341; t=1616609833; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=0Q1a9yNgsqvQgXrF4LsiCrjGpER4 abve4cdFkLBdyg4=; b=MrcN30TLWgo3TfKkg9GO//l26uvcYp/vwTJcHzYAeB2s 9NeaiubfndOCz3bI9ZDvwvekebK24ERs6wuTHxDR35nMpTzshvKI9s5kzNOWtvCs y+JSBWKo4P5ST1smXJlfjeKa7LpAQ36pOnZzaL8jxerAM5ENx1hq17KyJLz+1cs=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 24 Mar 2021 13:17:13 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 643023985.19922.3896; Wed, 24 Mar 2021 13:17:12 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2341; t=1616609839; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0Q1a9yN gsqvQgXrF4LsiCrjGpER4abve4cdFkLBdyg4=; b=UBqaUxuOiQmyOhL9g4i2fVq B2PviU8sS2otUUtm3qH+tjTiOebZ1/jp/MKB19TsN+cty7Cf9f661T81QVDfwnX/ XWc8XvoYEHprGDM4uKkQWXoQbcDOuHBKaOBqCPS3lWU99Bw95bK9VfdjsCZquMhp YxeQEXVzM5ok5Hn5reqs=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Wed, 24 Mar 2021 14:17:19 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1326683300.1.60612; Wed, 24 Mar 2021 14:17:18 -0400
Message-ID: <605B8229.8050608@isdg.net>
Date: Wed, 24 Mar 2021 14:17:13 -0400
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: Dave Crocker <dcrocker@gmail.com>, Ken O'Driscoll <ken=40wemonitoremail.com@dmarc.ietf.org>, Charles Gregory <Charles@possumdelight.com>
CC: IETF DMARC WG <dmarc@ietf.org>
References: <6cacad89cb2049858938fce107d60dd9@possumdelight.com> <VI1PR01MB7053E1ED6ED09791428D6EE4C7639@VI1PR01MB7053.eurprd01.prod.exchangelabs.com> <03a570ad-c66a-c7b7-29d6-28ba6edab459@gmail.com>
In-Reply-To: <03a570ad-c66a-c7b7-29d6-28ba6edab459@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/K90368eCkiwAvzNkNfmvsb_uWtc>
Subject: Re: [dmarc-ietf] Sender vs From Addresses
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 Mar 2021 18:17:26 -0000

On 3/24/2021 1:26 PM, Dave Crocker wrote:
> On 3/24/2021 4:54 AM, Ken O'Driscoll wrote:
>> There is actually an existing working group draft discussing 
>> extending DMARC to incorporate the 5322.Sender header, see 
>> https://datatracker.ietf.org/doc/draft-ietf-dmarc-sender/. That 
>> document goes into considerable detail on how 5322.Sender could be 
>> incorporated in the future.
>
>
> To be possibly overly frank, I think the draft is stalled.� Given 
> existing practice, there are challenges to fielding this, for 
> incremental adoption, in a way that is reasonable and useful.� (The 
> Internet does not support 'flag' days.)
>
> I am still, sometimes, mulling over the choices for this, but so far 
> haven't come up with (or seen) ways to resolve the challenge.
>
> An option the working group declined to pursue is to define an 
> Author: field and leave the From: field to the 'handling' role DMARC 
> has relegated it to.� The draft for this is being pursued outside of 
> the working group.
>
>

As I as always said with all our decision points, like this one -- if 
we are changing a well-used protocol, still in informational state and 
we are seeking a standard track, we need to provide more options. With 
all these rough decision they are ideal for making it optional.  So if 
you want a particular operation to expose a public policy that says 
"Sender" is in some formal protocol language way, is more important 
than "From" then there is no reason why we can not define those 
protocol rules.  But right not, DMARC is too limited. We must exploit 
and expand section 3.1.3 for advanced DMARC methods:

3.1.3.  Alignment and Extension Technologies

    If in the future DMARC is extended to include the use of other
    authentication mechanisms, the extensions will need to allow for
    domain identifier extraction so that alignment with the RFC5322.From
    domain can be verified.


This is whats holding us back --- trying to "correct" the current 
informational spec WITH words and no protocol improvements whatsoever.

So what is the rule for Sender? I'll support it if it makes sense. If 
sender is used, there SHOULD be some author policy tag indicating so.

-sender=1

means to follow your specs?

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos