Re: [dmarc-ietf] [ietf-smtp] and DMARC with p=quarantine; pct=0

"Kurt Andersen (b)" <> Sat, 26 January 2019 00:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BBEC12DDA3 for <>; Fri, 25 Jan 2019 16:15:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3nL52zyOdmMS for <>; Fri, 25 Jan 2019 16:15:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE0811295D8 for <>; Fri, 25 Jan 2019 16:15:28 -0800 (PST)
Received: by with SMTP id x6so9146922ioa.9 for <>; Fri, 25 Jan 2019 16:15:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T/7pOHqcxhhITdxFMQvHCRJnY2yHkyen16szts0DXSw=; b=L7qyWSXJHSmP6dCsUK1xCdgfwJqvn1aYmbOF3Ct4d3L41cp0QZqnXpaYMqKbPupFUk 2IoMv98kspMLGM5wm3x2APxXjoDfsPDNWtkrRQlMqIMETV3f/SfTAWtQ1FD/JIf2TBze HFJR0YLAnJjRhxSEEb0xXjtXCPhuzzsVntqAA=
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=T/7pOHqcxhhITdxFMQvHCRJnY2yHkyen16szts0DXSw=; b=f3MBLX81jxQMzS4YcipbfjRdHHh6GMSHw1sd04H5pYAIeW6CflsnFxAwqvqOhw5YEg V22Ug09z7ZXosziJAgl+nCwTnDuqGlZqqK7RzRAUSKXei9Wf1fDrHvEcAmLaVZ3MaHAl qzAUbiQqMe6dQf6BEhVyd0Gj4WIGrtbIppSaiPfhjYzuYIHKh7Q/c7Oz1/R+XV31Bx5M PdC6UVDdsnVLhFTWPiMAbGqvytb9pUMWFKKp29vUysgwDvU0XeCP+Z97JDwFhSijwYUy 2/4BAFi+DMHX3A03UEPKgNLiDO0WX+yIi9aI2XovGXdPPWbIiQ9FfDiyO4xtcRvbGkxo I3pw==
X-Gm-Message-State: AHQUAuaW/ztIhXL+Kt+EBir/KFCwP946AdhZgdh2sjW3YyEj2zGrcQFw L0JL8DfvVUYYujiIn7xEsGUNI+5xFrlvO7e318wRE7y5v2KBZQ==
X-Google-Smtp-Source: AHgI3IZByGXPD44qmDQBUNrDAzePsFyn7/hMkVyYbTzH5pS8EDCPSU1z5BtnVxZbx1eWdAu5zCQT/hiO7j1yMYZyQ3c=
X-Received: by 2002:a6b:6306:: with SMTP id p6mr8085786iog.196.1548461727754; Fri, 25 Jan 2019 16:15:27 -0800 (PST)
MIME-Version: 1.0
References: <20190125221241.4D54E200D31436@ary.qy> <>
In-Reply-To: <>
From: "Kurt Andersen (b)" <>
Date: Fri, 25 Jan 2019 14:15:16 -1000
Message-ID: <>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <>, "" <>
Cc: John Levine <>
Content-Type: multipart/alternative; boundary="0000000000003b46c10580515797"
Archived-At: <>
Subject: Re: [dmarc-ietf] [ietf-smtp] and DMARC with p=quarantine; pct=0
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, 26 Jan 2019 00:15:31 -0000

This is worthwhile, if aspirational, input to a future phase of the DMARC
WG (added to the distro and moving SMTP to BCC). It is, as you observe, not
the current state of the spec.

One further complication is that relatively few receivers generate forensic
report (ruf), in part due to privacy concerns. As a result, even if the
process worked the way you advocate, you won't get much if any information.


On Fri, Jan 25, 2019 at 1:27 PM Дилян Палаузов <>

> Hello,
> at a high level the common interest is to reach a state, where deployed
> DMARC works in practice reliably:
> - verifiers and signers are compatible
> - signature are not broken on their way to the recipients, so no bad
> delivery
> - the path from sender to recipient always works reliably and whenever
> something does not work as expected an individual
> failure report is sent
> …
> Receiving aggregate report, stating 0,1% of mails do not verify DKIM,
> shows that signers and verifiers in that
> combination are not compatible.  The aggregate report does not say whether
> the the signer or the verifier does bad job,
> it just proves that DMARC is not going to work 100% reliably.  This is bad
> for both parties, as it just means that DMARC
> shall not be trusted as it in practice does not work as expected (and
> therefore deploying it is…)
> The individual failure reports provide the means to find exactly what is
> going wrong, on which system.  To tackle a
> failure report I want to be sure that something wrong happened.  A failure
> report for p=none cannot mean, that something
> wrong happened, in particular it does not mean that DMARC is violated.  So
> sending a report on p=none makes no sense.
> Shall a failure report be sent for p=quarantine; pct=0?
> says “p=reject;pct=0; is to force MLMs to
> rewrite From:, so as to
> avoid useless reports”.
> This is discussable but the common aim is to have a state, where reports
> get very seldom and every report has an added
> value — indicates a problem that is investigated.  Sending too much
> reports, on real and unreal troubles, makes tracking
> manually all reports impossible and does not help to make DMARC reliable.
> Keep in mind that not every person deploying
> DMARC or mailing lists understands DMARC or acknowledges that its MLM
> modifies messages but does not change the From:
> sender.
> The current discussion does not lead in the direction of reaching the
> state, where reports are sent seldom and indicate
> troubles, which troubles shall and can be handled in a way, that prevents
> happening them again in the future.  That
> said, the current setups in general do not permit to improve the accuracy
> of DKIM/DMARC evaluations.
> There are not only theoretical, but also practical concerns.  Having
> DKIM-Signature: r=y; … in a message, sent over a
> mailing list, the From: is changed and DKIM invalidated.  Per RFC 6651 a
> report is sent.  But this report is useless, as
> the MLM broke the intentionally the DKIM-Signature, so there is no
> information to extract from the report and there is
> no approprite handling.
> In summary, the specifications shall be read in such a way, that:
> * reports shall only be sent, when the recipient of the report can and
> shall take actions to improve the accuracy of
> * for the purposes of testing there must be a way only to get reports for
> bad situations, without having the bad
> consequences.
> Regards
>   Дилян