Subject: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

From: Alessandro Vesely <[email-masked]>
Date: Thu, 17 Dec 2020 19:25:48 +0100

We would like to close this ticket two weeks from now, by the end of the year, 
so please get on it.

The ticket text is just:

     Make it clear in privacy considerations that failure reports can provide
     PII well beyond a domain name, and are not sent by most receivers.

Currently, the dmarc-failure-reporting draft includes the Privacy 
Considerations of RFC 7489.  They address which kind of privacy policy may 
conflict with failure reporting.  Yet, that section doesn't say what PII is 
contained in a reported message, except generically mentioning that "These 
reports may expose sender and recipient identifiers (e.g., RFC5322.From 
addresses)".

Do we need to clarify more?

Any lawyers in this WG?

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 17 Dec 2020 21:39:00 -0500

>     PII well beyond a domain name, and are not sent by most receivers.

The current text says that, but it should also point out that
redaction does not always remove PII. Info about sender or recipient
might be encoded in non-obvious places such as the Message-ID or DKIM
selectors.*

Also, whether we use the current Org domain heuristic or a tree walk
to find a higher level DMARC record, there is no way to reliably tell
the relationship between a domain publishing the rua or ruf tag and a
subdomain being reported. Partly this is the Holy Roman Empire
problem, partly the PSL is just incomplete and always will be.

>Any lawyers in this WG?

The IETF most definitely does not provide legal advice.

R's,
John

* - I've been doing that for ages.  Every message gets a unique selector.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 18 Dec 2020 18:53:45 +0100

> might be encoded in non-obvious places such as the Message-ID or DKIM

Info which is encoded in such a way that only the sender can understand rises 
no PII concern, IMHO.  A sender could cache sent messages and devise how to 
encode the corresponding filenames in DKIM selectors.  Reporting just the 
failed signature would leak the whole message by reference.  So what?

> problem, partly the PSL is just incomplete and always will be.

Right.  A user can use a submission server which is trusted not to relay 
messages to third parties.  Yet, ruf= can point to a completely different 
environment.  By reporting failures (which could be each and every message) a 
report producer can be of service to covert communication tracking.

To avoid that risk, one can send just the header, and redact it appropriately. 
Should the spec give practical advice about how to do that?

> The IETF most definitely does not provide legal advice.

That sounds more like a bug than a feature.  We should at least check that any 
advice given is legally sound.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 18 Dec 2020 15:05:43 -0500

> failed signature would leak the whole message by reference.  So what?

Now he knows which forwarded recipients are talking with his users.

> environment.

No, that's not what I was talking about.  I am the registry for 
someplace.ny.us, and the county government is co.someplace.ny.us.  I get 
all of the DMARC reports for the county's mail.  Oops.  I'm not being 
hypothetical here.

> To avoid that risk, one can send just the header, and redact it 
> appropriately. Should the spec give practical advice about how to do that?

Since it doesn't solve the problem, no.

> That sounds more like a bug than a feature.  We should at least check that 
> any advice given is legally sound.

There are 195 countries in the world, and many like the US have states or 
provinces with different legal systems.  Legally sound where?

R's,
John

---

From: Seth Blank <[email-masked]>
Date: Fri, 18 Dec 2020 16:03:58 -0800

I think the general point is that when DMARC was originally written, there
was a general expectation that forensic reports were essential to get
domains to authenticate properly, and would be generally provided.

We now know that forensic reports come from only a handful of places,
mostly due to PII considerations due to how reports are redacted in
practice.

A privacy consideration should say such a thing, specifically clarify what
may be in a report that could be categorized as PII even after intended
redaction, but refrain from legal advice.

Seth, with schrodinger's hat

On Fri, Dec 18, 2020 at 12:05 PM John R Levine <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 19 Dec 2020 17:48:50 +0100

> redaction, but refrain from legal advice.

As John pointed out, an IP address can be classed as personal data in a country and not in another.  It is hard to tell what data could be PII while refraining from legal considerations.  Anyway, email addresses seem to be PII under any legislation.  Indeed, that's the only piece of data mentioned by RFC 6590.  (Hence I guess one should redact also From:, Jesse's point for ticket #61 notwithstanding.)

Yet, spam complaints seem to be sent w/o redaction.

I confess I wouldn't know how to carry out an "intended redaction".  I cannot recall any useful redacting recommendation for email messages.  Most "practical" guides recommend to print them, carefully redact addresses, phone numbers and the like, then scan the result and send the image.  Non so practical for a mail filter daemon.  I read Outlook has a message redaction feature.  I'd be curious about what does that deliver.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 19 Dec 2020 14:52:04 -0500

>> redaction, but refrain from legal advice.

Given how few failure reports we're seeing, perhaps we should just
take out the advice and say something like you can send these as is
or redacted if you want and your policies permit, but most people don't.

It's kind of amusing to know the exact names and e-mail addresses of
everyone at Linkedin who subscribes to the same lists I do, but I
could live without it.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 20 Dec 2020 12:47:56 +0100

> Now he knows which forwarded recipients are talking with his users.

Are failure reports about forwarded messages still useful?  If not so much, 
perhaps we could deplore them.

Keeping the target of forwarded messages private needs to be addressed at 
emailcore as well, though.  Regular bounces leak the same info.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 20 Dec 2020 13:17:03 -0500

>> [ failure reports leak PII including forwarded recipients ]

> perhaps we could deplore them.

There's no mechanical way to tell whether a message has been forwarded as 
opposed to bcc or a mailing list or a local redistribution list or 
whatever.

Given how few sites send failure messages, and that we all seem able to 
manage our DMARC setups without them, I don't think they're worth a lot of 
effort.  Hence my suggestion for simplified advice.

> emailcore as well, though.  Regular bounces leak the same info.

That seems like a great way to destroy mailing lists by not telling them 
which recipients are bouncing.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 21 Dec 2020 18:19:08 +0100

On Sun 20/Dec/2020 19:17:03 +0100 John R Levine wrote:
> opposed to bcc or a mailing list or a local redistribution list or whatever.

One could judge by verified SPF alignment.  Such kind of gross misconfiguration 
can be detected by aggregate reports, so disabling RUF doesn't seem to be an 
irrecoverable loss.

> Given how few sites send failure messages, and that we all seem able to manage 
> our DMARC setups without them, I don't think they're worth a lot of effort.  
> Hence my suggestion for simplified advice.

Agreed.  However, cutting down sending times might be reassuring.

> That seems like a great way to destroy mailing lists by not telling them which 
> recipients are bouncing.

Temporary failures (over quota) don't hurt mailing lists.  Permanent failures 
(target account takedown) deserve bounces right from the forwarding address.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 21 Dec 2020 12:28:06 -0500

> (target account takedown) deserve bounces right from the forwarding address.

Um, the mailing list *is* the forwarding address.

In any event, I think we agree that failure reports are not worth a lot of 
effort here.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 21 Dec 2020 19:06:34 +0100

> Um, the mailing list *is* the forwarding address.

Oh, well, no, in that case the target address is not meant to be kept secret.

> In any event, I think we agree that failure reports are not worth a lot of 

I'd look for ways to trim them down a bit.  Just enough to let them be 
privacy-wise credible.  Besides skipping forwarded stuff (including mailing 
list) and an enable-by-domain feature, avoiding external addresses in ruf= 
could be another simplification.  Not worth?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 21 Dec 2020 13:25:48 -0500

> Oh, well, no, in that case the target address is not meant to be kept secret.

You don't know that.  Keeping in mind that the reports go the the From: 
address, some lists let subscribers see who else is subscribed, but many 
do not.

> privacy-wise credible.

As I would have thought was evident by now, there is no such thing.  We 
have no idea what parts of the message might disclose PII, and we have no 
idea what relationship (if any) the targer of the ruf= might have to the 
author of the messsage.  We can just note that ruf can leak personal info 
and leave it at that.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 21 Dec 2020 19:57:38 +0100

On Mon 21/Dec/2020 19:25:48 +0100 John R Levine wrote:
> address, some lists let subscribers see who else is subscribed, but many do not.

Sorry for my lack of details.  I was considering the cases where a bounce or a 
failure report reveal that [email-masked] forwards to [email-masked]. 
That is, a user may want to receive mail destined to her (old) address, but 
does not want (old) contacts to become aware of her new one.  The address she 
uses to subscribe to a mailing list is obviously revealed to the MLM.  It is 
not secret in that sense.

> As I would have thought was evident by now, there is no such thing.  We have no 
> idea what parts of the message might disclose PII, and we have no idea what 
> relationship (if any) the target of the ruf= might have to the author of the 
> message.  We can just note that ruf can leak personal info and leave it at that.

What is evident is that, as conceived, failure reports break privacy enough to 
make an admin's skin crawl.  I think we should convey the fact that failure 
reports are (to be) sent in limited circumstances and with due circumspection. 
We must underline that in order to differentiate failure from aggregate 
reports, lest people conclude that feedback reporting is a bad idea in general.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 21 Dec 2020 16:01:44 -0500

> Sorry for my lack of details.  I was considering the cases where a bounce or 
> a failure report reveal that [email-masked] forwards to 
> [email-masked]. That is, a user may want to receive mail destined to her 
> (old) address, but does not want (old) contacts to become aware of her new 
> one.  The address she uses to subscribe to a mailing list is obviously 
> revealed to the MLM.  It is not secret in that sense.

You keep confirming what I am saying.

The failure report from [email-masked] would go to the report 
receiver of whoever sent the message in the first place if the MLM doesn't 
munge From, or to the MLM if it does.  Either way, it's leaking PII.

> What is evident is that, as conceived, failure reports break privacy enough 
> to make an admin's skin crawl.

Right.

> I think we should convey the fact that failure reports are (to be) sent in limited circumstances and with due 
> circumspection.

Yes, that is more or less what I have been saying, only I'd say you 
probably don't want to send them at all since they have turned out not to 
be important.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Dec 2020 10:22:22 +0100

On Mon 21/Dec/2020 22:01:44 +0100 John R Levine wrote:
>> I think we should convey the fact that failure reports are (to be) sent in 
>> limited circumstances and with due circumspection.
> 
> Yes, that is more or less what I have been saying, only I'd say you probably 
> don't want to send them at all since they have turned out not to be important.

Saying so ourselves would corroborate our credibility.  One place to change is 
the second paragraph in the Introduction.  For example:

OLD

    "Failure reports," or "failed message reports," provide diagnostic
    information about messages that a Mail Receiver has determined do not
    pass the DMARC mechanism.  These reports are generally sent at the
    time such messages are received and evaluated, to provide the Domain
    Owner with timely notification that such failures are occurring, and
    to provide information that may assist in diagnosing the cause of the
    failures.

NEW

    Failure reports provide detailed information about the failure of a single
    message or a group of similar messages failing for the same reason.  They
    are meant to aid extreme cases where a domain owner is unable to detect why
    failures reported in aggregate form did occur.  As an extension of other
    kinds of failure notifications, these reports can contain either the content
    of a failed message or just its header.  The latter characteristic entails
    severe privacy concerns.  For that reason, and because it turned out not to
    be important, failure reporting is usually disabled.

Best
Ale
--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Dec 2020 08:16:05 -0800

>    be important, failure reporting is usually disabled.
I'm not understanding what this "severe privacy concerns" are. It looks 
like a glorified bounce message to me. My messages pass through the 
originating domain in the clear, but it only becomes a "severe privacy 
concern" when it is reflected back? How does that work?

Mike

---

From: "John R Levine" <[email-masked]>
Date: 22 Dec 2020 11:39:09 -0500

I think that text is way too long and overspecific but we've already spent 
too much time on this so I'll stop and see if there are other opinions.

On Tue, 22 Dec 2020, Alessandro Vesely wrote:
>   are meant to aid extreme cases where a domain owner is unable to detect > why
>   kinds of failure notifications, these reports can contain either the > content
>   severe privacy concerns.  For that reason, and because it turned out not > to

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Dec 2020 17:50:58 +0100

On Tue 22/Dec/2020 17:16:05 +0100 Michael Thomas wrote:
> I'm not understanding what this "severe privacy concerns" are. It looks like a 
> glorified bounce message to me. My messages pass through the originating domain 
> in the clear, but it only becomes a "severe privacy concern" when it is 
> reflected back? How does that work?

Unlike bounces, you're delivering PII info to a third party.

In Europe, if you setup failure reporting that way, having a third-party 
handling/ processing meta-data or even mail content requires you to inform your 
customers about that, and ask permission.  If third-party is outside EU, since 
privacy shield got canceled last July, there is not even a legal basis anymore 
that would allow you to do so at all.  In all cases, you would be held 
responsible for your customers data unless third-party is signing contracts 
with you to accept EU privacy laws.  EU has severe penalty for companies which 
breaking GDPR.

I cannot tell for Canada or Australia.

Best
Ale
--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Dec 2020 09:02:10 -0800

On 12/22/20 8:50 AM, Alessandro Vesely wrote:
>> I'm not understanding what this "severe privacy concerns" are. It 
>> looks like a glorified bounce message to me. My messages pass through 
>> the originating domain in the clear, but it only becomes a "severe 
>> privacy concern" when it is reflected back? How does that work?
>
>
> In Europe, if you setup failure reporting that way, having a 
> third-party handling/ processing meta-data or even mail content 
> requires you to inform your customers about that, and ask permission.  
> If third-party is outside EU, since privacy shield got canceled last 
> July, there is not even a legal basis anymore that would allow you to 
> do so at all.  In all cases, you would be held responsible for your 
> customers data unless third-party is signing contracts with you to 
> accept EU privacy laws.  EU has severe penalty for companies which 
> breaking GDPR.
>
>
Sorry, having to ask for permission because of laws does not constitute 
a "severe privacy concern". That is completely outside of the scope of 
IETF and we should be pandering to it.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Dec 2020 19:59:58 +0100

On Tue 22/Dec/2020 18:02:10 +0100 Michael Thomas wrote:
>>> I'm not understanding what this "severe privacy concerns" are. It looks like 
>>> a glorified bounce message to me. My messages pass through the originating 
>>> domain in the clear, but it only becomes a "severe privacy concern" when it 
>>> is reflected back? How does that work?
>>
>> handling/ processing meta-data or even mail content requires you to inform 
>> your customers about that, and ask permission. If third-party is outside EU, 
>> since privacy shield got canceled last July, there is not even a legal basis 
>> anymore that would allow you to do so at all.  In all cases, you would be 
>> held responsible for your customers data unless third-party is signing 
>> contracts with you to accept EU privacy laws.  EU has severe penalty for 
>> companies which break GDPR.
>
> Sorry, having to ask for permission because of laws does not constitute a 
> "severe privacy concern".

Except in the sense that they're called privacy laws.  Do you have a better 
wording?

> That is completely outside of the scope of IETF and we should be pandering
> to it.

Making specifications that cannot be legally abided by is in IETF scope?

Best
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 22 Dec 2020 11:33:35 -0800

> Making specifications that cannot be legally abided by is in IETF scope?

Sure - RFC 7258. Unless you want to play the semantic card of BCP vs.
specification.

--Kurt

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Dec 2020 11:41:06 -0800

On 12/22/20 10:59 AM, Alessandro Vesely wrote:
>
>> Sorry, having to ask for permission because of laws does not 
>> constitute a "severe privacy concern".
>
>
> Except in the sense that they're called privacy laws.  Do you have a 
> better wording?

I don't know what was wrong with the initial text. But it most certainly 
is not a "severe privacy concern", especially if it is the originating 
domain getting the report. It already saw the original message in the 
first place assuming it wasn't spoofed, and if it was spoofed they are 
entitled to see it for forensics if the receiving domain is willing to 
send it to them.

> Making specifications that cannot be legally abided by is in IETF scope?
If the laws are unreasonable? Sure. We're not putting backdoors in for 
encryption either. It's their laws, let them figure it out.

But you said that providers can get people to opt in, so that seem moot.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 23 Dec 2020 10:15:58 +0100

On Tue 22/Dec/2020 20:41:06 +0100 Michael Thomas wrote:
> I don't know what was wrong with the initial text. But it most certainly is not 
> a "severe privacy concern", especially if it is the originating domain getting 
> the report. It already saw the original message in the first place assuming it 
> wasn't spoofed, and if it was spoofed they are entitled to see it for forensics 
> if the receiving domain is willing to send it to them.

It may happen that the ruf= address ends up at the same submission server that 
issued the original message, but that's not guaranteed.  John mentioned a real 
example.

> encryption either. It's their laws, let them figure it out.

Failure reporting is rather akin to backdoors, in the sense that it can be used 
for pervasive monitoring.  IMHO, GDPR is long winded and lacks practical design 
elements that could have inspired privacy-protecting protocols, but its intent 
is certainly not unreasonable.

> But you said that providers can get people to opt in, so that seem moot.

I'd recommend that software implements failure reporting, leaving it disabled 
with the possibility to enable it by domain in case of need.  However, such 
recommendation would be an addition to the protocol, so it is not going to make 
it to the spec.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 23 Dec 2020 10:16:08 +0100

> Sure - RFC 7258. Unless you want to play the semantic card of BCP vs.

I don't get it.  Do you mean that failure reporting can be assimilated to 
pervasive monitoring, and deserves mitigation as such?

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Wed, 23 Dec 2020 05:56:04 -0500

> >   be important, failure reporting is usually disabled.
The following is factually and technically incorrect: " The latter
characteristic entails severe privacy concerns." The latter characteristic
"the header". In fact, the full message can contain much more PII and/or
PHI.

> Please consider the environment before reading this e-mail. https://jl.ly

I agree with John. I'll go further and say that the working group should
focus on what the IETF does best - technical specifications that involve
interoperability - and avoid straying too far into the realms of law and
politics. While the EU and GDPR may impact choices that operators make,
there are other legal jurisdictions in the world. Further, my experience
has been that many operators (receivers) only provide failure reports when
contractual relationships (direct or indirect) exist between the parties
involved. This can certainly meet the privacy requirements of GDPR and
other privacy regulations.

In conclusion, suppositional assertions such as " For that reason, and
because it turned out not to be important, failure reporting is usually
disabled." should not be included in the proposed standard. Could someone
(anyone?) provide data that failure reports are not important? One example
of the importance and usefulness of failure reports is for domains that
actually have control of their mail flows. By pulling all the URLs from
failure reports (received through a contracted party) and then removing all
the URLs which we included in the mail that we had originally sent, all
that was left was 100% badness and maliciousness. This significantly
empowered our takedown efforts.

Michael Hammer

---

From: [email-masked]
Date: Wed, 23 Dec 2020 08:54:01 -0800 (PST)

> "the header". In fact, the full message can contain much more PII and/or

Quite right. It's also unforunate that we appear to be spending more arguing
about what consistutes a legitimate privacy concern than reviewing proposed
text.

I also note that saying what's "usually done", even if currently correct, is at
best the province of a BCP. It has no business being in a standard.

> other privacy regulations.

Agreed, but none of this belongs in the standard either. All the standard needs
to say is that message header and bodies can contain personally identifiable
information and that this may affect the choice of whether or not to send
failure reports. Something like:

  Failure reports provide detailed information about the failure of a single
  message or a group of similar messages failing for the same reason. They
  are meant to aid in cases where a domain owner is unable to detect why
  failures reported in aggregate form did occur. It is important to note
  these reports can contain either the header or the entire content of a
  failed message, which in turn may contain personally identifiable
  information, which should be considered when decoding whether or not to
  generate such reports.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 23 Dec 2020 13:10:30 -0500

>  information, which should be considered when decoding whether or not to

Ship it.

Regards,

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 23 Dec 2020 12:03:28 -0800

> >  information, which should be considered when decoding whether or not to

With one minor correction, I agree. The minor correction is in the last
sentence: s/decoding/deciding/

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 23 Dec 2020 12:06:33 -0800

Hatless:

> >  information, which should be considered when decoding whether or not to

Modulo a couple of tweaks (below), I agree.

Failing that, I have another proposal to consider that might aid us in
shipping a standards track DMARC sooner: Remove any and all mention of
failure reports, and do all that in a later add-on document as was done
with RFC 6651.

Tweaks:

* s/whether or not/whether/
* s/decoding/deciding/

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 23 Dec 2020 15:08:30 -0500

> * s/whether or not/whether/

Sure.  Now ship it?

> failure reports, and do all that in a later add-on document as was done

Given how marginal failure reports have turned out to be, that doesn't 
seem like a great use of our time.

Regards,

---

From: [email-masked]
Date: Wed, 23 Dec 2020 12:13:09 -0800 (PST)

> sentence: s/decoding/deciding/

Yes, sorry about that.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 23 Dec 2020 13:51:41 -0800

> seem like a great use of our time.

Well the "Remove" part was the key to getting us unstuck if this turns out
to be a pain point, if they are indeed marginal and seldom used.  So stick
a "maybe" before "do".

-MSK

---

From: Dotzero <[email-masked]>
Date: Wed, 23 Dec 2020 19:34:26 -0500

> to be a pain point, if they are indeed marginal and seldom used.  So stick

Based on my experience, I disagree that failure reports are marginal and
seldom used. It's kind of like an iceberg, mostly below the surface. Seeing
as most of the action is (currently) between contracted parties, it would
be nice to hear some of the intermediaries such as Agari, ValiMail,
Dmarcian and ? chime in. Perhaps some of the large mailbox providers could
chime in on number of domains they are sending failure reports for. If
individual companies providing numbers are a problem, perhaps M3AAWG could
provide combined numbers from a number of mailbox providers/receivers.

Michael Hammer

---

From: "John R Levine" <[email-masked]>
Date: 23 Dec 2020 21:11:47 -0500

On Wed, 23 Dec 2020, Dotzero wrote:
> seldom used. It's kind of like an iceberg, mostly below the surface. ...

Seems to me that if we splice in Ned's tweaked privacy language, we're 
done.  I don't see any reason to change the technical spec.  People will 
send what they send, and it's become clear that we have nothing useful to 
say about what one might redact.

Regards,

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 23 Dec 2020 21:39:03 -0500

I Believe I agree with the current version, but can someone post what we
think is the final text?

tim

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 24 Dec 2020 10:35:10 +0100

On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote:
> I Believe I agree with the current version, but can someone post what we think 
> is the final text?

I posted it here:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting

I don't think the text is final, though.  Besides minor tweaks in the first 
paragraphs of Section 3, the whole discussion about external destinations has 
to be stroked and replaced with a reference to aggregate reporting.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 24 Dec 2020 13:55:07 -0500

>> I Believe I agree with the current version, but can someone post what we 

See below, with the two changes mentioned before and Mr Copy Edit's minor 
tightening up which I hope are not controversial.

> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting

Hold it. I don't recall that we agreed to break failure reports into a 
separate document.  It makes more work and I see no agreement to change
anything beyond the security paragraph.  In particular, we have nothing to 
offer on what one might or might not redact.

R's,
Jobn

Security considerations

Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same
reason. They are meant to aid domain owners to detect why failures
reported in aggregate form occured. It is important to note these
reports can contain either the header or the entire content of a
failed message, which in turn may contain personally identifiable
information, which should be considered when deciding whether to
generate such reports.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 26 Dec 2020 11:47:26 +0100

On Thu 24/Dec/2020 19:55:07 +0100 John R Levine wrote:
> Hold it. I don't recall that we agreed to break failure reports into a separate 
> document.

The fact that draft-ietf-dmarc-failure-reporting-00 exists on IETF datatracker 
seems to confirm WG consensus.  But see also:
https://mailarchive.ietf.org/arch/msg/dmarc/2DsSazvE9QxFjVSeg_mdNlRMETM

> It makes more work and I see no agreement to change anything beyond the
> security paragraph.  In particular, we have nothing to offer on what one
> might or might not redact.

I still think it'd be a good idea to mention RFC 6590...

Anyway, the change at hand arose from a ticket, as per Subject:.  After a long 
discussion, the new paragraph was explicitly proposed for the Introduction of 
the separated document, where it is most effective.  IMHO, Ned's wording —which 
you said to ship— is more comprehensive than the abbreviated version quoted 
below, hence preferable.

Why did you change your mind?

Best
Ale

> reported in aggregate form occurred. It is important to note these

---

From: Todd Herr <[email-masked]>
Date: Mon, 28 Dec 2020 08:29:48 -0500

> information, which should be considered when deciding whether to
Sorry; late to the party due to the holiday...

Is it not also important to note that the recipient of the failure report
(the domain owner) may not be the originator of the failed message, and
that fact should also weigh into the consideration of deciding whether to
generate such reports?

If A publishes a DMARC policy record, and a bad actor sends intentionally
fraudulent mail using A's domain as the RFC5322.From to addresses that are
not among A's current customer base, and therefore unknown to A, sending
failure reports to A that don't redact these email addresses reveals PII to
A that A has no business receiving.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:* 703.220.4153

---

From: Dotzero <[email-masked]>
Date: Mon, 28 Dec 2020 09:12:28 -0500

> A that A has no business receiving.

Todd,

Would this be akin to the proprietary and confidential information, as
indicated in the footer of your email message, which you sent to a publicly
accessible list operating under IETF's "Note Well" policy?  Some might
argue that receipt of this information in DMARC failure reports is a
feature and not a bug. Just as the ability to use WHOIS in fighting abuse
has been gutted as a result of GDPR, do we really want to go down a path of
warning people of "dangers" in such an un-nuanced manner?

I agree with John and others that a generic warning regarding security and
privacy issues is the more useful approach given that this is a technical
standard and vague hand waving is not particularly useful as an
implementation guide. For bad guys using/abusing real email addresses as
destinations, the privacy ship has sailed as someone somewhere got breached
or the addresses got scraped. The same goes for originating From and Mail
>From addresses, except the originating domain is already aware of them.
Given the choice between writing a book that few will read and even less
will understand, and writing a brief generic warning, I choose short and
generic.

Michael Hammer

---

From: [email-masked]
Date: Mon, 28 Dec 2020 06:54:24 -0800 (PST)

> seems to confirm WG consensus.

I'm not ethusiastic about the split, but if that's what people want then so be
it. I will say that my experience has been that doing so is usually more work
and provides less benefit than you'd expect.

That said, the adoption of something as a WG document, especially one with an
intended status of <none> and in the absence of a corresponding charter update,
doesn't really mean much. 

I also don't see where the discusssion leading to the WG consensus on the
split occurred on the mailing list. Perhaps you could point me at it?

> But see also:

> I still think it'd be a good idea to mention RFC 6590...

Why? RFC 6589 documents a generic approach to partial information hiding. It
does not specify how to apply this technique to DMARC failure reports, and
doing so effectively requires a careful assessment of what needs to be hidden
and what does not, and that in turn drags in all of the specifics we need to
avoid in a base document of this sort.

Indeed, as things stand, since the intent of RFC 6589 is to preserve some
information, we can't even say it solves any particular problem with DMARC
failure reports.

				Ned

P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
standards-track status to be nothing short of astonishing. How on earth do you
assess interoperability?

---

From: Todd Herr <[email-masked]>
Date: Mon, 28 Dec 2020 10:48:10 -0500

> will understand, and writing a brief generic warning, I choose short and

Michael,

I am not opposed to the generic warning, but the following sentence in the
proposed warning gives me pause:

"They are meant to aid domain owners to detect why failures reported in
aggregate form occured."

The implication, to me, in that sentence is that the failure report will be
sent to the party that originated the message, and that's not always going
to be true. All failure reports will be sent to the domain owner, but the
domain owner will not always be the originating party for the message in
the failure report.

I'm not a lawyer, but providing A with some information about a message
that A sent to X seems different, from a privacy perspective, than
providing A with some information about a message impersonating A that B
sent to X, and I thought perhaps the generic warning might mention this
distinction, if possible. Something like:

Security considerations

Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same
reason. They are meant to aid domain owners to detect why failures
reported in aggregate form occured. It is important to note these
reports can contain either the header or the entire content of a
failed message, AND THAT THE DOMAIN OWNER RECEIVING THE
REPORTS MAY NOT BE THE ORIGINATING PARTY FOR THE MESSAGE(S)
REFERENCED IN THE FAILURE REPORTS. IN ANY CASE, THEY may contain
personally identifiable information, which should be considered when
deciding
whether to generate such reports.

--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Dec 2020 07:57:45 -0800

On 12/28/20 7:48 AM, Todd Herr wrote:
>  not a lawyer, but providing A with some information about a message 
> providing A with some information about a message impersonating A that 
> B sent to X, and I thought perhaps the generic warning might mention 
> this distinction, if possible. Something like:
>
>     Security considerations
>
>     personally identifiable information, which should be considered
>     when deciding

This is a tempest in a tea pot. This is an issue with the originating 
domain and nobody else. They can send it to a third party even if the 
url lists them to receive the report first.  The receiving domain can't 
know what they will do with the report, and the originating domain has 
already seen the mail in clear text before it was sent. IETF should stay 
out of the business of being nannies that it has no way to enforce.

Mike

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 28 Dec 2020 11:14:41 -0500

I would drop that whole third sentence, and mention sending such reports
may contain PII.
The document can refer the reader to non-IETF documents for information,
but in general
we do technical standards, and stay away from policy decisions in standards
track documents.

tim

On Mon, Dec 28, 2020 at 10:57 AM Michael Thomas <[email-masked]> wrote:

>  not a lawyer, but providing A with some information about a message that
> A sent to X seems different, from a privacy perspective, than providing A
> with some information about a message impersonating A that B sent to X, and
> I thought perhaps the generic warning might mention this distinction, if
> possible. Something like:
>
> Security considerations
>
> domain and nobody else. They can send it to a third party even if the url
> lists them to receive the report first.  The receiving domain can't know
> what they will do with the report, and the originating domain has already
> seen the mail in clear text before it was sent. IETF should stay out of the
> business of being nannies that it has no way to enforce.
>
> Mike

---

From: "John R Levine" <[email-masked]>
Date: 28 Dec 2020 12:06:18 -0500

> and provides less benefit than you'd expect.

I recall agreeing to split out all of the reporting into a separate draft, 
which makes some sense so the two parts can proceed separately, but not 
further splitting aggregate and failure reports.

Regards,

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 28 Dec 2020 13:00:12 -0500

I will admit my memory can get pretty hazy, but I agree with Mr Levine - I
remember splitting out reporting,
but only as one document.

The Working Group can always make a compelling case to change this

tim

---

From: Seth Blank <[email-masked]>
Date: Mon, 28 Dec 2020 10:05:57 -0800

We agreed to split aggregate and failure reporting into different
documents, and this split was discussed on the list several times, as well
as at IETF 108.

The intention was to split apart the key components that realistically get
updated in different manners / at different cadences.

Aggregate reports and failure reports get used in wholly different manners,
have fundamentally different use cases, are implemented in wildly different
ways, and have completely different privacy and security considerations.
Hence, we agreed they should be split into separate documents, so each can
be concise, to the point, and independently updated.

Seth, as Chair

--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Dec 2020 10:17:34 -0800

On 12/28/20 10:05 AM, Seth Blank wrote:
> documents, and this split was discussed on the list several times, as 
> well as at IETF 108.
>
> The intention was to split apart the key components that realistically 
> get updated in different manners / at different cadences.
>
> Aggregate reports and failure reports get used in wholly different 
> manners, have fundamentally different use cases, are implemented in 
> wildly different ways, and have completely different privacy and 
> security considerations. Hence, we agreed they should be split into 
> separate documents, so each can be concise, to the point, and 
> independently updated.
>

Does that mean all of the reporting? So that DMARC is really ADSP-bis? 
The reporting is clearly a completely separate protocol from the policy 
mechanism, and is far more likely to mutate than the base policy 
mechanism which has changed very little from ADSP. I mean, as far as I 
can tell the main change from ADSP is to include spf too.

Mike

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2020 13:49:15 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-

All true, but the actual specs overlap quite a lot. For example, where
does section 7.1 about verifying external destinations go? If the
answer is that it's copied into two documents, that is bad.

I think we've seen that for failure reporting there is nothing to
change beyond updating the privacy considerations, so leaving all the
reporting in one document is unlikely to cause schedule problems.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2020 13:52:18 -0500

>that fact should also weigh into the consideration of deciding whether to

The exact same issue applies to aggregate reports which can leak a
fair amount of PII from domains with modest amounts of traffic so you
can guess who sent what.  See my prior message about the county government.

R's,
John

>this email and then delete it from your system.

Somehow this boilerplate seems especially ironic.

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Dec 2020 14:31:27 -0500

On 12/28/2020 1:17 PM, Michael Thomas wrote:
>> documents, and this split was discussed on the list several times,
>> as well as at IETF 108.
>>
>> The intention was to split apart the key components that
>> realistically get updated in different manners / at different cadences.
>>

When Seymour Cray was asked by his engineers building the Cray super 
computer, what primary language should they use for the new concept of 
Vectorization computing, Seymour responded; "I don't care what 
language we use ... just call it FORTRAN!"

It's marketing now, folks. It was what academia was teaching and 
industry engineers were using at the time.  Lets just get the 
DKIM-POLICY model done and call it DMARC. I really don't care because 
the basic fundamental concept has been established and to me, that is 
the most significant gain we have here - the DKIM-POLICY DNS LOOKUP 
concept has traction.

Yes, functionally, they were all the same, SSP, ADSP, DSAP and DMARC, 
from the basic LMAP "Lightweight Mail Authorization Protocol" concept 
of using an author domain for a DKIM-POLICY DNS lookup model. DMARC is 
the latest with a different syntax language that has gained traction. 
I support DMARC for that only reason -- its about TIME!!  I rather we 
define the protocol DKIM-POLICY Model because we already have a 
DKIM-TRUST model in the standard.

Nonetheless, now we can piggy-back off the _dmarc.example.com DNS 
lookup rather than _adsp._domainkey.example.com.

All the same concept, therefore all the same problems. Lets get DMARC 
done as a basic-lookup protocol and begin adding more to it related to 
3rd party authorization protocols which can piggy-back of the DNS 
call.   Reporting should of always been a separate consideration.

PS: Consider how many DNS lookups an all-things SMTP receiver does for 
port 25, non-authenticated/Authorized connections. For wcSMTP:

At connection:

IP Geo Location Filter
IP DNS RBL

At SMTP before DATA

Maybe EHLO domain DNS matching check
Maybe EHLO domain SPF check
Maybe MAIL FROM SPF check
Maybe MAIL FROM Call Back Verifier (MX)

At SMTP DATA if it gets this far:

Maybe DKIM check
Maybe ADSP 5322.From check
Maybe DMARC 5322.From check
Maybe ATPS 5322.From check
Maybe VBR 5322.From check

Overall, there are a lot of calls today per SMTP session.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 28 Dec 2020 21:13:48 +0100

On Mon 28/Dec/2020 16:48:10 +0100 Todd Herr wrote:
>     "They are meant to aid domain owners to detect why failures reported
>     in aggregate form occurred."
> 
> sent to the party that originated the message,

How do you derive that?  To me, the sentence seems to implicate that failure 
reports go to the same entity which receives aggregate reports.  That's not 
always going to be true either.  The point should be that the authority who 
decides where either kind of reports go is the same who publishes the public 
keys.  "Domain owners" is meant to indicate such authority.

Best
Ale
--

---

From: [email-masked]
Date: Mon, 28 Dec 2020 12:41:57 -0800 (PST)

> further splitting aggregate and failure reports.

I was referring to the latter; I thought the reference to the drafts involved
made that clear. Sorry for the confusion.

The outcome of the split of MIME part one into four parts may offer some
limited insight here. IMO splitting message bodies from media types was a sound
logical split and ended up being a good thing. The split of conformance
criteria from media types, however, was a pretty serious lose - they now tend
to get ignored - so much so it's tempting to try and undo it.

But the split of media type registration from MIME/email was the real win, so
much so that it more than justified the entire activity.
 
The lesson, if there is one, is to go just far enough, but no further.
Splitting different reporting types smells a lot like "further" to me.

				Ned

---

From: Todd Herr <[email-masked]>
Date: Mon, 28 Dec 2020 16:20:55 -0500

> keys.  "Domain owners" is meant to indicate such authority.
Forgive me, as my words weren't clear here.

"[Failure reports] are meant to aid domain owners to detect why failures
reported in aggregate form occurred" says to me that the idea behind
failure reports is to put them in the hands of a party that can address the
failures.

DMARC validation failures can be caused either due to legitimate mail
(i.e., mail originated by or on behalf of the publisher of the DMARC
policy, a.k.a., the domain owner) failing authentication checks due to a
shortcoming in the authentication practices of the domain owner or some
other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail
not originated by or on behalf of the domain owner, so mail intended to
fraudulently impersonate the domain), specifically the kind of mail that
DMARC is purported to be designed to stop.

All reports will go to the domain owner, and they should all go to the
domain owner, but the domain owner will have no interest in fixing the
authentication practices of the illegitimate mail streams identified by
failure reports, nor would it have the ability to do so even if it wanted
to.

I believe at one time long ago there was an idea that a second possible
usage for failure reports showing illegitimate mail was to give the domain
owner evidence to present to an abuse desk or takedown vendor to get the
illegitimate mail cut off at its source, but I don't know that for certain.
Without such a use case, failure reports regarding mail that the domain
owner didn't cause to be originated are just noise, because there's no
action that the domain owner can take.

--

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2020 17:16:20 -0500

>illegitimate mail cut off at its source, but I don't know that for certain.

We did think of that, but at least in my experience all of the failure
reports that aren't legit messages handle were random forgeries from
Chinese networks where the spammers were just taking addresses from
their spam lists. Perhaps if my name were Paypal I'd see some targeted
fakery but it's not my impression that kind of faked mail is sent from
fixed sources.

>action that the domain owner can take.

Yup.  Still don't think failure reports need a separate document.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 28 Dec 2020 23:03:46 -0800

> standards-track status to be nothing short of astonishing. How on earth do

With the benefit of hindsight, that's a great question.  I'd have been
happy with Informational.  Indeed, the IESG evaluation record shows several
ADs brought that up, but none of them insisted, and thus it didn't get
changed.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 29 Dec 2020 10:33:30 +0100

On Mon 28/Dec/2020 15:54:24 +0100 ned+dmarc wrote:
> Why? RFC 6590 documents a generic approach to partial information hiding. It

The failure-reporting draft references RFC6591.  The only appearance of the 
term "redaction" occurs in the 2nd paragraph of Section 4.1:

    These reports may expose sender and recipient identifiers (e.g.,
    RFC5322.From addresses), and although the [RFC6591] format used for
    failed-message reporting supports redaction, failed-message reporting
    is capable of exposing the entire message to the report recipient.

RFC6591 doesn't go into a very detailed description.  It references RFC6590:

    For privacy reasons, report generators might need to redact portions
    of a reported message, such as an identifier or address associated
    with the end user whose complaint action resulted in the report.  A
    discussion of relevant issues and a suggested method for doing so can
    be found in [RFC6590].

RFC6590, in turn, avoids the specifics of what exactly needs to be redacted. 
However, it mentions the local parts of email addresses.

> standards-track status to be nothing short of astonishing. How on earth do
> you assess interoperability?

Maybe it's the ability to relate reports from the same source with one another 
which makes them manageable.  Producers of actionable reports and consumers who 
react properly can be said to interoperate, can't they?

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 29 Dec 2020 10:59:30 +0100

> DMARC is purported to be designed to stop.

That kind of analysis seems to be missing from the draft.  After some years of 
experience,  we should be able to provide some, I'd hope.  If not, we'd better 
bluntly drop the draft.

Personally, I used to receive a few of them.  None at all now.  The only 
mention I recall about failure reports was an old article, by Terry Zinc IIRC, 
where he said they're key for telling abusers from legit operators needing 
realignment.  I don't recall why that info couldn't be derived from the source 
IPs though.

Best
Ale
--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 06:50:50 -0800

On 12/28/20 11:03 PM, Murray S. Kucherawy wrote:
> On Mon, Dec 28, 2020 at 7:23 AM <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> happy with Informational.  Indeed, the IESG evaluation record shows 
> several ADs brought that up, but none of them insisted, and thus it 
> didn't get changed.
>
What I had always expected to happen was, among other things, that MUA's 
would use it for like a web-like padlock too. At that point you have a 
protocol consumer. It's sort of disappointing they by and large don't 
from what I've seen. Hence my question on another thread DMARC fail, 
with p=none. That seems wrong and would definitely send the wrong signal 
to the MUA on how to mark it up.

Mike, who has now hacked on a thunderbird extension

---

From: [email-masked]
Date: Tue, 29 Dec 2020 06:55:52 -0800 (PST)

> term "redaction" occurs in the 2nd paragraph of Section 4.1:

Referencing an approved standards document on failure reporting formats is
perfectly reasonable and even necessary.

> However, it mentions the local parts of email addresses.

If anything this is an even stronger case for not referencing RFC 6590 here -
it's unnnecessary because the reference is already in the failure reporting
format specification.

I also note that RFC 6591 was published in 2012, long before PII became such a
contentious issue. Timing can be everything.

> react properly can be said to interoperate, can't they?

Absent agreement on what gets redacted and how? Not even close.

RFC 6590 doesn't even pass muster as a BCP, since it describes an overall
approach to solving a range of problems and explictly does not recommend
a particular practice.

This is an informational document, nothing more and nothing less.

				Ned

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 08:25:05 -0800

>     standards-track status to be nothing short of astonishing. How on

Ned -- rfc6589 is a ipv6 informational doc. which rfc are you actually 
referring to?

Mike

---

From: [email-masked]
Date: Tue, 29 Dec 2020 09:22:18 -0800 (PST)

> experience,  we should be able to provide some, I'd hope.  If not, we'd better

I think a list of possible failure causes would be nice to have, because
a lot of people seem to think that DMARC is a completely reliable mechanism.

I'm not entirely convinced this document is the place for it, but OTOH
I'm not convinced it isn't.

It also strikes me as more of an exercise in enumeration of possibilities than
an actual analysis.

Let's see. We have:

  o Illegitimate mail
  o Message changed in transit, invalidating DKIM signature
  o Incorrect DKIM signing
  o Incorrect SPF setup
  o Unintentional domain misalignment
  o Improper assertion of DMARC policy

We get regularly get problem reports whose root cause turns out to be one of
these things.

I've probably missed a bunch, and this may not be the best way to compose the
list.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2020 13:59:09 -0500

>I'm not convinced it isn't.

Sounds like a separate WCP document.  I agree it could be nice to have something
to point to when people insist that it's my fault that their DMARC rules don't
match the way my mail system works.

>  o Improper assertion of DMARC policy

Don't forget

 o Normal forwarding of SPF validated mail
 o Authorized third party senders with no access to DKIM keys

Could be an interesting document.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 11:03:33 -0800

>   o Authorized third party senders with no access to DKIM keys
If by "authorized" you mean authorized by the originating domain, I don' 
t have a lot of sympathy since they can delegate them a selector and 
update their DNS. Not doing so is just lazy.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 29 Dec 2020 20:37:38 +0100

> I'm not convinced it isn't.

A list of failure causes w/o further considerations may well live in an 
appendix of the main document.  If failure causes are specifically categorized 
for failure reports, this document becomes a good candidate.

>   o Message changed in transit, invalidating DKIM signature
        o Unintended DKIM breakage
        o Intentional DKIM breakage (e.g. MLM)
     o DKIM signatures not evaluated or not reported
     o Missing DKIM signature
>   o Incorrect SPF setup
     o "Mute" forwarding (SPF failure)
     o VERP disalignment
> We regularly get problem reports whose root cause turns out to be one of
> these things.

The point is working out why one cannot understand the failure reason from 
aggregate reports.  In what cases we do need a failure report in order to 
understand what's wrong?  Maybe we need better aggregate reports?

I found one problematic report today, reported by Yahoo! (Oath) on behalf of aol:

   <record>
     <row>
       <source_ip>4.31.198.44</source_ip>
       <count>1</count>
       <policy_evaluated>
         <disposition>none</disposition>
         <dkim>fail</dkim>
         <spf>fail</spf>
       </policy_evaluated>
     </row>
     <identifiers>
       <header_from>tana.it</header_from>
     </identifiers>
     <auth_results>
       <spf>
         <domain>ietf.org</domain>
         <result>pass</result>
       </spf>
     </auth_results>
   </record>

4.31.198.44 is mail.ietf.org.  DKIM and SPF are not aligned, hence the failure. 
  I'm surprised there are no DKIM signatures.  Now I'm going to add "DKIM 
signatures not evaluated or not reported" to the list above, as it turns out 
that Yahoo! seem to report valid signatures only.  Anyway, would I have got a 
better understanding had I received a ruf as well?

One thing a failure reports brings is the Received: (or ARC) chain.  If I 
wandered how come the IETF sends messages with my header_from, a ruf might 
help.  Is that a real case?  Forwarding for email address portability (either 
"mute" or SRS) is probably not even worth being reported, since there's nothing 
a mail admin can do about that —updating the address could be done by the 
author, had the server returned a 251/551.

Today's other reports are even more straightforward.  But then I run such a 
tiny server that I don't get an interesting assortment of cases.

Another question is *if* I were running a large server and *if* that 
problematic record had a <count>1 zillion</count>, how many of the 
corresponding failure reports would I read, assuming I received any?

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2020 15:10:52 -0500

>update their DNS. Not doing so is just lazy.

A lot of tiny non-profits like Girl Scout troops use email addresses
at webmail providers and send their announcements through ESPs like
Constant Contact and Mailchimp.  This is yet another situation where
DMARC can't describe an entirely normal mail setup.

Constant Contact apparently got Yahoo to give them a signing key,
at least temporarily, but that doesn't scale.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 12:15:46 -0800

> at least temporarily, but that doesn't scale.

What gmail does for gsuite is generates (or not, who knows) a key and 
gives you the selector to add to your dns. I don't see why that doesn't 
scale for all situations.

Mike

---

From: Douglas Foster <[email-masked]>
Date: Tue, 29 Dec 2020 15:47:18 -0500

My review of messages from Constant Contact and other major E.S.P.s is that
they do obtain and use a DKIM selector when the domain has dmarc
enforcement.

Earlier in this discussion I was assured that conditionally applying the
right signature was not a significant burden for them.

Scaling does not seem to be a problem yet.

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2020 15:59:22 -0500

>scale for all situations.

To point out the obvious, because they use a single address at
yahoo.com or gmail.com or hotmail.com, not a private domain. These are
tiny organizations that don't have a lot of computer expertise nor a
lot of need for it.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 13:05:30 -0800

> tiny organizations that don't have a lot of computer expertise nor a

Um, so? The have to procure a domain too which can be technically 
challenging. If they want to use outsourced email, the outsourced email 
provider should provide the support to get their selector into their 
DNS.  If they can't bother, I don't care if their email isn't delivered.

Mike

---

From: "Jim Fenton" <[email-masked]>
Date: Wed, 30 Dec 2020 15:22:49 -0800

> tiny organizations that don't have a lot of computer expertise nor a

But these Girl Scout troops are going to publish a DMARC policy despite 
their lack of expertise?

---

From: Laura Atkins <[email-masked]>
Date: Thu, 31 Dec 2020 10:15:07 +0000

> On 30 Dec 2020, at 23:22, Jim Fenton <[email-masked]> wrote:
> 
> But these Girl Scout troops are going to publish a DMARC policy despite their lack of expertise?

Many Girl Scout troops were affected when Yahoo published p=reject. Which is probably why John brought it up. This isn’t a hypothetical, this is things that we know actually happened and real world effects of DMARC. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 31 Dec 2020 15:10:47 +0100

On Thu 31/Dec/2020 11:15:07 +0100 Laura Atkins wrote:
>> On 30 Dec 2020, at 23:22, Jim Fenton <[email-masked] wrote:
>>> In article <[email-masked] you write:
>>> To point out the obvious, because they use a single address at yahoo.com
>>> or gmail.com or hotmail.com, not a private domain. These are tiny
>>> organizations that don't have a lot of computer expertise nor a lot of
>>> need for it. >>
> Many Girl Scout troops were affected when Yahoo published p=reject. Which is 
> probably why John brought it up. This isn’t a hypothetical, this is things that 
> we know actually happened and real world effects of DMARC.

I'd guess the problem they experienced have been mailing list and submissions 
using ISP's bundled services or similar unauthorized MSAs.  The former is fixed 
by From: rewriting, the latter has no possible fix.

Are there other unwanted effects?

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 31 Dec 2020 11:00:29 -0500

>by From: rewriting, the latter has no possible fix.

Not a good guess.  Please review previous messages in this thread for clues.

>Are there other unwanted effects?

The main effect is that the mail they'd been sending from their ESP
with their Yahoo address on the From: line used to work, and now falls
on the floor or worse.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 31 Dec 2020 18:26:24 +0100

> to be stroked and replaced with a reference to aggregate reporting.

I removed duplicated text and adjusted references.  Diffs available here:

https://tools.ietf.org/rfcdiff?url1=draft-ietf-dmarc-failure-reporting-00&url2=https://raw.githubusercontent.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/main/draft-ietf-dmarc-failure-reporting.txt

If the WG agrees, I'd post that as -01 and close ticket #55.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 31 Dec 2020 12:27:26 -0500

Before we do that I think we should revisit whether we have one reporting 
draft or two.

On Thu, 31 Dec 2020, Alessandro Vesely wrote:

>> paragraphs of Section 3, the whole discussion about external destinations 
>> has to be stroked and replaced with a reference to aggregate reporting.
>
>

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 31 Dec 2020 18:35:10 +0100

> Not a good guess.  Please review previous messages in this thread for clues.

Ah, yeah, the ESPs.  Besides dmarc=fail, they also trigger some SA macros, such 
as FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, 
FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS, HTML_IMAGE_RATIO_04, 
HTML_MESSAGE, ...

> with their Yahoo address on the From: line used to work, and now falls

Why can't the ESPs do From: rewriting?

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 31 Dec 2020 18:41:17 +0100

On Thu 31/Dec/2020 18:27:26 +0100 John R Levine wrote:
> Before we do that I think we should revisit whether we have one reporting draft 
> or two.

That issue only touches ticket #55 because it's the only one which called for 
altering the I-D's text.  Also having a -01 beside -00 is irrelevant to the 
question.

Discussing the split deserves its own ticket, IMHO.

Best
Ale

---

From: "John R Levine" <[email-masked]>
Date: 31 Dec 2020 12:51:10 -0500

> Why can't the ESPs do From: rewriting?

To what?  The Yahoo address is the only address the scout troop has?

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 31 Dec 2020 19:06:35 +0100

> To what?  The Yahoo address is the only address the scout troop has?

Copy that to Reply-To: and write a mangled From: that looks troopy but passes 
DMARC.  Just like MLMs do.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 31 Dec 2020 13:22:50 -0500

> DMARC.  Just like MLMs do.

Lists at MLMs have names that the subscribers will recognize, but the 
scout troop only has the Yahoo address.

There are certainly kludges that one can apply to circumvent DMARC 
rejections, but this is a clear failure, an existing legitimate mail use 
that DMARC breaks.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 31 Dec 2020 10:36:15 -0800

On 12/31/20 10:22 AM, John R Levine wrote:
>> Copy that to Reply-To: and write a mangled From: that looks troopy 
>> but passes DMARC.  Just like MLMs do.
>
> rejections, but this is a clear failure, an existing legitimate mail 
> use that DMARC breaks.
>
>
The entire problem with catering to the long tail is that it is holding 
hostage better email security. We should stop doing that. There is no 
right to stasis forevermore. If the scouts email breaks, they can get 
somebody to fix it. They will thank us in the long run when scammers 
can't phish using them as a prop.

Mike