Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 Feb 2012 11:47:46 +0100

On 31/Jan/12 21:00, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>> BTW, why isn't the rs= string actionable even in the absence of ra=?
> 
> Good point; fixed.

Nice, thanks for this --and for the other fixes as well.  Does this
change have to be addressed also in the last step of the reporting
algorithm?  See below...

>> 3.3. *DKIM Reporting Algorithm*
>> 
>> The last paragraph of this section is rather convoluted.  In order to
>> simplify it, I would modify the first step of the algorithm

> I think that falls under "semantically equivalent", so I'd prefer
> not to change it.

Steps 2-9 are quite precisely stated, so I'm not sure how obvious it
is what amount of latitude is left to programmers' common sense.  An
alternative is to use regular text phrases to discuss the SHOULDs and
MAYs of generating a report, as well as the relative independence
between that and honoring rs=.  The algorithm proper would then
specify what to do after those decisions are made.  (Hey, numbering
paragraphs /is/ meaningful in this case.)

>> 8.5. *Automatic Generation*
>> 
>> The last paragraph, about out-of-band arrangements, seems to defy this
>> I-D's very purpose of automating reporting.  Considering what marf-as
>> is going to say on unsolicited reports, I'd s/create/persist sending/.
> 
> What this section is trying to say is that people should not
> implement systems that do this kind of reporting work by default.

Yes.  In this sense, that paragraph is rowing in the opposite
direction than the rest of the I-D.  (I understand "reporting of
message authentication failures in an on-demand fashion" as
I-set-record=you-send-report.)

> It can create a ton of traffic due to simple infrastructure
> problems at the signer/sender, for example.  The obvious
> mitigation, rate limiting the generation of reports, isn't an ideal
> solution for various reasons.

Agreed.

> I don't think this harms what -as is saying about unsolicited
> reports.

Not at all.  However, marf-as says
                                        Where an unsolicited report
     results in the establishment of contact with a responsible and
     responsive party, this can be saved for future complaint
     handling and possible establishment of a formal (solicited)
     feedback arrangement.

That is, it provides for transitioning to an out-of-band agreement, if
interpreted in this I-D's context.

> This document discusses a specific kind of feedback and thus this
> is not a statement about ARF in general.

It is, since the paragraph talks about "these (or any) ARF reports".
And it is good to do so, IMHO.  This I-D is not specifying
blind-to-witting transitions, and I'm not suggesting it should, but
maybe it can still suggest some details of such activity.

>> 8.6. *Reporting Multiple Incidents*
>> 
>> To suspend report generation for some time after an RCPT rejection of
>> the reporting address might also provide for a safe approach.
> 
> Since it's Security Considerations, none of this is normative.
> It's just a suggestion for handling large volumes of reports.

Yes, such specification should belong to some other I-D
(reporting-discovery? :-)

> Your two are equally viable, so it would be fine to add them as
> well, especially since the latter one talks about a way to do rate 
> limiting at the report receiver rather than relying on the report 
> generator to do it all.  So I'll add this:
> 
>    <t> Other rate limiting provisions might be considered,
>        including detection of a temporary failure
>        response from the report destination and thus
>        halting report generation to that destination
>        for some period, or simply imposing or negotiating
>        a hard limit on the number of reports to be sent
>        to a particular receiver in a given time
>        frame. </t>

While that may be semantically correct, there is the practical problem
that 4xx reply codes are not reported timely.  It is necessary to
query the mail queue in order to know whether there are outstanding
temporary failures.  In case the boundary box where the report
generator lives does not send mail out directly, it is not practical
to determine that condition.

On the other hand, 5xx reply codes should cause the current message to
be discarded.  On resuming reporting, new reports are transmitted,
rather than the queued flood initiators.  However, in order to ensure
immediate notification of rejections in all cases, one would have to
use purposely configured variable envelope senders.

What do you think?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Feb 2012 10:41:10 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Wednesday, February 01, 2012 2:48 AM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07
> 

The last step already does talk about including the "rs=" string, if there was one.  What does need correction though is step 8 which presumes "ra=" is there.  I'll tidy that up.

> Steps 2-9 are quite precisely stated, so I'm not sure how obvious it is
> what amount of latitude is left to programmers' common sense.  An
> between that and honoring rs=.  The algorithm proper would then specify
> what to do after those decisions are made.  (Hey, numbering paragraphs
> /is/ meaningful in this case.)

We've used the "semantically equivalent" language in a few places without complaint, most notably ADSP and I think DKIM as well.  I think adding specific implementation detail about possible alternate implementations will just clutter the matter rather than improving it, so I'd prefer to leave it alone.

> >> The last paragraph, about out-of-band arrangements, seems to defy
> >> this I-D's very purpose of automating reporting.  Considering what
> >> marf-as is going to say on unsolicited reports, I'd s/create/persist sending/.
> >
> > What this section is trying to say is that people should not implement
> > systems that do this kind of reporting work by default.
> 
> Yes.  In this sense, that paragraph is rowing in the opposite direction
> than the rest of the I-D.  (I understand "reporting of message
> authentication failures in an on-demand fashion" as

I don't agree.  The I-D is meant to present the mechanisms for requesting and providing these reports.  That is, "If you're going to do this, here's how we think you should go about it."  There are some obvious concerns with doing so across-the-board without any checking or thought to it, though one certainly could do that.  It seems very appropriate to me to call that out in Security Considerations.

> And it is good to do so, IMHO.  This I-D is not specifying blind-to-
> witting transitions, and I'm not suggesting it should, but maybe it can
> still suggest some details of such activity.

I think to do so we would wander into the realm of speculation, not specification.  I don't think that's a good idea for something that's asking for Proposed Standard status as a protocol document.  Perhaps it could as an applicability statement, but that's not what we're doing here.

> Yes, such specification should belong to some other I-D (reporting-
> discovery? :-)

If we're going to talk about handling of large report volumes, given our current document set, the AS is the right place to do it.  If you think that's important, now's the time to make such a proposal, before WGLC closes.

> that 4xx reply codes are not reported timely.  It is necessary to query
> the mail queue in order to know whether there are outstanding temporary
> failures.  In case the boundary box where the report generator lives
> does not send mail out directly, it is not practical to determine that
> condition.
> 

I think if the advice that's been added about observing the behavior of the report recipient as input to a throttling mechanism is actually impractical, we should remove it rather than expanding on it and complicating the document further.  We risk confusing the reader.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 Feb 2012 13:16:15 +0100

On 01/Feb/12 19:41, Murray S. Kucherawy wrote:
>> (I understand "reporting of message authentication failures in an
>> on-demand fashion" as I-set-record=you-send-report.)
> 
> I don't agree.  The I-D is meant to present the mechanisms for
> requesting and providing these reports.  That is, "If you're going
> to do this, here's how we think you should go about it."  There are
> some obvious concerns with doing so across-the-board without any
> checking or thought to it, though one certainly could do that.

What's that "could"?!  There's nothing I can conceivably do besides
setting the RR properly.  If that is not enough for getting reports
from whoever will happen to get a broken signature, then this I-D is
completely useless --I can well receive occasional failure notices
from friends based on authfailure-report only.

Differently from abuse reports, authentication failures may affect
personal messages and confidential content.  Concern over divulging
that is due.  If I were to report to unknown people, I would probably
want to redact most header fields and omit the body.

> It seems very appropriate to me to call that out in Security 
> Considerations.

Yes.

>> This I-D is not specifying blind-to- witting transitions, and I'm
>> not suggesting it should, but maybe it can still suggest some
>> details of such activity.
> 
> I think to do so we would wander into the realm of speculation, not
> specification.

Let me describe a possible case, just to make sure we're talking about
the same thing:

Alice writes to Bob, DKIM-Signature breaks, ISP-B (Bob's ISP) start
reporting to ISP-A.  ISP-A receive the first reports, check that they
are good and confirm, possibly on
http://postmaster.ISP-B.example/acknowledge?key=ISP-A_beenhere, that
they would like to continue receiving them.  That doesn't lower the
amount of redaction applied to reports.  Yet, ISP-A can collect
reports and form a statistic picture of how their configuration goes.
 Useful work already, isn't it?

After some months, ISP-A write to ISP-B to arrange for a debugging
session:

   Hi ISP-B,

    I have some statistical evidence that messages from our user Alice
   to your user Bob tend to break much more often than normal.  Would
   it be possible to check that more closely?  Alice says she can
   resend the messages listed below (see attachment).  Bob agrees, but
   please check his consent for your records.

   Regards
    ISP-A
   ---
   (attachment omitted)

ISP-B answer affirmatively and manually forward unredacted reports of
the relevant failures to ISP-A.  ISP-A find the bug and they lived
happily ever after.

> I don't think that's a good idea for something that's asking for
> Proposed Standard status as a protocol document.

The idea is just to note that there are data items about ISP-A, such
as acknowledgment, contacts, responsiveness, and involvement, that is
worth being stored on a per-domain database.  We don't need to say
that such data may turn out to be useful for looking into spam
(reporting) issues, as that is indeed speculation.

>>>> the reporting address
> If we're going to talk about handling of large report volumes,
> given our current document set, the AS is the right place to do it.
> If you think that's important, now's the time to make such a
> proposal, before WGLC closes.

Both dkim-reporting and spf-reporting have a section on "Envelope
Sender Selection".  Reporting-discovery would need one too.  The
question of flow control (see below) is a related problem, also common
to all those specs.  I agree it is good to factor them.

Are you saying the AS is the right place for both flow control and
loop avoidance?

What do everybody else think?

>> While [temporary failure] may be semantically correct, there is
>> the practical problem that 4xx reply codes are not reported
>> timely.  It is necessary to query the mail queue in order to know
>> whether there are outstanding temporary failures.  In case the
>> boundary box where the report generator lives does not send mail
>> out directly, it is not practical to determine that condition.
>> 
>> On the other hand, 5xx reply codes should cause the current
>> message to be discarded.  On resuming reporting, new reports are
>> transmitted, rather than the queued flood initiators.  However,
>> in order to ensure immediate notification of rejections in all
>> cases, one would have to use purposely configured variable
>> envelope senders.
>> 
>> What do you think?
> 
> I think if the advice that's been added about observing the
> behavior of the report recipient as input to a throttling mechanism
> is actually impractical, we should remove it rather than expanding
> on it and complicating the document further.  We risk confusing the
> reader.

Hm...  I don't think that a non-empty envelope sender may cause
reporting loops, as reporting does not actually use it.  Hence, we
could use it for flow control.

For some unsorted details, we may recommend 552 after RCPT for
momentarily stop reporting, but had better not rely on it.  Rather, I
propose we encourage getting acknowledgments and recording them along
with per-domain reporting history.  Report generators should use VERP,
and suspend reporting to rejecting domains for an amount of time
inversely proportional to the confidence, e.g.:

  0.5T      for an acknowledged domain,
  T         for a first-time first-failure,
  2T,
  4T,
  ... ,
  one year  for dorks.

where T is the TTL of the relevant _report's RR if retrieved with the
AA flag, or some other time constant either agreed with the domain or
set by default.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Feb 2012 10:16:15 -0800

> Sent: Thursday, February 02, 2012 4:16 AM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was-07
> 
> > requesting and providing these reports.  That is, "If you're going to
> > do this, here's how we think you should go about it."  There are some
> > obvious concerns with doing so across-the-board without any checking
> > or thought to it, though one certainly could do that.
> 
> completely useless --I can well receive occasional failure notices from
> friends based on authfailure-report only.

I think we're talking past each other here.  What this draft presents is a method that amounts to a two-way handshake between someone that wants reports about DKIM failures and someone willing to generate them.  You need to consider both sides of that equation.  For report generators in particular, simply turning this on without giving any thought to the potential for creating a mail storm is possibly a bad idea, which means we should provide appropriate cautions.  For senders/signers, you need to be aware that requesting reports might mean you get (legitimately) mailbombed.  That's what Sections 8.5 and 8.6 try to point out.

> want to redact most header fields and omit the body.

But that's a risk in any ARF context, isn't it?  I don't see why it's necessary to call it out here (or, presumably, in spf-reporting).  It's called out appropriately in the authfailure-report draft (Section 3.1 at least), which this one normatively references.

> >> This I-D is not specifying blind-to- witting transitions, and I'm not
> >> suggesting it should, but maybe it can still suggest some details of
> >> such activity.
> >
> are good and confirm, possibly on http://postmaster.ISP-
> B.example/acknowledge?key=ISP-A_beenhere, that they would like to
> continue receiving them.  That doesn't lower the amount of redaction
> applied to reports.  Yet, ISP-A can collect reports and form a
> statistic picture of how their configuration goes.

Sure, but I think if you take the DKIM-specific aspect out, you're talking about a generic feedback loop scenario.  And that means it's more appropriate for the applicability statement draft.

> The idea is just to note that there are data items about ISP-A, such as
> acknowledgment, contacts, responsiveness, and involvement, that is
> worth being stored on a per-domain database.  We don't need to say that
> such data may turn out to be useful for looking into spam

But that isn't specific to DKIM reporting, so I don't think that belongs here.

> Are you saying the AS is the right place for both flow control and loop
> avoidance?

Yes.  That draft is now in WGLC, so if you want to make a pitch to add text to that document, now's the time.

> What do everybody else think?

That's a fine question.  I suggest summarizing the proposed change in another thread.

> > I think if the advice that's been added about observing the behavior
> > of the report recipient as input to a throttling mechanism is actually
> > impractical, we should remove it rather than expanding on it and
> > complicating the document further.  We risk confusing the reader.
> 

Actually anything that isn't the empty envelope sender could cause a forwarding loop, modulo normative guidance to the contrary.  Section 6 covers this.

> AA flag, or some other time constant either agreed with the domain or

And you think this would improve Section 8.6 rather than complicating it?  Personally, I'm satisfied that the last paragraph of what we have in that section is adequate to introduce the idea.  Developing and recommending a detailed tracking system design seems like overkill here.  If someone wants to do such a thing, it would certainly be valid, but I think suggesting that such a thing might be necessary could become a barrier to adoption.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 03 Feb 2012 10:43:08 +0100

On 02/Feb/12 19:16, Murray S. Kucherawy wrote:
>>> The I-D is meant to present the mechanisms for requesting and
>>> providing these reports.  That is, "If you're going to do this,
>>> here's how we think you should go about it."  There are some 
>>> obvious concerns with doing so across-the-board without any
> I think we're talking past each other here.  What this draft
> presents is a method that amounts to a two-way handshake between
> someone that wants reports about DKIM failures and someone willing
> to generate them.  You need to consider both sides of that
> equation.  For report generators in particular, simply turning this
> on without giving any thought to the potential for creating a mail
> storm is possibly a bad idea, which means we should provide
> appropriate cautions.  For senders/signers, you need to be aware
> that requesting reports might mean you get (legitimately)
> mailbombed.  That's what Sections 8.5 and 8.6 try to point out.

I don't think we are at cross purposes, as we have more matching than
contrasting points.  Yet, at times we are unable to understand each
other --possibly my English doesn't help much.

Define "giving any thought".  Auto or manual?

Section 8.5 is about out-of-band arrangements.  The only sense I'm
able to make of it is that the signer has already set up an FBL with
the report generating domain.  If that's correct, it has to be said
more clearly.  BTW, the last phrase:

   data found in the DKIM signatures, which could have been
   fraudulently inserted.

is obsolete now that the data is checked in the DNS.

Section 8.6 is about run-time control of traffic.  We may solve the
problem or just mention it.  Let's see if anyone else is interested.
In any case, the mailbombing is limited by a max in/out ratio of 3 (if
one fails SPF and DKIM and gets a spam report for each message) so it
should be fine for sites like mine where that ratio is usually around
10~20.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Feb 2012 13:58:11 -0800

> Sent: Friday, February 03, 2012 1:43 AM
> To: [email-masked]
> > I think we're talking past each other here.  What this draft presents
> > is a method that amounts to a two-way handshake between someone that
> > wants reports about DKIM failures and someone willing to generate
> > them.  You need to consider both sides of that equation.  For report
> > generators in particular, simply turning this on without giving any
> > thought to the potential for creating a mail storm is possibly a bad
> > idea, which means we should provide appropriate cautions.  For
> > senders/signers, you need to be aware that requesting reports might
> > mean you get (legitimately) mailbombed.  That's what Sections 8.5 and
> > 8.6 try to point out.
> 

I'll define "without giving any thought" as "install, enable, walk away."

> Section 8.5 is about out-of-band arrangements.

Quite the opposite; Section 8.5 is about generating reports to anyone that asks for them, rather than sending them to sites that have specifically asked for them.  I can improve the language to reflect this.

The point is that report generators could be installed to send reports whenever they are requested.  For a large email campaign whose signatures all break, this could cause the sender to become inundated with reports.  It could also cause the report generator to be overwhelmed generating reports.  Both parties need to be aware of this.

> BTW, the last phrase:

Removed.

So here's the pending 8.5:

8.5.  Automatic Generation

   The mechanisms described in this memo are primarily intended for use
   in generating reports to aid implementers of [DKIM] and [ADSP] and
   other related protocols in development and debugging.  They are not
   intended for prolonged forensic use.  However, such uses are possible
   by ADMDs that want to keep a close watch for fraud or infrastructure
   problems.

   A sender requesting these reports can cause its mail servers to be
   overwhelmed if it sends out signed messages whose signatures fail to
   verify for some reason, provoking a large number of reports from
   report generators.  Similarly, a report generator could be
   overwhelmed by a large volume of messages requesting reports whose
   signatures fail to validate, as those now need to send reports back
   to the signer.

   Limiting the rate of generation of these messages may be appropriate
   but threatens to inhibit the distribution of important and possibly
   time-sensitive information.

   In general ARF feedback loop terms, it is often suggested that report
   generators only create these (or any) ARF reports after an out-of-
   band arrangement has been made between two parties.  This mechanism
   then becomes a way to adjust parameters of an authorized abuse report
   feedback loop that is configured and activated by private agreement
   rather than starting to send them automatically based solely on data
   found in the DKIM signatures, which may have unintended consequences.

> problem or just mention it.  Let's see if anyone else is interested.

I think I like the idea of common-factoring this into the AS, but I'm watching for others to reply.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 03 Feb 2012 17:05:02 -0500

>    by ADMDs that want to keep a close watch for fraud or infrastructure

I probably missed a discussion about this sometime, but why isn't this 
intended for prolonged forensic use?  The applications of ARF I've seen that's 
exactly what they are for.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Feb 2012 20:51:36 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Friday, February 03, 2012 2:05 PM
> To: [email-masked]
> intended for prolonged forensic use?  The applications of ARF I've seen
> that's exactly what they are for.

The difference to me is that conventional ARF (e.g., spam reports) are almost always provoked by some human action, like clicking a Report Spam button in a mail reader.  These, by contrast, will almost always be automatically generated.  Perhaps we should say that, rather than what's there now.

I think the current language is also drawn from implementation experience.  It's akin, I suppose, to running a binary in production that has full debugging symbols included to enable detailed debugging versus a stripped binary that is leaner but harder to debug.  Indeed, running a report generator with all of this turned on can obviously cause drag on a mail system when large and/or constant volumes of these reports are being sent in addition to regular mail.

So how about this to replace the above paragraph:

ARF reports have historically been generated individually as a result of some kind of human request, such as someone clicking a "Report Abuse" button in a mail reader.  In contrast, the mechanisms described in this memo are focused around automated reporting.  This obviously implies the potential for much larger volumes or frequency of messages, and thus greater mail system load (both for report generators and report receivers).
	
These mechanisms are primarily intended for use in generating reports to aid implementers of [DKIM] and [ADSP] and other related protocols in development and debugging.  They are not intended for prolonged forensic use, specifically because of these load concerns.  However, extended use is possible by ADMDs that want to keep a close watch for fraud or infrastructure problems.  It is important to consider the impact of doing so on both report generators and the requesting ADMDs.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 Feb 2012 00:29:03 -0500

On Saturday, February 04, 2012 08:51:36 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Scott Kitterman Sent: Friday, February 03, 2012 2:05 PM
> > To: [email-masked]
> > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was
> > -07> 
> > >    intended for prolonged forensic use.  However, such uses are
> > >    possible by ADMDs that want to keep a close watch for fraud
> > >    or infrastructure problems.
> > 
> The difference to me is that conventional ARF (e.g., spam reports) are
> almost always provoked by some human action, like clicking a Report Spam
> button in a mail reader.  These, by contrast, will almost always be
> automatically generated.  Perhaps we should say that, rather than what's
> there now.
> 
> I think the current language is also drawn from implementation experience. 
> It's akin, I suppose, to running a binary in production that has full
> debugging symbols included to enable detailed debugging versus a stripped
> binary that is leaner but harder to debug.  Indeed, running a report
> generator with all of this turned on can obviously cause drag on a mail
> system when large and/or constant volumes of these reports are being sent
> in addition to regular mail.
> 
> ARF reports have historically been generated individually as a result of
> some kind of human request, such as someone clicking a "Report Abuse"
> button in a mail reader.  In contrast, the mechanisms described in this
> memo are focused around automated reporting.  This obviously implies the
> potential for much larger volumes or frequency of messages, and thus
> greater mail system load (both for report generators and report receivers).
> 
> These mechanisms are primarily intended for use in generating reports to aid
> implementers of [DKIM] and [ADSP] and other related protocols in
> development and debugging.  They are not intended for prolonged forensic
> use, specifically because of these load concerns.  However, extended use is
> possible by ADMDs that want to keep a close watch for fraud or
> infrastructure problems.  It is important to consider the impact of doing
> so on both report generators and the requesting ADMDs.

"not intended for prolonged"/"not generally intended for prolonged" and I 
think I'm happy.  

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Feb 2012 22:09:55 -0800

> Sent: Saturday, February 04, 2012 9:29 PM
> To: [email-masked]
> "not intended for prolonged"/"not generally intended for prolonged" and
> I think I'm happy.

Sold.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 05 Feb 2012 12:42:58 +0100

On 05/Feb/12 07:09, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Scott Kitterman
>

Hm... I'm neutral on that.  Actually, I'd like a report generator to
be useful for both full-detail verbose debugging and lightweight
advisory statistics.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 Feb 2012 10:21:52 -0500

>be useful for both full-detail verbose debugging and lightweight

I think the wording allows for that.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 06 Feb 2012 11:21:14 +0100

On 02/Feb/12 19:16, Murray S. Kucherawy wrote:
>> I propose we encourage getting acknowledgments and recording them
>> along with per-domain reporting history.  Report generators
>> should use VERP, and suspend reporting to rejecting domains for
>> an amount of time inversely proportional to the confidence,
>> e.g.:
>> 
> And you think this would improve [Section 11.5 of marf-as-06] rather
> than complicating it?  Personally, I'm satisfied that the last
> paragraph of what we have in that section is adequate to introduce
> the idea. Developing and recommending a detailed tracking system
> design seems like overkill here.  If someone wants to do such a
> thing, it would certainly be valid, but I think suggesting that
> such a thing might be necessary could become a barrier to
> adoption.

VERP should be quite straightforward to implement, given that it's
been around for decades.

What to do on delivery failures is part of using VERP, of course.
Per-domain DBs may look more like greylisting whitelists than
subscriber lists.  They are needed anyway to implement paragraph 6 of
Section 8 ("MUST provide a way for a report recipient to request no
further reports be sent to that address") unless that gets limited to
heuristically inferred addresses.

Ideas?