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

Dotzero <> Sat, 10 August 2019 15:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C53B120043 for <>; Sat, 10 Aug 2019 08:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 4_tBRClXjM5i for <>; Sat, 10 Aug 2019 08:07:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 918B212001A for <>; Sat, 10 Aug 2019 08:07:50 -0700 (PDT)
Received: by with SMTP id s3so8396585wms.2 for <>; Sat, 10 Aug 2019 08:07: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; bh=utbniqjTAymfjc/m2qNwmlJZQKpWcRcwl94Dx8+NLX0=; b=sIKRbza87Db7VqCNGprEBrIazlsfccwaODCX2/ByiHc8ZosXXldV7iA7vs5iGNv2t7 xCSzFklYxubpNuRCdIu0GCy+DDSG4/3sdhUKScmqGPNpqNk8Jz1WguZsq5yct4ZDLOSM OdD7SRA7jlLbxSezUQrDhkvM9MW9424H6uQx2t/I47Z19+rWWNNwkadjMDal9hgpZF4s qbvJTFNjMu4voOrf5VrcVCaOUID/SDnKxaI6VQ2nVUXyN8PTdX6+e86vNCnxhqUAQtYP vUQtLWUORHzyTA079l7D5U2FTMRjOqC0oksLBd5UOphn0lsILCYyN+GJT6j+GI98fqx8 iGEA==
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; bh=utbniqjTAymfjc/m2qNwmlJZQKpWcRcwl94Dx8+NLX0=; b=GbwVt1AhbTbjLGRs5+qJryTHKU+6oehRGVNkjD4n+GQ3SkDGZIJjr4oqZEYXKEo+1q J3eSx53r2vARUMXKTx6P9KMVLHaYx/id4YDROW3IfsQm6a44gl+2xpa+IU7xONCCnClz 09c/lx9/rdFyeHeVBK/rucoz6QwTf8HXedgma3R3TZfduZCOybvneFt5QC55VCEgqKsW CUbtZx1NjwXhlvV8deK8zniIRG2y/dZufvYbrkuV+oWudURCv8Cnmc1yVnplE8DonwiM WtoNGKsnHSLhuj2c5Vc7KOSG3A9KHwIdJH4z4HtTZUyNrZKYRc+HvyfcJhyfMVDbNAOe qfFA==
X-Gm-Message-State: APjAAAU/vjgvlO6tDfA6vUcEvVmk+65G49vhHfiWCvUiGgDIS/mtNc+M xeQ6e9Qbva51hd4mWPT5G8PVO2yVP4oIKbC8VPs=
X-Google-Smtp-Source: APXvYqwITq2wkEz/P32bpGNJVzASonIcIFqrkzcggbCSFIqH8rjVGWtWvD5dMqw11Tf9K/VgvZvgZyjAhL1O1ZQekKc=
X-Received: by 2002:a1c:751a:: with SMTP id o26mr17191328wmc.13.1565449669102; Sat, 10 Aug 2019 08:07:49 -0700 (PDT)
MIME-Version: 1.0
References: <20190803030532.1D33375D900@ary.qy> <> <> <> <>
In-Reply-To: <>
From: Dotzero <>
Date: Sat, 10 Aug 2019 11:07:38 -0400
Message-ID: <>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <>
Cc: "Murray S. Kucherawy" <>, Scott Kitterman <>, IETF DMARC WG <>
Content-Type: multipart/alternative; boundary="00000000000070d01f058fc4a72e"
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: Sat, 10 Aug 2019 15:07:54 -0000

On Sat, Aug 10, 2019 at 4:44 AM Дилян Палаузов <>

> 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.

I'll add a third voice. When we came up with DMARC - yes, I was part of the
original team -  we were extremely cognizant of the fact that
there is no way to bind receivers/validators to the preferences expressed
by senders. The whole purpose of DMARC was to take something that was
working through private contractual agreements in a private group and make
it available more generally and publicly. Today there are receivers which
only make reporting available on a contractual basis through 3rd party
intermediaries or because there are direct relationships between the sender
and receiver. It is important to recognize what is required for
interoperability (in a standard) and what is a want that goes beyond what
is appropriate for a standard documenting technical interoperability.

> 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.
> 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.

Technical standards, as a general rule, should not be written based on
suppositions with regard to hypothetical causations that lack any empirical
evidence to support those suppositions. One could just as easily suppose
that the reason that receiving hosts do not notify the purported sending
domain is that they believe it is a bad idea. In either case it is a
supposition without any validation. We are not mind readers.

> 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.
You are asserting the amendment is necessary but you are providing no data
to support your assertion. My experience covering a corpus of billions of
emails does not support your assertion.   I therefore agree with Scott and
Murray that no amendment is appropriate in this case.

Michael Hammer