Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Ken O'Driscoll <ken@wemonitoremail.com> Wed, 12 June 2019 11:05 UTC
Return-Path: <ken@wemonitoremail.com>
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 7CB70120155 for <dmarc@ietfa.amsl.com>; Wed, 12 Jun 2019 04:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wemonitoremail.com
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 6sgKTMWg6vel for <dmarc@ietfa.amsl.com>; Wed, 12 Jun 2019 04:05:35 -0700 (PDT)
Received: from email.wemonitoremail.com (email.wemonitoremail.com [78.47.26.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9560120150 for <dmarc@ietf.org>; Wed, 12 Jun 2019 04:05:34 -0700 (PDT)
Received: from localhost [127.0.0.1]
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1560337532; bh=kF0PEixHs0z9xVUmmcfFMZPLO/dfbi+otRjRNQMnnTw=; h=Subject:From:To:Date:In-Reply-To:References; b=aYWI0FUkBdrYG6/agL5U5hnU9ytC7/+pN69565LvQhwGvjlnf1LDHrS5ANABzM5pN 1JoayLm7uA5E83UjvYRCi+nDLk16W3ukSm29KcVV4OSKsQrO6KJXZtAqYeQL8FYroT YeYtZMaII/NSiuBLldYvEVpkWWiu3wZlxywWpo3E=
Message-ID: <b35700fed33aea68cde9a10c492b90f25519ce30.camel@wemonitoremail.com>
From: Ken O'Driscoll <ken@wemonitoremail.com>
To: dmarc@ietf.org
Date: Wed, 12 Jun 2019 12:05:30 +0100
In-Reply-To: <a8ac130a671f5bcd1bf9f09781325e84a9f1fda6.camel@aegee.org>
References: <a8ac130a671f5bcd1bf9f09781325e84a9f1fda6.camel@aegee.org>
Organization: We Monitor Email
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.2 at email.wemonitoremail.com
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/fFpWOR9-rwAApe8sx4kKRzptNhg>
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: Wed, 12 Jun 2019 11:05:37 -0000
On Tue, 2019-06-11 at 21:00 +0000, Дилян Палаузов wrote: > Dear all, > > when DMARC passes, there is no difference between p=reject and > p=quarantine. [...snip...] > However, it is ultimately up to the receiving site to decide, whether it > wants to accept this extra work. If it does not accept the extra work, > it just handles quarantine as reject. This does not violate the DMARC > specitification. Even in a moderately complex spam filtering engine, DMARC is just one indicator / signal amongst many. Who does the "extra work" is subjective. For example, a large mailbox provider may consider support queries about missing or rejected emails as unwanted "extra work" etc. DMARC does not live in isolation - it's part to a greater ecosystem. > Do you have a story, why one wants to publish p=quaratnine? What is the > use case for it? It just makes emails less reliable, as they end as Junk > and this is very similar to discarding the emails. There is a world of difference between requesting that a recipient flag an incoming message as spam as opposed to asking them to discard it outright. And that is regardless of how individual mailbox provides treat p=quarantine. A use case for p=quarantine is that when deploying DMARC for any reasonably complex site, it forms part of a graduated approach (perhaps in conjunction with pct=x) utilising aggregated reports to moving towards p=reject. The proactive nature of DMARC means that its deployment needs to be properly planned with any risks mitigated as best as possible. The various stages of p= can easily be articulated on a project plan / risk register. And such sites that require such planning are often starting from a position of improperly documented mail flows and inconsistently implemented SPF/DKIM. In addition they often operate in regulated sectors and are commonly top-heavy with risk-adverse middle management. I accept that a small site with a simple mail flow which does not operate in a regulated space and has thin governance could likely move straight from p=none to p=reject without serious repercussions. Such sites are not the majority of DMARC deployments. DMARC changes how recipient mailbox providers treat email and therefore it needs to be deployed in a controlled manner, p=quarantine being one component of that. > Imagine a mailing lists, where the recipient of an email address expands > to several mailboxes on different domains. An incoming email fails DMARC > validation before being distributed over the ML. The domain owner for > that mail origin has published p=quarantine, this email cannot be > delivered in the Junk folder of the recipient, because the mailing list > itself does not have a junk folder. DMARC was never originally intended / scoped to work with domains which interacted with mailing lists. The 5322.from address rewriting kludge allows such interaction by removing future DMARC tests. A mailing list operator can also choose to reject emails from domains which have a DMARC record. DMARC has no use case to offer when working with mailing lists. > How about, deleting policy Quarantine and instead rephrasing policy > Reject: > > It is up to the receiving server if it rejects messages failing DMARC, or > accepts and delivers them as Junk. > > (This does not change the protocol, just the wording) I think this is completely unwarranted for (at a minimum) the above mentioned reasons. Ken.
- [dmarc-ietf] Abolishing DMARC policy quarantine Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Ken O'Driscoll
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Laura Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Dotzero
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Vladimir Dubrovin
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Dotzero
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Vladimir Dubrovin
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Alessandro Vesely
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Steve Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Vladimir Dubrovin
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Steve Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Dotzero
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Steve Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Alessandro Vesely
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Tim Wicinski
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Alessandro Vesely
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Brandon Long