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

Dotzero <dotzero@gmail.com> Sat, 26 January 2019 17:57 UTC

Return-Path: <dotzero@gmail.com>
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 173FC130F19 for <dmarc@ietfa.amsl.com>; Sat, 26 Jan 2019 09:57:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 o7XBb_HT73QU for <dmarc@ietfa.amsl.com>; Sat, 26 Jan 2019 09:57:05 -0800 (PST)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A306A130F26 for <dmarc@ietf.org>; Sat, 26 Jan 2019 09:57:04 -0800 (PST)
Received: by mail-wr1-x42c.google.com with SMTP id r10so13471854wrs.10 for <dmarc@ietf.org>; Sat, 26 Jan 2019 09:57:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=14oqOnedjC/TdmtsqNmk37Qr7Wrg0zq8aUGnW6poCKY=; b=UU/RK0jP6GyWczn6dX4671Eguf5VGsxlba5h295lH2O7RRjE/OCijjOxnu1vFQ2eo4 PPGp/y6z5DIiQDKKRUhCfjrAflxrJqZKFcppTsgvtVt2VRyEEvMimhjNpYZ4pLQUVtWs 3bCAAfPRCc0ZLloh/PyHKSGzdgNts6yp5ZGhr6AI8DJXxCxMxKSYbrfR3vwJimFO/YAy +yMGAlIOcfjEevDT2m10+lr1USGbFX8i7et5DNp94o0Z+BHJliSAdVEU7YOfb1Boe5HO sjSkMStPtbqdOEcQ4vO4XBfwFjPhYNPi8ag30zEaiFLBHv/C1FfUYtOfl9YZzeRytdo+ FkbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=14oqOnedjC/TdmtsqNmk37Qr7Wrg0zq8aUGnW6poCKY=; b=oMM7WdPJO+J3AsudwxP8MtynNi9WZEaqsLT4xC1L+YyJ0SKYJGJWrakPiFpzoYCc+a lWozUXaI8YZRY46xf4SuUIe85nBP9p3jLD73sHtM8rpFuuZzsuebUEFii0G7KV1CnpEz vOCG8KcL2wkBVYNtZVQD+ARje7JuxA4P/FIGn5di82N+xSxAP4v1lnj9Cj70U0+zGomC sHqEPh2LeDo6wZfEkKQu8bdXURcoZ4hTrtmYbufZJBi89o5z5wk1BaQwDB6sBheQGnj1 3SJhSZpZDNDpQQb48whW8auHRNu9zSN1EVMHVE4AY3oJFA3wQN/dLjFcxQCVzuJgIPh7 GMzg==
X-Gm-Message-State: AJcUukeHP71MQdV1pSwUmPaU3sKNaIyXUOf7SKWgCODvSmQcfvyS/ZC1 s5KmW6QH0FDJJpcKCuQukz/MApRI+J35JsuyxpU=
X-Google-Smtp-Source: ALg8bN7x1zOrKvstEtNitjtoEaKNLG4JXqaHQD4kpcQqmoSBh5ZQl5SzSpdxuUobuvyw5a2lCVK5VH4dX1DXEhDScbw=
X-Received: by 2002:a5d:6b09:: with SMTP id v9mr16477771wrw.304.1548525422935; Sat, 26 Jan 2019 09:57:02 -0800 (PST)
MIME-Version: 1.0
References: <20190126163123.AAA4B200D39816@ary.qy> <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org>
In-Reply-To: <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org>
From: Dotzero <dotzero@gmail.com>
Date: Sat, 26 Jan 2019 12:56:52 -0500
Message-ID: <CAJ4XoYd8zq53MRmsXKx=Fh1n0NpHj=Q+0i5fjD1HDnqDE26++Q@mail.gmail.com>
To: Дилян Палаузов <dilyan.palauzov@aegee.org>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c284b20580602b4d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ICSOH12SQpFYtAz6gXfQElJe2JA>
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: Sat, 26 Jan 2019 17:57:08 -0000

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