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

Alessandro Vesely <vesely@tana.it> Sun, 04 August 2019 10:56 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24223120026 for <dmarc@ietfa.amsl.com>; Sun, 4 Aug 2019 03:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85th624ZxMYb for <dmarc@ietfa.amsl.com>; Sun, 4 Aug 2019 03:56:09 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162B2120025 for <dmarc@ietf.org>; Sun, 4 Aug 2019 03:56:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564916167; bh=5q9iFJb0gDpmm0VudgOv/czGkcCda9zVP/Mf1cbA+HU=; l=1661; h=To:References:From:Date:In-Reply-To; b=Bnodeu/AOrEOqR7mSLVgGTJZWMOISVFDLhAQdf8JCT8+RV9hAwf9YSkibRivj/a6l HSUAo/r3KGPF6CnD2W31RipQKfC06QYWo+sMfA3Zcj30ern4dRAl0+8/BuDRiqA+dZ iA3WznGLQx+86ylyjGkuZbRiIo3ivrxxrOHANG9d6I2hXh7lTl2D6pTUHMDh7
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC03D.000000005D46B9C7.00001743; Sun, 04 Aug 2019 12:56:07 +0200
To: dmarc@ietf.org
References: <e84652a9df6b61e599f30e7fae6c0c728faf5ce5.camel@aegee.org> <5DD2CBA9-6F28-483C-9B08-8D3A41526BD7@wordtothewise.com> <d36a922d6bbb8426167e44d434e07b62faf86f21.camel@aegee.org> <6FCCAD3E-C2EB-4613-B0C0-148AE3387D21@wordtothewise.com> <bf96723d0a98477bac0f6f54742d3eb4d03f30a6.camel@aegee.org>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <036af2bc-4c77-af23-376d-1a2ce60e064f@tana.it>
Date: Sun, 04 Aug 2019 12:56:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <bf96723d0a98477bac0f6f54742d3eb4d03f30a6.camel@aegee.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/QUBbzhLI2-b0nOumycBZ54_Neoo>
Subject: Re: [dmarc-ietf] Concerns for not Sending a Failure Report?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Aug 2019 10:56:12 -0000

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