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

From: Дилян Палаузов <[email-masked]>
Date: Sat, 26 Jan 2019 11:37:41 +0000

Hello,

for a smooth working DMARC DKIM signers and verifiers must be interoperatable.  When a server DKIM-signs a message and
sends it to another server without intermediates, the latter shall be able verify the signature.  Imagine, the DKIM
validation fails and the ruf= dmarc report email address points to the sending server.

What are the privacy concerns in this simple scenario that speak against sending a DMARC/DKIM report to sending server,
telling that the DKIM validation fails?

https://tools.ietf.org/html/rfc7489#section-9 mentions some privacy thoughts, but these are not applicable when the
sending server obviously has already the reported message and no intermediates are involved, that could expose
additional information.

Regards
  Дилян

---

From: Vladimir Dubrovin <[email-masked]>
Date: Sat, 26 Jan 2019 16:26:18 +0300

Message sender can expect message content is only stored in sender's and
recipient's mailboxes after delivery. If deleted by both sender and
recipient, this message is not longer exists and it's content can not be
recovered.

In this scenario, (partial) message content can be stored in DMARC
forensic subsystem unknowingly to user, it may violate user's privacy
expectations and/or rights, depending on local legislation.

26.01.2019 14:37, Дилян Палаузов пишет:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 26 Jan 2019 14:05:40 +0000

Hello,

how does the unrealistic expectation of message sender and recipient, that a “deleted” message is immediately
irreversibly removed from all backups, differ from the expectation that an “erased” message does not exist in a forensic
subsystem?

Do Terms of Use, that clarify the sending of forensic reports (and backup policies) close the expectation/reality gap?

Regards
  Дилян

---

From: "John Levine" <[email-masked]>
Date: 26 Jan 2019 10:36:49 -0500

>telling that the DKIM validation fails?

The person reading the DMARC reports had enough authority to put a
record in the DNS, but that is not the same thing as being able to
read all of the users' mail.

In large mail systems, different staff have different roles, and very
few of them can look at users' mail.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 26 Jan 2019 16:03:39 +0000

Hello,

> few of them can look at users' mail.

Aha, we have staff dealing with DNS, staff dealing with email boxes and domain owners.

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?

Regards
  Дилян

---

From: "John Levine" <[email-masked]>
Date: 26 Jan 2019 11:31:23 -0500

>is no expectation of the users that a deleted message is erased and that the domain owner, DNS staff and email staff

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.

R's,
John

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 26 Jan 2019 17:21:28 +0000

Hello John,

> rest are from mailing lists where I wouldn't expect DMARC to pass.

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.

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

Regards
  Дилян

---

From: Dotzero <[email-masked]>
Date: Sat, 26 Jan 2019 12:56:52 -0500

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 Дилян Палаузов <[email-masked]>
wrote:

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

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

> generators of those reports, that sending forensic reports violates users

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
> If GDPR is the only concern, this can also be clarified.  But clarifying
> that GDPR is not a problem, will be losing
> 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.

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

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 26 Jan 2019 21:14:18 +0000

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.  Which users?  On the site that sent the initial mail or on
the site that generated the report.  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 Дилян Палаузов <[email-masked]> wrote:
> > Hello John,
> > 
> 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.
>  
> Clearing out the chaff originating from servers other than your own helps, but I'm not going to try to teach John anything. 
> 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.
> 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

---

From: "John Levine" <[email-masked]>
Date: 26 Jan 2019 17:38:12 -0500

In article <[email-masked]> you write:
>such report will not match the expectations of the users.

I'm pretty sure that the people you think you are arguing with are not
on this mailing list.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Sat, 26 Jan 2019 13:29:36 -1000

On Sat, Jan 26, 2019 at 12:38 PM John Levine <[email-masked]> wrote:

> >reiterating over the arguments against sending reports to the ruf= …dmarc
> address, the first provided reason was, that

Nor on any of the other IETF lists :-)

--Kurt

---

From: Vladimir Dubrovin <[email-masked]>
Date: Sun, 27 Jan 2019 03:36:06 +0300

27.01.2019 0:14, Дилян Палаузов пишет:
> .... 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

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 28 Jan 2019 10:15:13 +0100

On Sat 26/Jan/2019 18:21:28 +0100 Дилян Палаузов wrote:

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

No way.  There are lots of little traps, for one example plain text messages
where a line start with "From ", like so:

>From here on, this message likely fails DKIM.

As small as this cases appear, if you program your MTA to fix them before DKIM
signing, you are going to break any OpenPGP/SMIME signatures that users had
affixed before.

You can educate users to use format=flowed, good luck.

You can push for global maildir usage, even harder.

The bottom line is that, in practice, understanding where that 1% failures come
from won't help eliminate them.

Best
Ale
--

---

From: Дилян Палаузов <[email-masked]>
Date: Mon, 28 Jan 2019 12:03:37 +0000

Hello,

sending a notification, when DMARC does not match is comparable to sending a notification/feedback loop, when a user
clicks a message as spam.  In practice, when a company owns two labels, that were distinct companies in the past, for
the one label the new company sends in the feedback loop the user, who clicked the the mail as unwanted, and the other
label does not include the recipient’s mailbox.

Both labels include the Message-Id in the report.  So when the messege was sent to one user, with the Message-Id it is
possible to determine which user clicked the mail as unwanted (provided no transparent MLMs were involved).  When the
message was sent over a mailing list, from the Message-Id it is not possible to determine which user marked the mail as
unwanted.

It is technically possible to provide to every single recipient-copy spread over a mailing list a distinct Message-Id,
in order to be able to conclude from the feedback-loop message, which user marked the mail as unwanted, and be able to
unsubscribe the user from the mailing list.  Is this the way to go, or is the rationalle that the one who implemented
the feedback loop including Message-Id intentionally skipping the recipient mailbox do not understand the big picture?

Will be there any rational concerns, if for a failed DKIM validation a report is sent to the signing server, containing
just the Message-Id, when From: alignes and DMARC p!=none?

Regards
  Дилян

---

From: "John Levine" <[email-masked]>
Date: 28 Jan 2019 14:21:58 -0500

In article <[email-masked]> you write:
>clicks a message as spam.

No, it isn't.  When the user clicks the spam button, she has taken a
specific step to notify someone about the message.  DMARC forensic
reports are entirely automated.

But once again, I am pretty sure the people who you would need to
persuade are not on this mailing list, or any IETF mailing list.

R's,
John