Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

Дилян Палаузов <dilyan.palauzov@aegee.org> Tue, 08 December 2020 11:24 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 F415C3A0BF5 for <dmarc@ietfa.amsl.com>; Tue, 8 Dec 2020 03:24:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 HTmBjtkNXxdv for <dmarc@ietfa.amsl.com>; Tue, 8 Dec 2020 03:24:50 -0800 (PST)
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 F3FE73A0BF0 for <dmarc@ietf.org>; Tue, 8 Dec 2020 03:24:49 -0800 (PST)
Authentication-Results: mail.aegee.org/0B8BOQjL767092; auth=pass (LOGIN) smtp.auth=didopalauzov@aegee.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1607426675; i=dkim+MSA-tls@aegee.org; bh=+n7FwivVD5rW1Js48OYwrp+1QgIKj/fU4wOSpqUnHG0=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=IJTagKFN/gu17qlYGRKqz8wv/44YQJj/cQzlXRao/iU3IEn+6S1qXRWvLnCvyvIC+ 7NdYbs43v1FisYpRGJoEn4lexUXGp4ee4MujNVgnfPA61DWxt7Y0BijqeEhQaxpLl9 hUg4pJjj+qK+FxsBWy0pnuoWJVv7Vi6j+4q+UiBhKRIrPsr9ZDTqIzG0VNjyXkaECu iymADzrnMdsILjcipO/BFa35r7ZHk+hGNYiXQzcSNa0U091IqL2u3Wk3qCk5/rC7es 5SR2wVjlf6Qp1nhbY1Vm0oSzRsjEvMUD9textkqx6rO3dLPR5TA7PQNii08tJRL6lW lLdpUQHCs2ghv2UJC8072FO1Q7tB2Exb3h7Z/JGrHSFHFt/UpY10EqDAsg1G5mO07u CRuiJjZmJZ9N8x8C5WUjTkWCBTkLNNUWCd0s1pD8B2XoyQaqlQqkUkc3DtguzhPWm0 0wzv5GGjb5vsJrUgvfVDDChv8z93hWTaBKEZ2PhHhc/Pu+X2MNCDWkgLvwZd9ks3W/ sdsYAlbRnT4lScFFcUR3hRJrPTIfGf/Uh7KotazMLBwEWO7/oCNMDHGCDtlnX5sp9u NLIDK0Z+TqGlUE/TUWpr6mjFM8TrCfF8lDo2cPKo+lPRdZjHjMmRXBt4DJWPWUees2 iI/UNJB856xa3HQihlk0FE/s=
Authentication-Results: mail.aegee.org/0B8BOQjL767092; dkim=none
Received: from [192.168.1.99] (87.118.146.153.topnet.bg [87.118.146.153] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id 0B8BOQjL767092 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 8 Dec 2020 11:24:27 GMT
Message-ID: <1ddcc797fb34a9d45b9467a7a86c49751e013561.camel@aegee.org>
From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= <dilyan.palauzov@aegee.org>
To: Brandon Long <blong=40google.com@dmarc.ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>, Dotzero <dotzero@gmail.com>, Benny Lyne Amorsen <benny+usenet@amorsen.dk>
Date: Tue, 08 Dec 2020 13:24:24 +0200
In-Reply-To: <CABa8R6uTadmZ-O23w-c3qMHmhofnsuB68_ski8-Q0OFDuQYZmw@mail.gmail.com>
References: <20201202021651.E8EE128C576A@ary.qy> <327860af-2fa7-63ee-4b89-6e7e383f3d53@crash.com> <2804da89-84d1-f601-9425-0b0d9baf6ae1@gmail.com> <1f6cae74-4eed-47f5-7249-e526bf1f5845@crash.com> <df11af30-2c27-0d69-97ba-bc058116c044@gmail.com> <87y2ig9t9i.fsf@orion.amorsen.dk> <CAJ4XoYeZXKKZpvtT2FcYouSsNur7=6d0PqSRnErVPQw6zCMW_A@mail.gmail.com> <CAL0qLwb=Vo63Q74r8N31STxbE2YN4+TMq_=yjr+cdMEJQ0m6Mg@mail.gmail.com> <CABa8R6uTadmZ-O23w-c3qMHmhofnsuB68_ski8-Q0OFDuQYZmw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="=-jz9tM/IdWIEWr2u/ytDj"
User-Agent: Evolution 3.39.1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/TB5NdBtGp_0RwUPXq6LLTzknigk>
Subject: Re: [dmarc-ietf] Ticket #39 - remove p=quarantine
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, 08 Dec 2020 11:24:54 -0000

Hello,

I do no see the point of having all the discussions here, as nobody is
capable to read and understarstand all written emails in their whole
quantity.  I personally do not follow the discussions anymore, apart
from reading the subjects…

On Mon, 2020-12-07 at 17:55 -0800, Brandon Long wrote:
> 
> 
> On Wed, Dec 2, 2020 at 11:09 AM Murray S. Kucherawy
> <superuser@gmail.com> wrote:
> > On Wed, Dec 2, 2020 at 6:47 AM Dotzero <dotzero@gmail.com> wrote:
> > > p= DID NOT mistakenly choose to use the language of receiver
> > > actions. p= represents the domain-owner request to the receiver
> > > as to the disposition of messages which fail to validate. Any
> > > reading of "concern" is supposition on the part of yourself or
> > > other self appointed interpreters of the mind of the domain-owner
> > > or administrator. The vocabulary is perfectly fine as it
> > > accurately describes the request being made. It makes no attempt
> > > to read the underlying reasoning behind the request because,
> > > surprisingly, there is likely to be a wide range of underlying
> > > reasoning behind why various domains publish the policies they
> > > publish. This is an interoperability standard, not a seance.
> > > 
> > 
> > 
> > Not sure I agree.
> > 
> > I have long held a quiet dislike for "quarantine" because that has
> > a particular meaning to milter implementations.  Specifically,
> > milter can render one of several final results about a message, one
> > of which is actually called "quarantine".  It means "park this in
> > the queue indefinitely until a human decides what to do with it." 
> > There's no indication to the operator that such a job is waiting
> > for review unless one goes and looks for such things.  The upshot
> > of this is that quarantining in that environment can become a
> > denial of service attack if I send you enough messages that end up
> > getting handled that way and your queue disk fills, or the queue
> > takes an inordinately long time to process because these have piled
> > up and need to be inspected.
> > 
> > Certainly not all implementers will trip on this (maybe none will)
> > but it's an argument to me in favor of picking a word or set of
> > words that describe what the domain owner thinks of the message,
> > rather than what the domain owner thinks you should do with it.
> > 
> 
> 
> Hmm, reading this thread, I think one missing feature in the dmarc
> spec is passing the expected disposition in the authres header, since
> presumably the evaluation is at smtp time, but the mailbox
> delivery itself would need to know it.  One could use the dmarc=
> names and look up the dmarc policy itself to also figure that out
> with some amount of work.

… and in July 2019 there was a discussion with the subject „Reporting
DMARC policy in A-R header fields“ on this mailing lists.    Below is
an off-list consensensus to put the applied policy in the A-R from that
thread, that was not sent eventually over the mailing list:

From: Scott Kitterman <sklist@kitterman.com>
To: Дилян Палаузов <dilyan.palauzov@aegee.org>
Subject: Re: Reporting DMARC policy in A-R header fields
Date: Wed, 31 Jul 2019 10:49:32 +0000


I agree with your statement.  MTA does the percentage test and puts the
policy to be applied in A-R for the MDA to consume.

I'm working off my phone, so typing is slow.  I don't mind being more
verbose once I'm at my laptop, but it will have to wait.  Please let me
know if it's still uncertain.

Scott K

On July 31, 2019 10:35:15 AM UTC, "Дилян Палаузов"
<dilyan.palauzov@aegee.org> wrote:
>Hello Scott,
>
>you are too spare in your words.
>
>My understanding of the conversation so far is that only the MTA does
>the sampling for failed messages based on p= and
>pct= . The A-R header is supposed to carry information, whether the
>message validated or failed DMARC and for failed
>validation, what the MDA shall do with the message (basically
>quarantine or deliver).
>
>If you put the policy to be applied in the A-R, then it is not the
>policy from DNS, but rather the disposition to be
>applied.
>
>Regards
>  Дилян
>
>On Wed, 2019-07-31 at 10:28 +0000, Scott Kitterman wrote:
>> I suppose you could also add something like dmarc.pct=50 too, but I
>think that would add complexity to no benefit.  As long as you make
the
>sample decision once, it works out the same.  For the case where a
>message wasn't selected due to sampling then I'd put the policy to be
>applied in A-R so the MDA doesn't have to worry about the percentage.
>> 
>> Scott K
>> 
>> On July 31, 2019 5:56:26 AM UTC, "Дилян Палаузов"
><dilyan.palauzov@aegee.org> wrote:
>> > Hello Scott,
>> > 
>> > for p=quarantine; pct=50 if the MTA does the sampling and decides
>to
>> > quarantine, and forward the email to the MDA, how can the MDA know
>> > whether it shall quarantine the message or not?
>> > 
>> > Regards
>> >  Dilyan
>> > 
>> > On July 31, 2019 1:25:23 AM GMT+03:00, Scott Kitterman
>> > <sklist@kitterman.com> wrote:
>> > > Since the status is per message, I think the MTA should do it
and
>> > other
>> > > than as perhaps a comment, it doesn't need to be in A-R.
>> > > 
>> > > Scott K
>> > > 
>> > > On July 30, 2019 2:04:28 PM UTC, "Дилян Палаузов"
>> > > <dilyan.palauzov@aegee.org> wrote:
>> > > > OFF LIST
>> > > > 
>> > > > Hello Scott,
>> > > > 
>> > > > does the PCT value belong to the published policy and subject
>to
>> > > > inclusion in the A-R header?
>> > > > 
>> > > > Who is supposed to apply the sampling, based on PCT parameter:
>the
>> > > MTA,
>> > > > the MDA or both?
>> > > > 
>> > > > If both are supposed to do it, can the A-R header be extended
>in such
>> > > a
>> > > > way, that only the MTA does the sampling, and
>> > > > carries the information to the MDA?
>> > > > 
>> > > > Regards
>> > > >  Дилян
>> > > > 
>> > > > On Tue, 2019-07-30 at 13:56 +0000, Scott Kitterman wrote:
>> > > > > The published policy (that's why I suggest dmarc.policy). 
>I'm not
>> > > > sure if disposition belongs in A-R.  If it does, it'd be a
>local
>> > > policy
>> > > > override, probably policy.dmarc as described now in RFC 8616.
>> > > > > Scott K
>> > > > > 
>> > > > > On July 30, 2019 1:34:46 PM UTC, "Дилян Палаузов"
>> > > > <dilyan.palauzov@aegee.org> wrote:
>> > > > > > 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
>> > > > > > > 
>> > > > > > > 
>> > > > > > > _______________________________________________
>> 



> 
> I know that Gmail and others put that information in the comments,
> but that probably shouldn't be for something explicitly part of the
> spec like this.
> 
> Anyways, +1 to keeping p=quarantine as a concept, but willing to go
> along with the consensus on naming.
> 
> Brandon 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc