Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields

Дилян Палаузов <dilyan.palauzov@aegee.org> Tue, 30 July 2019 13:34 UTC

Return-Path: <dilyan.palauzov@aegee.org>
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 A155C12019F for <dmarc@ietfa.amsl.com>; Tue, 30 Jul 2019 06:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
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 OU0XN-cEXPjo for <dmarc@ietfa.amsl.com>; Tue, 30 Jul 2019 06:34:50 -0700 (PDT)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 405CA1201EE for <dmarc@ietf.org>; Tue, 30 Jul 2019 06:34:49 -0700 (PDT)
Authentication-Results: mail.aegee.org/x6UDYkTF017367; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564493687; i=dkim+MSA-tls@aegee.org; r=y; bh=KhCeJuK5eM5Xj9nGUc7d/5+Sa6bSSEuBquY5JmjJl2A=; h=Subject:From:To:Date:In-Reply-To:References; b=Txkh431rqr7kC60UUOU18eRK9H4Xk2ehUSeXbB1IFY0yelEeDzN5s9dYedEnbwSEf ir4UQsjQOSij7N+dWBO7Yl+8qqRXfCRCe/q5cX8Mr6YroDkW+3Pwg2YTMgSmxn5uA7 GBGNw7qMy9hIC97pKS7u16SnaW0ObyfWsDNwyeRUivE1TodmF2n8NnRPAhhfVt+W6N GmrA8aovoKGgW0xmqlTp3N69qxttNvyd/10uUCxQFBPUmuuv9MgbH0fI6ap9GZeuCT 1xMXjigkw58FqiUrePLGLPwIz0wuj3IDWC0aikDsWYJk7tAh8n/zbC9l2YnC0LByFt JjvOw3EwUaGHEBxlgWe6/xF67WSbCdhnme2d0KA/Ak14rHLp4asU89TLClvCzVQkQY 5hrm6Y4ppMjxhksTD7uCQCO0l28c+dBEtZIRdQhjzDz9i8LmE8xEIa1EejclTjAx/h NERLCGFvJKggMxtgquBiPJP2BXFbVVlwifCT1ANA2DCWAlHn0MGUTqpkTBSWm8V6lm OWtPkYCOPq7/de3lNFDZV7l2p2IVNVx/yG4g8UW5T4JjYfxwo6I9l5ozSsamyNFZ79 GccoYRguA9kZbIJF0Ir5BinXgCuQZLxlX2jId1GE+msKj40OPwmjuRmJI5fjoBmXI0 rrC2/zBciOSsdfNtSg/y0Fuc=
Authentication-Results: mail.aegee.org/x6UDYkTF017367; dkim=none
Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6UDYkTF017367 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 30 Jul 2019 13:34:47 GMT
Message-ID: <ad404895f272ede4a9d0fb7cfb142a65414318d3.camel@aegee.org>
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
To: Scott Kitterman <sklist@kitterman.com>, dmarc@ietf.org
Date: Tue, 30 Jul 2019 13:34:46 +0000
In-Reply-To: <4600949.rz9u5RyGOV@l5580>
References: <2577720.3ZthdXZjm2@l5580> <4600949.rz9u5RyGOV@l5580>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.33.90
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ueQgw2V19z1RL7S0kLqfAStoiVM>
Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields
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: Tue, 30 Jul 2019 13:34:53 -0000

Hello Scott,

do you want to include in the A-R header the published policy, as obtained from DNS (my first interpretation of your
proposal), or the disposition of the message after applying DKIM/SPF/DMARC validation, pct sampling, and the ominous
reject→quarantine sampling conversions?

With disposition I mean what is called at https://tools.ietf.org/html/rfc6591#section-3.2.2 Delivery-Result.

For the disposition on p=reject only the MTA can make the decision based on pct to reject, so it makes sense if the
result of disposition is included in the A-R header by the MTA and consumed by the MDA.  In turn, including pct and
published DMARC policy in the A-R header, so that the MDA can do the sampling, does not make sense.

If you want to call the new parameter “policy”, then it shall be articulated that it means disposition, and not
published policy.

I am in favour of the proposal.

It allows for forwarded emails/aliases to indicate in the A-R header, that sampling was already performed by the
aliasing server, and the final server that accepts the email can skip performing the sampling again.  Performing the
sampling again has the disadvantage, that the pct= parameter is misinterpreted, as the parameter is supposed to be
applied only once.

On the other side, skipping of the second sampling by whatever server is pure theory, and has no practical impact.

Greetings
  Дилян

On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterman wrote:
> On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman wrote:
> > I'd like to add the option to record DMARC results in an A-R header field
> > for consumption by a downstream processor.  I think it would be something
> > like this:
> > 
> > Authentication-Results: mail-router.example.net; dmarc=pass
> > header.from=example.com policy.dmarc=none
> > 
> > That would take adding an entry in the Email Authentication Methods registry
> > for:
> > 
> > method: dmarc
> > ptype: policy
> > value: dmarc
> > 
> > Does that make sense as a way to do it?  Does anyone have alternative
> > suggestions?
> 
> I think comments should be free-form.  If we want data that can be machine 
> parsed, we should specify it.
> 
> I think the above works in ABNF terms.  It's:
> 
> Authentication-Results:" authserv-id; method=result ptype.property=value 
> ptype.property=value
> 
> According to the ABNF, there can be more than one propspec 
> (ptype.property=value) per methodspec in resinfo, so I think it's legal.  It 
> would just need the new registry values for dmarc.
> 
> Scott K
> 
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc