Re: [dmarc-ietf] Abolishing DMARC policy quarantine

Steve Atkins <> Sat, 15 June 2019 22:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 633A412012A for <>; Sat, 15 Jun 2019 15:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M0o4M4rOxN5g for <>; Sat, 15 Jun 2019 15:13:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CEE311200C5 for <>; Sat, 15 Jun 2019 15:13:17 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 1AFD19F146 for <>; Sat, 15 Jun 2019 15:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=aardvark; t=1560636796; bh=BnzR9+fhthKL7bpIReS48G92oRIqnOuc4/DdLlGg3Hg=; h=From:Subject:Date:References:To:In-Reply-To:From; b=K/627I+nIHv0Y1vz+qOs9FBc/AYBE7pi7CkaIYaFrnWmSfBKadKteBzDJisHpaiTe PUU2e7hmyl9VzWCoWjmsTkwMRFCiV4fEMzNbQs8oEGi+BjroRzen06PC1CoMvvRrVB V3JnHM0mXZdh2Y6JFK63f61PR3Foq/rR4lCCpzas=
From: Steve Atkins <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 15 Jun 2019 23:13:13 +0100
References: <> <> <> <> <>
To: dmarc <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 15 Jun 2019 22:13:21 -0000

> On Jun 15, 2019, at 9:25 PM, Дилян Палаузов <> wrote:
> Hello,
> p=reject; pct=0 is equivalent to p=quarantine; pct=0.

I've not been following this thread too closely so I might be missing something, but under current
DMARC spec I don't think that's so - see section 6.6.4.

If I've missed the point ... never mind, carry on.


> The rest of this email is about (against) handling p=reject and p=quarantine differently.  Namely, where a server
> rejects on p=reject and “quarantines” on p=quarantine.
> There are more examples, all under the category p=quarantine, where the spam filter does not think a message is spam and
> DMARC fails (e.g. missing DKIM-Signature):
> — an autoresponder.  The incoming email will be delivered as non-spam, as the spam filter does not classify the email as
> spam.  Would you suppress the autorespond (out-of-office/vacation) message, or will you take the risk to send bad
> backscatters, risking lowering your IP reputation.  Is it up to the domain owner of the original message decide on you
> sending backscatters, by publishing slightly different dmarc policies?  If you handle quarantine as reject there is no
> such risk of getting bad IP reputation (under these concrete conditions).  If no auto-responder is sent and the mail is
> not classified as spam, the user will rely on the fact, that an autoresponder was sent… big fuzz.
> — an 1:1 alias to a different server.  If your server thinks the email is not spam, but the server to which the alias is
> redirected thinks the message is spam, or if the user marks it as spam, your IP reputation gets worse.  If you handle
> quarantine as reject there is no such risk.
> — a MLM (1:many alias), where anybody can send messages - same problem as above, just bigger damage.
> p=reject and p=quarantine both communicate, that all messages from a domain must have aligned, valid dkim signature or
> aligned, valid spf result and that for messages from the domain failing DMARC, there must be some penalty.
> How many distinct penalty levels does a sending domain owner need?
> One, or more than one?  Are two penalty levels enough?  Is there justification for two penalty levels?  Can the same 
> justification be used to introduce a third penalty level?  What does the domain owner/sending domain want do
> communicate, by using the first, second, or third penalty level?
> Currently the decisions on handling quarantine/reject in different ways are taken by:
> * domain owners, who own a domain
> * spammers, who use the domain of the domain owner, and let's say are distinct from the domain owners
> * mailbox operators
> Not taken into account are the users.  Why shall a user want to have more messages in its spam folder (assuming that the
> quarantined message was at the end classified as spam and the email operator handles Reject and Quarantine differently)
> versus handling p=quarantine as p=reject and having less Spam to pay attention for?
> About the costs, Quarantine meaning neither deliver, not reject, but something different, can be implemented in this
> way: the operator does not deliver the emails failing DMARC for a domain with p=querantine to the users, but arranges
> staff, to decide what to do.  The costs for that staff, are the extra costs for having distinct handling of
> Reject/Quarantine.  If there is no such staff, and the decisions are taken by the users, then the costs are the same,
> these just are shifted to the users.
> Finally, while DMARC can be used to communicate that all emails from a domain must PASS DMARC rules, why there is a need
> to communicate what to do with emails that fail DMARC from: the domain?  The DMARC specification can be simplified, by
> leaving the hanlding of such emails ultimately up to the receiving host and then there is no need to iterate the options
> at protocol level for the sending domain. (The option, that all emails from a domain must have aligned DKIM signatures,
> but it is up to the recipient what to do with messages without valid dkim-signature or spf result is anyway missing)j
> Regards
>  Дилян
> On Sat, 2019-06-15 at 13:11 -0400, Hector Santos wrote:
>> On 6/14/2019 5:58 PM, Дилян Палаузов wrote:
>>> Hello Ken,
>>> effectively I proposed handling p=reject and p=quarantine the same way.
>>> ..
>>> Lets have an example for p=quaranite:
>>> majordomo@domain is an address where commands are sent and the software receiving the
>>> command always sends an answer, even if the command is unclear.  An email is sent
>>> to majordomo@domain.  The sending domain has published policy Quarantine.  This address
>>> has no spam/junk folder attached to it.  The options for an email are:
>>>  * reject the email during the SMTP dialog
>>>  * accept the email and let majordomo send an answer to it
>>>  * arrange a human to decide which emails to discard (handle an imaginary Spam folder for the account).
>> Oh I see your concern/point/proposal now.
>> Yes, I highlighted this basic issue in years past in regards to the 
>> handling semantics debates. Even with SPF,  how -ALL (FAIL) was 
>> interpreted and handled was questioned. Some believed a -ALL FAIL 
>> policy is more like a quarantine because "no one actually rejects."
>> But overall, this would be an implementation consideration, not a 
>> protocol design consideration. The protocol is correct to have a 
>> handling semantics describing both ideas - reject and quarantine.
>> All we can do is highlight the existence of backend mail storage 
>> designs and legacy MUA protocol(s) that can not handle a quarantine 
>> safely. So at best, you can basically highlight the security design 
>> concerns and possible requirements to implement a quarantine concept.
>> There is much mail design history and evolution to consider. The 
>> concept of quarantine came with the integrated mail design premise that:
>> - The backend offers user folders or separate mail streams for normal 
>> in-box mail and quarantine, spam, junk mail separations. While this is 
>> common today for ESPs, this was not always the case for all backend 
>> designs.  It was often proprietary in nature.  No standard here unless 
>> we assume everyone using an "Microsoft Exchange" (MAPI) concept or 
>> IMAP which is not reality. This coincides with the premise,
>> - The broad range of online and offline MUAs all support the 
>> multi-folders provided by the backend.  This is again not reality and 
>> not always the case.
>> I'll give you a perfect example -- POP3.
>> POP3 is a single mail stream pick up protocol standard. So for a 
>> backend that provides POP3 service available to its customers and for 
>> the user using MUA with POP3 support, the backend POP3 server MUST NOT 
>> merge any suspicious, spam, junk or quarantine mail with the user's 
>> normal in-box mail pick up stream.
>> While an advanced POP3 backend server can emulate a single stream 
>> consolidation of multi-user folders, it would a major security loop 
>> hole to expose POP3 users to quarantined mail merged into the user's 
>> pop3 mail stream.  For this to work securely, this advanced POP3 
>> server must assume the MUAs are advanced enough or users are advanced 
>> enough to write MUA scripts that will separate the single pop3 stream 
>> into spam, junk and quarantine folders again.
>> All we can do is highlight how "rejects" can be interpreted 
>> differently.  After much discussion with SPF, while it didn't provide 
>> an specific example using POP3, it was generically described under 
>> Local Policy Considerations:
>> It should also be highlighted for DMARC-bis, if not already.
> _______________________________________________
> dmarc mailing list