Re: [dmarc-ietf] Abolishing DMARC policy quarantine

Дилян Палаузов <dilyan.palauzov@aegee.org> Thu, 01 August 2019 14:38 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 00634120169 for <dmarc@ietfa.amsl.com>; Thu, 1 Aug 2019 07:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 J-G8QNmhJk0O for <dmarc@ietfa.amsl.com>; Thu, 1 Aug 2019 07:38:13 -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 B8AB112018F for <dmarc@ietf.org>; Thu, 1 Aug 2019 07:38:12 -0700 (PDT)
Authentication-Results: mail.aegee.org/x71Ec8OA003540; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564670289; i=dkim+MSA-tls@aegee.org; r=y; bh=LpFIeC7QyqeQ3afwcDUAxcUYDWLF7uX+L9UNQYjU2ec=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=VtZcELH8k11+GW0yEvLcjzrDsI4Vetp3V2HnTV2snLsErEmwCCm7f+vzsh+iXhA2t N7mAWC38MS1APKhh6cad81XYnY0IMU9YAOhPqIxrdiVif9ejRYsRZ8GkJvX5PQm4K1 2oJAqjidGdgVow8vCbgwqJ2dyNhkBJdxDWmMhJZvPpYDYoiQ5rN7YI9+E7QDKOlXsr mjlzie4WtkG4WDmlg8iWB7iwkE4jrXqDeUR5cfx0NhXyHzwRiEO9/cMQMZ0PoZ10wI laQTR5A58HldCzHu2bmxkSwchHQvLvqd2qs58AjCaNI3tWu7+qNUGO6NhuTBr0JoPW 1FrdYFb6LUTRkImc/uYFDOmCf7CY/ItBqdQohKLmgG67/VwcUu7mYUpxkTSOHOi0GT PeeVIByeAhC4YW96TMCPJOmJQ0hrf9wPQkikKJRibINWM1yq+g8rkgE3qQf1vOoOpV WhbYrVmBeOa6c8jifIay+t7Muo0/iTn4oN3yctYAUbwynlH9DLSnYuzJ3tNIwkbAsO JkUIh0lx3g1VkWnUUUylTrklq5sc0SKDNFO9P36ol0WRTcdpA6thSWf5rOvn+E7g+q 0i/VBLNquqzeoOSt3BcDWrMqXfE1szKJC23qeoYJfBmiRwydTYNlOutOQ93mCi7njG 3/rKh5ETPOKp80+ZrSqk5ZL8=
Authentication-Results: mail.aegee.org/x71Ec8OA003540; 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 x71Ec8OA003540 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 1 Aug 2019 14:38:09 GMT
Message-ID: <d1159ea43c926b2e617cd2ac41ad43985935a085.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: hsantos@isdg.net, "Murray S. Kucherawy" <superuser@gmail.com>, Tim Wicinski <tjw.ietf@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>, Alessandro Vesely <vesely@tana.it>
Date: Thu, 01 Aug 2019 14:38:08 +0000
In-Reply-To: <5D42EDB5.10107@isdg.net>
References: <a8ac130a671f5bcd1bf9f09781325e84a9f1fda6.camel@aegee.org> <b903c983-5c65-5b17-62bf-9ff42ffdbaaa@corp.mail.ru> <CAJ4XoYeJRcGfO7LntM6LBeJ5rMOcb0D=ya31Rm8utoWTqE7oXQ@mail.gmail.com> <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <CAL0qLwYYEMofia2S4a8oXsf02fnJg7y+DovvMWZENUW+4yUyiw@mail.gmail.com> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <CAL0qLwbX4T5=EFZtwPPk9aYdUpR72c4r5t8SB1WETkpXEtUahQ@mail.gmail.com> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> <CAL0qLwbixESJypwDG3NMuv22+Lb3w-iHPok8xZf-hy3Fiu38EA@mail.gmail.com> <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it> <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org> <CADyWQ+GcVA64Kg0RVi13+-kTXtHRds+iPb5gs7VM7VYSk=XS-A@mail.gmail.com> <CAL0qLwZsupUWkUpGPtQtp0Z-+rK56z17gJ2uHaQa=5MrZ7jnsA@mail.gmail.com> <5D42EDB5.10107@isdg.net>
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/k7HTd0M0KPOu9N5abPdgV1v41FE>
Subject: Re: [dmarc-ietf] Abolishing DMARC policy 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: Thu, 01 Aug 2019 14:38:15 -0000

Hello Hector,

you state, that a domain owner can request p=quarantine over p=reject because of concers of false positives.

Why shall one have concers about false positives, but will not be willing to fix them?

I do repeat myself, but the way to fix the false positives is to introduce p=reject, see which emails fail and are
returned and then fix the DKIM implementation for that messages.  That said, if you have concerns of false positives and
want to get rid of them, the way to go is do p=reject.  If there are concerns about false positives, but nobody wants to
fix them, you end having an unreliable system.  Besides, I do not see when a false positive happens, due DKIM stuff not
running correctly, whose problem is this:
• Of the sending domain owner,
• Of the user sending the mail (the only one who has nothing to say, except switching the provider),
• Of the site receiving the mail,
• Of the user receiving the mail?

Among several valid answers, a correct one is, that this is a problem of the one who has wrong DKIM implementation and
this is either the sending or the receiving site.  Since the problem is not of the sender, the sender shall have no say.

Note, that quarintining a message for a user, that never checks her spam folder, is equivalent to discarding the message
and for such users the choise is in practice reject or discard.

On Thu, 2019-08-01 at 09:48 -0400, Hector Santos wrote:
> On 7/31/2019 11:32 PM, Murray S. Kucherawy wrote:
> 
> How the receiver implements mail filters SHOULD always remain as local 
> policy.
> 
> [...]
> 
> If we take quarantine out, there is still going to be receivers who will 
> perform a quarantine concept regardless of a hard reject policy.
> 

This is not exactly what I’m proposing with abolishing policy quarantine.

I propose, that there are only two policies that can be annouced by the domain owner:
• “none”, meaning that not all mails have DKIM-Signature that alings to From: to that domain
• “not none”, meaning that the domain owner announces, that all messages From: that (sub)domain are supposed to have
valid, aligned DKIM-Signatures.

For pragmatical reasons, the name for “not none” will be “reject”.

Moreover, I propose, that when the policy is “not none”, the recipient decides how to punish messages, that fail DMARC
validation and the specification elaborates the possibilitis.

So, with “not none” policy, some recipients will do hard reject and others not.  Just like sites which have not
deployedd DMARC.

In any case, if the consens is to keep policy quarantine, and the specification states, that implementations can allow
receiving sites to override the policy to reject (or to quarantine) and implementations can allow individual users to
override the policy (to reject or to quarantine), recommending what to do with messages that go simultaneously to users
which have not overridden the policy and to users which have overriden the sender policy, then I am fine.

Regards
  Дилян