Re: [dmarc-ietf] Concerns for not Sending a Failure Report?

Дилян Палаузов <> Sun, 04 August 2019 11:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96BFA120025 for <>; Sun, 4 Aug 2019 04:47:07 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (4096-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qhGS2TVaiZlp for <>; Sun, 4 Aug 2019 04:47:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB407120019 for <>; Sun, 4 Aug 2019 04:47:05 -0700 (PDT)
Authentication-Results:; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=k4096; t=1564919223;; r=y; bh=8szj5lN3/sIq1M6uuvPVwihLvylWnPo4eA/X4NkCsAQ=; h=Subject:From:To:Date:In-Reply-To:References; b=qNGWSURcoMdirU/UGy5us9p1qQgQoswttATjmVcy+Be5sEOOvDE7UoeZ5yIrooF9H mDtRpANe1nTivZpTFgTy1PbXSaGIhmzfQ84ZHkq28SoDmW07shxzOVNxjbIIrk0u4L xmA2RiYT+rHA4sISHjrUcngDeem7XkymJBeYEzc+AZfywSku4EhMxlIq7GOqeyBRr3 OJ6pZ74z199BIWawnRY2MmNSmDpeHWPP6x+KCsHTXRhjSOGt6l2y/WUZVGKvHDNq76 LCE1nXoibanigJaSKUcLf2IE2QkV4Cpqvqz8jQAPFkJQnUcWapUVq/aM/5wFx8G1/k vteXO8/XiqUp5xv6yajZo2UMlt0kBi3p4tVjdmALj16Z82MmbR1vnWxXmMoBzhMZGA aOUYXvXLxbt/nJoBNCgL9UR/djl+VWcTrQCi3fC9npP4FPDr1aYP62gGxbelf9sRfo qPOpEIx190IA8QoWA0ODQmcbxcxCmbBW8LRq0yrgJIHGJ/pRa47k8IoFdbfh4PXLj2 3xQsPCFZ2Ke5evrhVqgnWVvTOJrBYNZ3ulyjXSFF3CpgxqKf/8eaVM+DQRrcCQm6lA 5WjJkn0nlmyi1kfEdhq/trzzSIFqPfRiETJ2xkRVPgGFgADvjpZhLd1OOByAlEgg3m LoWBPyLkLEB3AwvAwYZpRE7Y=
Authentication-Results:; dkim=none
Received: from Tylan ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x74Bl10e029318 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 4 Aug 2019 11:47:02 GMT
Message-ID: <>
From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= <>
To: Alessandro Vesely <>,
Date: Sun, 04 Aug 2019 11:47:01 +0000
In-Reply-To: <>
References: <> <> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.33.90
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.2 at
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [dmarc-ietf] Concerns for not Sending a Failure Report?
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: Sun, 04 Aug 2019 11:47:08 -0000

Hello Alessandro,

what is the purpose of the failure reports?

If the purpose is align DKIM, SPF and DNS implementations of senders and receivers, then I am proposing ways to exchange
information for debugging.

I do not propose how to obtain information about scammers’ actions.  DMARC is invented to make the workflow of scammers
impossible, it is not about exchanging information of performed scammers’ action.

If a site promises to its users, that all emails will be encrypted, then publishing a ruf= address likely violates that
promise.  This is not necessary true, if the failure report is delivered (encrypted) only to the person who sent the
original message.  This creates a big fuzz, whether forwarding always the failure reports to the sender of the original
message is a good idea and goes out of scope.

I changed my mind:

The DKIM—Signature has a tag r=y.  It is a matter of adding a new value r=a, that means both:
• The writer of the message, or a site which has received the message at some moment, is willing that a failure report
for failed DKIM validation is sent, for every present DKIM-Signature that aligns to DMARC.  The one who adds r=a can
have a copy of the message.
• Receiving sites can assume, that whoever adds r=a has a already a copy of the message and sending failure report with
the content of the email does not reveal information to the recepient of the report about the content of the email.

Now, if nearly all mails from a domailn, that pass DMARC have r=a and emails that fail DMARC from the domain, have no
r=a, then the lack of r=a on its own, makes the mail suspicious.

Will scammers start inserting r=a?

Will be there a doubt, when both r=a and ruf= are present, that both the writer of the message and the domain owner are
willing to receive failure reports and neither of them has concerns, when the reports are sent?


On Sun, 2019-08-04 at 12:56 +0200, Alessandro Vesely wrote:
> Hi Dilyan,
> On Sun 04/Aug/2019 12:10:51 +0200 Дилян Палаузов wrote:
> > The receiving server knows, which IP address sent the mail and it knows, to
> > which IP addresses set the failure report will go.  If there is a match in
> > the IP addresses, then the receiving server knows that the one who will get
> > the report is also the one, who has anyway access to the message.
> That's not always true.  For example, I know of mailbox providers who, on
> delivery, automatically encrypt cleartext messages to the public key of the
> recipients, including the Sent folder.  Operators at that provider's aren't
> able to sniff message contents unless they're sent back on failure by receiving
> sites.  In general, users trust their mailbox providers also because of the
> policies they enact.  Matching those policies with unwarranted disclosure of
> messages is not straightforward.
> In addition, the most interesting reports are messages not coming from my IP.
> Scammers abusing may domain name use their own IPs.  I see those failures in
> the aggregate reports, but don't know if the IPs mentioned there correspond to
> mailing lists or other legitimate forwarders, or even some ill-informed users
> of mine who send their mail through their ISPs.  That's why I need failure
> reports.  It would be enough if the aggregate reports contained an indication
> of the spamminess of those messages, or the reputation of those IPs.
> Failure reports for messages originating from my IP are only useful for
> debugging.  An activity which I can more easily do by using free mailboxes, as
> you said, or sites specifically dedicated to testing email.
> Best
> Ale