Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy

Vladimir Dubrovin <dubrovin@corp.mail.ru> Sun, 27 January 2019 00:36 UTC

Return-Path: <dubrovin@corp.mail.ru>
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 13CC5130EAF for <dmarc@ietfa.amsl.com>; Sat, 26 Jan 2019 16:36:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.843
X-Spam-Level:
X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru
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 Imli4UlxELHG for <dmarc@ietfa.amsl.com>; Sat, 26 Jan 2019 16:36:12 -0800 (PST)
Received: from smtp38.i.mail.ru (smtp38.i.mail.ru [94.100.177.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388C612DF72 for <dmarc@ietf.org>; Sat, 26 Jan 2019 16:36:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=Dij/8XerWy6A5lP29KBbGCN3r/d2DhrsCnTRUCE2Ets=; b=JaUEaNjP0BLDTHezWCOHrEZq8UfHmpW9DSMHD9imvy/Iyixqxv294c64aeDKbJWlRwroa18IjHppBP4QxgE6qb3K8980Uoi+w7AjUueUh6K8t7B4DtfUfvU5fnO4lBSi9myoI4ke5+uWycP1598tgtL/CMUzBMZ6z6YDD2d5IW8=;
Received: by smtp38.i.mail.ru with esmtpa (envelope-from <dubrovin@corp.mail.ru>) id 1gnYQi-0001aj-9q; Sun, 27 Jan 2019 03:36:08 +0300
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <dilyan.palauzov@aegee.org>, Dotzero <dotzero@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <20190126163123.AAA4B200D39816@ary.qy> <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org> <CAJ4XoYd8zq53MRmsXKx=Fh1n0NpHj=Q+0i5fjD1HDnqDE26++Q@mail.gmail.com> <ad02c03115cebe042ba0c6f815b5e98cec0398ae.camel@aegee.org>
From: Vladimir Dubrovin <dubrovin@corp.mail.ru>
Openpgp: preference=signencrypt
Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY
Message-ID: <d075df49-7d28-c931-9283-c39b593dd343@corp.mail.ru>
Date: Sun, 27 Jan 2019 03:36:06 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <ad02c03115cebe042ba0c6f815b5e98cec0398ae.camel@aegee.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Authentication-Results: smtp38.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru
X-618D5548: 81FD5A73BC5E955B3B62BF16355A2F9CD5726B99309011CDA92371E9ECBAA7EC
X-77F55803: 689590B63E0A4B015A78504BD2AC294108AEA42614CCE77CEB08515F5588567FA02EBCA0187532DCF73B5AEBDB4B5463
X-7FA49CB5: 0D63561A33F958A500FFD96411788983460A730502DF659607F79E37EC8612C98941B15DA834481FA18204E546F3947C2FFDA4F57982C5F4F6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8BF1175FABE1C0F9B6A471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C22498B372E35CF5A2D2DD32BA5DBAC0009BE395957E7521B51C24DA2F55E57A558BE49FD398EE364050FB28585415E75ADA9040F9FF01DFDA4A8C4224003CC836476C0CAF46E325F83A522CA9DD8327EE4930A3850AC1BE2E735051E786F7189A1785298F17BCD5CD198731C566533BA786A40A5AABA2AD371193C9F3DD0FB1AF5EBFD6F4F5CC2EFF5953C9F3DD0FB1AF5EB4E70A05D1297E1BBCB5012B2E24CD356
X-Mailru-Sender: DBC2F4F1B1B33C64B837EEACE6D760D0B80410A2C624C14EDFA0BCB064EF36BE31F5BB1E3305B3FEDF27400FA58A4AF1E66B5C1DBFD5D09D63761FFB9297ED015BF713DEE2A5F4A567EA787935ED9F1B
X-Mras: OK
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/LMxccVuJ8_rtluKqTFF4syeoy18>
Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
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, 27 Jan 2019 00:36:17 -0000

27.01.2019 0:14, Дилян Палаузов пишет:
> Hello,
>
> reiterating over the arguments against sending reports to the ruf= …dmarc address, the first provided reason was, that
> such report will not match the expectations of the users. 
> .... very good technical arguments skipped....

Nope, the point was it can finally lead to violation of privacy and
legal risks.

Since you probably speak Russian, I can give some good example.

As you may be know, E-mail in Russia is regulated by Telecommunication
Act (Закон о связи).

Article 63.4 ("communication privacy") says "Information about messages
sent via electronic communications ... and said messages .... can only
be provided to sender or recipient ...".

To make a ruf report one should send information about message to
address which is neither sender nor recipient.

Your argumentation is very good to explain a technical staff why some
partial information can be safely sent to some site. The only problem
is, there is no need to explain it here, you should satisfy a lawyer.



>  It can be assumed, that sending reports to the ruf= address at a certain domain
> matches the expectations of the users of that domain and any non-matching expectation is a problem of the one who
> published the ruf= entry, not the one generating a report.  I do not say that once the report is generated and sent the
> sender has to store the report, so that the expectation of the user, that received the initial mail, are also met, when
> the report generating server does not store a copy of the sent report.
>
> The second argument was, that staff managing DNS and staff managing emails (and able to read user’s email) are
> completely different persons.  I do read here, that the DNS staff can use its posititon to insert arbitrary email
> addresses in the ruf= tag and by this way come in a position to read emails, that otherwise the DNS staff would not be
> entitled to read.  Seriously, if the ruf= tag is not trusted, why shall the p= tag be honoured, and why shall also be
> the DKIM public signature and MX record be trusted?  Either the ruf= email address is trusted to receive reports, or the
> whole DNS of the sending domain is not trusted.
>
> The third argument is, that in case 1% ouf of 10 000 000 messages between two hosts are reported in the aggregate
> message not to match DKIM, then it is worth investigating the cause.  Alright, that is exactly my point.  I want the
> reports, provide ruf=, and don’t receive the reports.   Where will you start investigating?  How can you find out if the
> problem is on the sender or receiver side?  If you validate once again your implementation and find nothing wrong with
> it, does it prove, that the implementation of other side has bugs?  Perhaps the other side has also proven in the very
> same way, that it is error-free.  You see only that 1% of the messages do not match DKIM validation, now and then.  What
> is the next step to make signer and verifier compatible?
>
> Guessing?  If making signers and verifier compatible can be achieved only by guessing, then DMARC cannot be trusted/is
> not mature.
>
> I have no problems if due changes somewhere DKIM for a while fails, as in this case there is nothing I can do.  But I
> want to be sure, that the cause is not on my side, and currently this is not evident.  It is just not clear, if there is
> a problem report, if the problem is temporary, when the cause was resolved, if the cause is on my side…  This properties
> make DMARC not reliable.
>
> Regards
>   Дилян
>
> On Sat, 2019-01-26 at 12:56 -0500, Dotzero wrote:
>> Please, RUF is a ""Failure Report", not a "Forensic Report". Please read RFC 7489 - https://datatracker.ietf.org/doc/rfc7489/
>>
>> On Sat, Jan 26, 2019 at 12:21 PM Дилян Палаузов <dilyan.palauzov@aegee.org> wrote:
>>> Hello John,
>>>
>>> On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote:
>>>> In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.camel@aegee.org> you write:
>>>>> How can a domain owner communicate, that its users agree to have investigations on forensic reports, where DKIM
>>>>> signatures failed (fot the purpose of avoiding repeating errors in DKIM signing/validation)?  In particular, that there
>>>>> is no expectation of the users that a deleted message is erased and that the domain owner, DNS staff and email staff
>>>>> function good as whole?
>> This is way outside the scope of DMARC., however, the very fact that the domain has provided an email address for receiving RUF reports is a pretty reliable indicator. Presumably DNS  and mailops staff work for/on behalf of the domain owner.
>>  
>>>> I suppose they could try to put it in the terms of service, but I
>>>> wouldn't begin to guess whether that would be enforcable or even legal
>>>> in places with the GDPR and other privacy laws.
>>>>
>>>> More to the point, I wouldn't bother.  The failure reports are almost
>>>> entirely useless.  Of the ones I get, the majority are random Chinese
>>>> spam that happened to forge one of my domains on the From line, the
>>>> rest are from mailing lists where I wouldn't expect DMARC to pass.
>> Clearing out the chaff originating from servers other than your own helps, but I'm not going to try to teach John anything. 
>>> A domain owner can certainly clarify anything in the terms of service, but even if the domain owner does these
>>> clarifications, s/he will not receive DKIM/DMARC forensic reports, because there is no mean to communicate to the
>>> generators of those reports, that sending forensic reports violates users expectations.
>> Individual user expectations are well outside the scope of DMARC. It is a domain/subdomain level protocol. If you don't want the reports then don't provide a destination for them to be delivered to.
>>> The reasons mentioned here against sending forensic reports were, that this might not match user expectations (on
>>> deleted information) and because email staff and DNS staff may differ.  I approached both concerns, by stating that user
>>> expections can be put in Terms of Use and that a domain owner can decide, that for a domain it is acceptable to receive
>>> forensic reports and insert this infomation in the Terms of Use.  So… what else exactly needs to happen, to resolve the
>>> concerns against sending forensic reports (which was my original question)?
>>>
>>> If GDPR is the only concern, this can also be clarified.  But clarifying that GDPR is not a problem, will be losing
>>> time, if independent of it there are other concerns.
>>>
>>> Imagine there is a failure report stating that after a direct communication between your server and another server, the
>>> receiving server sends you an aggregate report, stating that 1% of the messages you sent yesterday do not validate DKIM.
>>> How do you suggest to proceed to reduce this to 0%?
>> Over time you are unlikely to keep "legitimate" failures at 0%. There are lots of moving parts and pieces that can cause a failure. It also depends on the characteristics of the mail streams involved. The domain owner(s) and staff will need to determine how much effort they are willing to put in eliminating (legitimate) email failures. If I'm sending 10 million emails to a domain and 1% are failing then I'm likely to look into it. On the other hand, if I'm sending 100 emails a day to a domain from an overall large system and 1% (1 email) is failing, that really falls into the noise and is unlikely to get much time spent on it.
>>
>> Michael Hammer
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc


-- 
Vladimir Dubrovin
@Mail.Ru