Subject: Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 1 Jun 2019 01:13:18 -0700

On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov <[email-masked]>
wrote:

> Shall I submit an erratum to RFC7489?
>

I would, yes.  And this should certainly be recorded as something we need
to fix for standards track DMARC, whether by chasing down RFC7489 errata or
via a dedicated issue in this WG's tracker.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 1 Jun 2019 10:18:28 +0200

On 6/1/2019 10:13 AM, Murray S. Kucherawy wrote:
> On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I would, yes.  And this should certainly be recorded as something we 
> need to fix for standards track DMARC, whether by chasing down RFC7489 
> errata or via a dedicated issue in this WG's tracker.

Hmmm...

The formal rule for errata in the RFC system is rather constrained: 
Only errors that mis-specify what was intended are permitted.

So, errors in thinking or failures to provide for cases don't count as 
errata.

What this means is that there is no standard way to record the need for 
better-performing capabilities or addition of new capabilities or the like.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 1 Jun 2019 10:00:59 +0100

Hi Dave,

> On 1 Jun 2019, at 09:18, Dave Crocker <[email-masked]> wrote:
> 
>> On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov <[email-masked] <mailto:[email-masked]>> wrote:
>> I would, yes.  And this should certainly be recorded as something we need to fix for standards track DMARC, whether by chasing down RFC7489 errata or via a dedicated issue in this WG's tracker.
> 
> Hmmm...
> 
> The formal rule for errata in the RFC system is rather constrained: Only errors that mis-specify what was intended are permitted.
> 
> So, errors in thinking or failures to provide for cases don't count as errata.

You are right, but I can always mark this issue as “hold for update”, so that it can be tracked for the -bis document.

Best Regards,
Alexey
> 
> What this means is that there is no standard way to record the need for better-performing capabilities or addition of new capabilities or the like.
> 
> d/
> 
> 
> -- 
> Dave Crocker
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 1 Jun 2019 08:38:32 -0700

On Sat, Jun 1, 2019 at 2:01 AM Alexey Melnikov <[email-masked]>
wrote:

> >> On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov <
> [email-masked] <mailto:[email-masked]>> wrote:
> > The formal rule for errata in the RFC system is rather constrained: Only
> errors that mis-specify what was intended are permitted.
> >
> You are right, but I can always mark this issue as “hold for update”, so
> that it can be tracked for the -bis document.
>

My understanding matched Dave's originally, but then I found this:
https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/

It's not surprising this sort of need to record a deficiency for later
handling has come up before, and we've adapted a way to deal with it.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 1 Jun 2019 19:49:56 +0200

> https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/

Interesting.  I've never seen that before.  I suspect few others have.

I was educated on the model I described by having a design change -- I 
don't remember whether it fixed a design error or added an enhancement 
-- refused for the errata record and I was told errata were only for 
documentation errors -- that is for cases in which the document did not 
adequately described "what was intended".  So, anything that alters what 
was intended by the wg and/or authors was declared out of scope.

While this was some years ago, I'm quite sure it was long after the date 
of the IESG document.

FWIW, it strikes me as a little crazy to have errata admittance rules be 
different for different streams.  What is the possible benefit that is 
major enough to warrant the additional complexity?  But that's just me.

Taking the current case, while it's nice that Alexey is friendly to 
adding this item as a hold, I'll suggest that the decision should rest 
with the troops already tasked with assessing the submission.  There 
doesn't seem to be a good reason to require an AD to make that decision.

d/

---

From: Hector Santos <[email-masked]>
Date: Sat, 01 Jun 2019 16:00:50 -0400

> handling has come up before, and we've adapted a way to deal with it.

Interesting.  How does this change based on the document status? 
Would you care if its informational?  Normally, you would not? But 
DMARC has broke the mold.

We seek an IETF standardization of a DKIM Policy system. We need to 
finish this work.   Right now, the DMARC method has the attention. 
There is going to be lots of work here and unless the 3rd party 
question is addressed, I expect the same ADSP scrutiny for DMARC.

I agree any suggestions for Informational Status document change 
should be held for the PS work.

-- 
HLS

---

From: Tim Draegen <[email-masked]>
Date: Tue, 4 Jun 2019 03:47:16 -0400

> On Jun 1, 2019, at 4:13 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 

I did not see this item submitted as errata, so I put it into the tracker:

  https://trac.ietf.org/trac/dmarc/ticket/30

I'd like to float the idea that this scenario might be something operators address when they're generating reports (perhaps mentioned in DMARC Usage Guide?). 

That said, the NOTIFY=NEVER idea makes a lot of sense to me, but I have to admit I'm not exactly sure how easy it is for operators to set this. If its not super obvious and available everywhere for free, I have to assume this means it'll be partially deployed forever, which puts us back at square one.

Sending with an empty RFC5321.MAILFROM sort of turns DMARC reports into a form of DSN. Implications unknown!

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 4 Jun 2019 17:01:36 +0200

Hi Tim,

On Tue 04/Jun/2019 09:47:16 +0200 Tim Draegen wrote:
>> On Jun 1, 2019, at 4:13 AM, Murray S. Kucherawy 
>> I would, yes.  And this should certainly be recorded as something we need to
>> fix for standards track DMARC, whether by chasing down RFC7489 errata or via
>> a dedicated issue in this WG's tracker.
> 
> I'd like to float the idea that this scenario might be something operators
> address when they're generating reports (perhaps mentioned in DMARC Usage Guide?). 

That's a good idea.

> That said, the NOTIFY=NEVER idea makes a lot of sense to me, but I have to
> admit I'm not exactly sure how easy it is for operators to set this. If its not
> super obvious and available everywhere for free, I have to assume this means
> it'll be partially deployed forever, which puts us back at square one.
> 

Not quite.  The ticket is wrong in mentioning bounces, because they don't
trigger an aggregate report.  Aggregate reports cover _any_ message that is
received with a From: domain having a DMARC record and a rua address.  That
obviously includes any aggregate reports that is received from the relevant
address.

The best solution I saw is not to send aggregate reports from a domain that has
a DMARC record with a rua address:
http://lists.dmarc.org/pipermail/dmarc-discuss/2018-October/004164.html

When I read that, I changed the From: header field of my generator, but I'm not
sure I did fix anything.  Once triggered, that kind of loop would last forever,
with <count>1</count> every day from both sides acknowledging each other's
report.  I looked for such a loop and found none, perhaps because every other
domain had already applied the trick?

Best
Ale
--