Re: [dmarc-ietf] New proposed wording for p=quarantiine

Brandon Long <> Tue, 20 August 2019 23:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3183A120106 for <>; Tue, 20 Aug 2019 16:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q-L2H_Z0hw7O for <>; Tue, 20 Aug 2019 16:08:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D06F61200D8 for <>; Tue, 20 Aug 2019 16:08:50 -0700 (PDT)
Received: by with SMTP id b20so123074vso.1 for <>; Tue, 20 Aug 2019 16:08:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5JcPzuv+KudXcN4V7g/TzHoOBmzTOzWz3LCKTQiHoWQ=; b=IZAU6NP3qHurSTq/vdUP8aesxkWcaO0aKdM/3uCY+ssiX61EE7JSCkdhWO2R+mSQy+ 2m1Kv06/ClJqcPomJZg8K6C6+660ElvrH6wGX/4FbNvq41qb/2vHezPt6UUjga7sixem 4zhSqlcoffSaFVg+c+E7OUGFfjgreK9rm3FND+qhH467hbaAeS7X5EKAK0/ncDxdsWMd y6q9UWb2Uss4QatmtQ+CxCZAZHRtkjGxIim2sOgS35h6hJbi27bz5uB8I1S9QIBSBDtl hMWPsMvTN27kd7TbZgPK44HBxVAuX55jpvi47b51v/DE82gaGGT2cWy7Nwk6Y65UuauL DwOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5JcPzuv+KudXcN4V7g/TzHoOBmzTOzWz3LCKTQiHoWQ=; b=svS9xhM3rQdkJ9unejDhnoQGmNi4PsEJyBCdcRR2h6W6/gsugJPYdg12a3yq0U46Zg DcaUo9DOA2lz60EIgSx/24pBvNGqPYhDpNM5G1/n7+sLANRpXQvOf1v2OWVysBdKX0fK ULusLtxbaEtt7MQSb4pWd7ZNpk3ip5UUxcUnymAXCHbK0B6t5oKMfll3nPEJApI4tgJp c/Zf82dzq33556ueKQM6F159I7ZwVknab6KCQLhqAFa2ZzDMsO/8byNDf6bL2YgqRYh2 3jBTBNLfIQfhE3s7GBhDw/vaTnxGaoyfKuRqikok9wTS6zisXauCzKnyv4oN7NaAUMxr DWFQ==
X-Gm-Message-State: APjAAAU+dvNdguF3uhzjpQI6yrBqE1SPIa/JVT6afmN+HzB4BT1LEYnh D6ysiFC3RFXRNva9Tm6pi2MkJRCWvCacyJV7G7S7h7w=
X-Google-Smtp-Source: APXvYqyx3a8TevAK1qWeQ/57dw3pCrq8lr/P0Sn3bRr7WQ6L03KFuv0wDNR8vCDubQMSw6OFtMIiy9Bm3aeCu9iCZ8U=
X-Received: by 2002:a67:ee98:: with SMTP id n24mr4055381vsp.92.1566342529150; Tue, 20 Aug 2019 16:08:49 -0700 (PDT)
MIME-Version: 1.0
References: <20190803030532.1D33375D900@ary.qy> <> <> <> <>
In-Reply-To: <>
From: Brandon Long <>
Date: Tue, 20 Aug 2019 16:08:37 -0700
Message-ID: <>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <>
Cc: "Murray S. Kucherawy" <>, Scott Kitterman <>, IETF DMARC WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [dmarc-ietf] New proposed wording for p=quarantiine
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: Tue, 20 Aug 2019 23:08:53 -0000

On Sat, Aug 10, 2019 at 1:44 AM Дилян Палаузов
<> wrote:
> Hello,
> to the idea to amend the existing definition of p=:
>   quarantine:  The Domain Owner wishes to have email that fails the
>          DMARC mechanism check be treated by Mail Receivers as
>          suspicious.  Depending on the capabilities of the Mail
>          Receiver, this can mean "place into spam folder", "scrutinize
>          with additional intensity", and/or "flag as suspicious".
> the text “
> The Domain Owner wishes in addition, that the sender of messages failing DMARC are notified about the suspicious
> handling with an appropriate rejection message.  Senders not willing to be notified that their message is suspicious,
> shall use the NOTIFY=NEVER service extension.
> In the past, Domain Owner could express as wish either to reject or to quarantine.  Considering that from the options:
> only reject; only qurantine; and quarantine, while notifying the sender about the suspicious handling of the message;
> nobody will choose only to quarantine, the interpretation of what the Domain Owner wishes by publishing quarantine was
> changed to include the rejection component.”
> so far two voices were against.  The reasoning against the amendment is that writing what the domain owner wants is just
> its preference, not anything binding, and the current definition is sufficient.
> My motivation in favour the amendment is, that currently nobody has the practice to quarantine messages and inform the
> sender of the special delivery status at the same time.   Spelling more precisely what the domain owner wants will
> suggest the implementations to implement precisely that preference.

It's not standard, but Google does add a string DMARC:QUARANTINE to
our 250 response to DATA for messages that policy
evaluated to quarantine.  I'm not sure anyone ever noticed, of course.
We've been doing it since 2012.

I'm not agreeing with the amendment, merely pointing this out.

Sender notifications would have to be one of:
1) Something like Google does, some 2xx response that contains extra
information the sending server would have to act on (which
becomes challenging in forwarding situations)
2) A 5xx response but also accept the message so a DSN is generated by
the sending (maybe intermediary) server. While I'm sure plenty of
already do something like this at least for honeypots, this seems like
a twisting of the standards.
3) A 2xx response, accept the message, and the receiver generating a
DSN.  This has the obvious typical backscatter issue.

So, I can see why our implementor chose #1, but also the low utility of it.


> With other words, the sole reason why a receiving host does not notify the sender for quarintined message might be, that
> the receiving site has not come to this idea.  The additional text removes the cause.
> If there was a common practice by now to deliver as junk and reject with appropriate text at SMTP level, then the
> amendment would have been less necessary.
> Regards
>   Дилян
> On Wed, 2019-08-07 at 08:13 -0700, Murray S. Kucherawy wrote:
> > On Sat, Aug 3, 2019 at 12:02 AM Scott Kitterman <> wrote:
> > > Policy is an indication of sender preference, not a directive the receiver must follow.  I think the definition is fine.  If the sender prefers failing messages be quarantined, then they should use that policy.  They won't get what they want in all cases and that's fine.
> >
> > This matches my understanding.
> >
> > -MSK
> > _______________________________________________
> > dmarc mailing list
> >
> >
> _______________________________________________
> dmarc mailing list