Subject: Re: [marf] I-D Action: draft-ietf-marf-as-12.txt

From: Pete Resnick <[email-masked]>
Date: Tue, 3 Apr 2012 13:08:06 -0500

On 3/30/12 4:49 AM, Murray S. Kucherawy wrote:

> Addresses AD feedback about use of normative language.
>    

Finally back in the land of the living...

I did a thorough review and I still have a bunch of concerns. As always, 
you can tell me I'm full of crap, but some of these are places where I 
find the text incomprehensible, and I suspect other ADs will have 
similar problems. Please have a look:

4.3.1.
       The reports SHOULD use "Feedback-Type: abuse", but can use other
        types as appropriate to the nature of the abuse being reported.
        However, the Mailbox Provider generating the reports needs to
        understand that the operator receiving the reports might not
        treat different feedback types any differently.

How about instead: "The reports SHOULD use "Feedback-Type: abuse" for 
its type. Although a Mailbox Provider generating the reports can use 
other types appropriate to the nature of the abuse being reported, the 
operator receiving the reports might not treat different feedback types 
differently." The "needs to understand" construction confused me as it 
didn't seem like something actionable.

5.1.1.
        At the time this document is being written, for the use cases
        described here, mail operators need to proactively request a
        stream of ARF reports from Mailbox Providers.  Recommendations
        for preparing to make that request are discussed in Section 4.1
        of [RFC6449].

Strike "At the time this document is being written, for the use cases 
described here". It seems utterly obvious. If you write a new document 
with new use cases, you can change the instruction. Also, why "need to" 
instead of "MUST"?

    2.  Furthermore, this document assumes that mail operators exchange
        abuse reports formatted per ARF [RFC5965] as email messages
        [RFC5322] over SMTP [RFC5321].  These and other types of email
        messages that can be received are discussed in Section 4.2 of
        [RFC6449].

Ugh. I preferred your earlier attempt on the list or Barry's wording 
much better. I don't really care what the "document assumes". I say go 
with "Operators MUST be able to accept...".

    3.  Mail operators need to consider the idea of automating report
        processing.  Discussion of this can be found in Section 4.4 of
        [RFC6449].

I don't really understand what that means and I don't see how it is 
actionable. What do you want mail operators to do?

5.2.1.
        An automated report processing system MUST accept all Feedback-
        Types defined in [RFC5965] or extensions to it.  However, report
        receivers cannot assume that Mailbox Providers will make use of
        any Feedback-Type other than "abuse", except with prior specific
        knowledge.  Additional analysis might be required to separate
        different types of abuse reports after receipt.

The first sentence is fine. After that, I suggest, "However, Mailbox 
Providers may only make use of the "abuse" Feedback-Type. Therefore 
report receivers might be required to do additional analysis to separate 
different types of abuse reports after receipt if they do not have prior 
specific knowledge of the sender of the report."

    2.  Implementers SHOULD NOT expect all Mailbox Providers to include
        the same optional fields.

How about, "Implementers MUST accept different combinations of optional 
fields since Mailbox Providers might not include the same ones."?

    3.  Reports may have been subjected to redaction of user-identifiable
        data as described in [I-D.IETF-MARF-REDACTION].  That document
        also discusses the handling of such reports.  This technique is
        also discussed in Section 4.4 of [RFC6449].

"Report receivers MUST/SHOULD accept reports that have been subject to 
redaction". Is that what you mean?

5.3.1
        Actions that mail operators might take upon receiving a report
        (or multiple reports) are discussed in Section 4.3 of [RFC6449].

Completely stylistic: "Section 4.3 of [RFC6449] discusses actions..."

6.1.1
        A report generator MUST provide a way for a report recipient to
        request no further reports be sent to that address and MAY
        provide a way for recipients to change the address(es) to which
        reports about them are sent.  Details of such mechanisms are
        outside of the scope of [RFC5965], [RFC6449], and this document.

So, thinking about this, the above instruction is completely 
non-interoperable. I am required to provide a mechanism, but how the 
mechanism works is unspecified. Please explain what this means.

6.2.1
        Handling of unsolicited reports has a significant cost to the
        receiver.  Senders of unsolicited reports, especially those
        sending large volumes of them automatically, need to be aware of
        this and do all they reasonably can to avoid sending reports that
        cannot be used as a basis for action by the recipient, whether
        this is due to the report being sent about an incident that is
        not abuse-related, the report being sent to an email address that
        won't result in action, or the content or format of the report
        being hard for the recipient to read or use.

I don't get why 2119 language is being avoided in the above. Why not 
s/need to be aware of this and do all they reasonably can to avoid 
sending/[MUST/SHOULD] NOT send ?

6.3.1
        MUAs SHOULD NOT generate abuse reports directly to entities
        merely because they were found in the message, or by queries to
        WHOIS ([RFC3912]) or other heuristic means.  Rather, the MUA
        needs to signal, by some means, the mailbox provider to which it
        connects to trigger generation of such a report.

The first sentence seems to conflict with 6.3/3. I don't understand the 
second sentence. Please explain.

6.4.3
        Finally, they need to be
        aware that the report could be discarded or ignored due to
        failure to take these steps in the most extreme cases.

How about, "In extreme cases, failure to do these things may result in 
the report being discarded or ignored."?

7.1
        Selection of the recipient(s) for reports that are automatically
        generated MUST be done based on data provided by the report
        recipient, and MUST NOT be done heuristically.  Therefore these
        reports are always solicited, such as the mechanisms defined in
        the examples listed above.

Stylistic: "Automatic report generators MUST select recipients based on 
data provided by the report recipient. In particular, recipients MUST 
NOT be selected heuristically."

    3.  When sending a new report via SMTP, it is necessary to construct
        the message so as to avoid amplification attacks, deliberate or
        otherwise.  The envelope sender address of the report needs to be
        chosen so that these reports will not generate mail loops.
        Similar to Section 2 of [RFC3464], the envelope sender address of
        the report needs to be chosen to ensure that no feedback reports
        will be issued in response to the report itself.  Therefore, when
        an SMTP transaction is used to send a report, the MAIL FROM
        command SHOULD use the NULL reverse-path, i.e., "MAIL FROM:<>".

Again, it seems that more 2119 language is appropriate here:

        The message for a new report sent via SMTP MUST be constructed
        so as to avoid amplification attacks, deliberate or
        otherwise.  The envelope sender address of the report MUST be
        chosen so that these reports will not generate mail loops.
        Similar to Section 2 of [RFC3464], the envelope sender address of
        the report MUST be chosen to ensure that no feedback reports
        will be issued in response to the report itself.  Therefore, when
        an SMTP transaction is used to send a report, the MAIL FROM
        command SHOULD use the NULL reverse-path, i.e., "MAIL FROM:<>".

I'm not totally clear on why the final "SHOULD" is not a "MUST", but I 
guess I can see that you might form it differently.

And finally, in the stylistic category, each section starts with:

    The following subsections include statements applicable when XYZing

Gads, I hate the passive construction. I don't have a recommendation.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Apr 2012 20:36:01 +0000

Attached is a diff that should satisfy everything Pete just brought up.  Please let me know if there are any objections.  Since most of this is well-baked and I don't believe any of it changes what the WG is actually trying to say (i.e., it's mostly about better choice of language and expression), I'll post a new version in the next couple of days unless there's objection.  Then hopefully we can get this one moving.

-MSK

---

From: Jacob R Rideout <[email-masked]>
Date: Tue, 3 Apr 2012 14:36:12 -0600

> How about instead: "The reports SHOULD use "Feedback-Type: abuse" for its
> type. Although a Mailbox Provider generating the reports can use other types
> appropriate to the nature of the abuse being reported, the operator
> receiving the reports might not treat different feedback types differently."
> The "needs to understand" construction confused me as it didn't seem like
> something actionable.

For the ARF reports we generate, we always use "Feedback-Type: abuse",
but add an Abuse-Type field that describes the origin of the abuse.
Currently this is one of complaint, trap, trap-pristine, or
trap-recycled. Are we suggesting that these types should be used in
place of abuse for Feedback-Type? Section 5.2.1 makes it clear that
the specific meaning of abuse might require additional analysis.

> I don't get why 2119 language is being avoided in the above. Why not s/need
> to be aware of this and do all they reasonably can to avoid

Are generators of unsolicited report also required to respect 6.1.1?
Does this establish some type of opt-out regime?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Apr 2012 20:38:23 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Tuesday, April 03, 2012 1:36 PM
> To: [email-masked]
> Cc: Pete Resnick
> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-12.txt
> 
> Attached is a diff that should satisfy everything Pete just brought up.
> Please let me know if there are any objections.  Since most of this is
> well-baked and I don't believe any of it changes what the WG is
> actually trying to say (i.e., it's mostly about better choice of
> language and expression), I'll post a new version in the next couple of
> days unless there's objection.  Then hopefully we can get this one
> moving.

...and now, with the attachment.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Apr 2012 20:41:16 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jacob R Rideout
> To: Pete Resnick
> Cc: [email-masked]
> Currently this is one of complaint, trap, trap-pristine, or trap-
> recycled. Are we suggesting that these types should be used in place of
> abuse for Feedback-Type? Section 5.2.1 makes it clear that the specific
> meaning of abuse might require additional analysis.

The legal values for Feedback-Type are registered.  Doing what you're suggesting would render your ARF messages non-compliant.  You should leave it how it is, or register your new types (which requires specification).

> Does this establish some type of opt-out regime?

Section 6 talks about unsolicited reports, so yes to both questions.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 04 Apr 2012 18:40:57 +0200

On 03/Apr/12 20:08, Pete Resnick wrote:
> operator receiving the reports might not treat different feedback
> types differently." The "needs to understand" construction confused me
> as it didn't seem like something actionable.

The suggested replacement seems to be saying that it is fine to use
"Feedback-Type: abuse" even if that doesn't correspond to the actual
content.  Would s/its type/such type/ avoid it?

> mechanism works is unspecified. Please explain what this means.

For Pete's info, the WG briefly discussed the possibility to describe
a mechanism, and concluded that mandating such compliance was too much
of a burden for a report generator.

> The first sentence seems to conflict with 6.3/3. I don't understand
> the second sentence. Please explain.

I'd propose the following text, rather than striking the whole paragraph:

   MUAs SHOULD NOT send abuse reports directly to the entities they
   deem responsible of the abuse.  Rather, MUAs need to signal the
   abuse to the mailbox provider to which they connect.  A MUA's
   signal may or may not use ARF [RFC5965] format, depending on how
   it's done.  This document does not specify by what means MUAs do
   such signaling.  The rest of this section discusses where Mailbox
   Providers can send reports, albeit possibly triggered by MUAs'
   signals.

Would that make the point any clearer?

---

From: Pete Resnick <[email-masked]>
Date: Wed, 4 Apr 2012 13:40:18 -0500

> content.  Would s/its type/such type/ avoid it?

That wasn't my understanding of the intent of the original text. The 
original seemed to say that you SHOULD use "abuse" unless you had good 
reason to think doing otherwise was OK, and in fact choosing something 
other than "abuse" might be unproductive since receivers might treat 
everything as if it were "abuse". If you want to say "SHOULD use 'abuse' 
when it's abuse", then I'd like to hear why that's not a MUST.

> of a burden for a report generator.

Yes, Murray and I chatted about this offline, and what he has suggested 
for 6.1.1 explains that well:

    1.  Handling of unsolicited reports has a significant cost to the

> Would that make the point any clearer?

Again, Murray and I chatted offline about this. It's not MUAs that are 
the problem. MUAs that follow all of the rules of a service provider 
(e.g., who send user initiated reports to an address in the appropriate 
header field) are well within rights to be sending abuse reports 
directly (and if you want to argue against that, I'm happy to argue back 
*strongly*). The key is that you don't want reports that go addresses 
that *any* generator (MUA or otherwise) simply pulls out of some random 
From: field or the like. Again, I like Murray's suggested replacement:

    1.  Report generators SHOULD NOT send reports to recipients that are
        uninvolved or only peripherally involved.  For example, they
        SHOULD NOT send reports to the operator of every Autonomous
        System in the path between the apparent originating system and
        the operator generating the report.  Instead, they need to send
        reports to recipients that are both responsible for the messages
        and are able to do something about them.

That explains the concern. Being an MUA is not the problem.

pr

---

From: Pete Resnick <[email-masked]>
Date: Wed, 4 Apr 2012 13:59:10 -0500

On 4/3/12 3:36 PM, Murray S. Kucherawy wrote:
> Attached is a diff that should satisfy everything Pete just brought up.  Please let me know if there are any objections.

Well, mostly. :-)

> On 4/3/12 1:08 PM, Pete Resnick wrote:
>> 5.1.1.
>> described here". It seems utterly obvious. If you write a new 
>> document with new use cases, you can change the instruction. Also, 
>> why "need to" instead of "MUST"?
>
>     1.  Mail operators MUST proactively request a stream of ARF reports
>         from Mailbox Providers.  Recommendations for preparing to make
>         that request are discussed in Section 4.1 of [RFC6449].
>    

Um, OK, that makes it clear why it ought not be a MUST. :-) Seriously 
though, you *don't* want to say that *all* mail operators MUST a request 
(which is how the sentence currently reads). You probably want to say 
that all requests MUST be proactive. The first sentence needs re-arranging.

>     2.  Operators must be able to accept ARF [RFC5965] reports as email
>         messages [RFC5322] over SMTP [RFC5321].  These and other types of
>         email messages that can be received are discussed in Section 4.2
>         of [RFC6449].
>    

Is there a reason that first "must" is not capitalized?

> sending/[MUST/SHOULD] NOT send ?

This was not addressed.

Everything else seems to be covered, and see also my answer to Alessandro.

Thanks.

pr

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 04 Apr 2012 21:27:01 +0200

On 04/Apr/12 20:40, Pete Resnick wrote:
> everything as if it were "abuse".

Uh, I understood it as the the statement that the expected type of
report is abuse, so much that some software can be equipped to only
write "abuse" or to assume that it is "abuse" even without reading it.

> If you want to say "SHOULD use 'abuse' when it's abuse", then I'd
> like to hear why that's not a MUST.

Hmm... possibly to avoid putting too many requirements?  A good reason
to think that putting something different, e.g. "virus" is if one is
equipped to report viruses that way.  But even then, receivers may be
unable to treat it properly, and this has to be taken into account.
Using some common sense is probably better.

> Yes, Murray and I chatted about this offline, and what he has
> suggested for 6.1.1 explains that well:
> 

This doesn't seem to touch much on how to pause sending in case of an
overwhelming number of reports, but that text is fine for me anyway.

> (e.g., who send user initiated reports to an address in the
> appropriate header field) are well within rights to be sending abuse
> reports directly (and if you want to argue against that, I'm happy to
> argue back *strongly*).

I wouldn't object against a MUA's right to send an abuse report,
especially if the server it connects to doesn't do such service, or
does it poorly.  The point is that that's not how things should be.
Two reasons are as follows:

1. Rejecting spam is generally considered more effective than
   quarantining it.  Hence, it is good if the MUA cooperates with its
   server on this.  Signaling spam, in particular, provides a means to
   instruct filters for on-line rejection.

2. MUAs most often live behind a NAT and don't have the requisites
   for letting an occasional abuse report evolve into an established
   feedback arrangement.  A server may provide a web-based reporting
   shop for that.  This perspective is addressed in 6.5/4.

Is there a better way to convey that?

> The key is that you don't want reports that go addresses that *any*
> generator (MUA or otherwise) simply pulls out of some random From:
> field or the like. Again, I like Murray's suggested replacement:
> 

Pete, please don't get distracted by the way the diffs get produced,
that paragraph was there already.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Apr 2012 19:41:19 +0000

> From: Pete Resnick [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2012 11:59 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> though, you *don't* want to say that *all* mail operators MUST a
> request (which is how the sentence currently reads). You probably want
> to say that all requests MUST be proactive. The first sentence needs
> re-arranging.

How about:

ARF report streams MUST be established proactively between Report Generators and Mailbox Providers.  Recommendations for preparing to make that request are discussed in Section 4.1 of <xref target="RFC6449"/>.

> Is there a reason that first "must" is not capitalized?

Nope, fixed.

> > sending/[MUST/SHOULD] NOT send ?

I think this paragraph sets the stage for the normative stuff throughout the rest of the section.  It doesn't itself carry any normative advice.  It might thus best be relocated, still without 2119 language, to the top of Section 6.  Do you agree?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Apr 2012 19:48:36 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Wednesday, April 04, 2012 12:27 PM
> To: Pete Resnick
> Cc: [email-masked]

Sounds to me like you're saying the same thing.

> overwhelming number of reports, but that text is fine for me anyway.

I think that's already covered elsewhere.

>    instruct filters for on-line rejection.

Ah, right, this was lost to memory when Pete and I discussed it in Paris.  So how about this, re-inserted as 6.3/1:

   1.  Rather than generating feedback reports themselves, MUAs SHOULD
       make abuse reports back to their mailbox providers so that they
       can generate and send ARF messages on behalf of end users.  This
       allows centralized processing and tracking of reports, and
       provides training input to filtering systems.

...with a reference to Section 3.2 of RFC6449 thrown in there, now that I look at it.

(The deviation from the SHOULD would be cases where, for example, there is no mailbox provider separate from the end user.)

-MSK

---

From: "John Levine" <[email-masked]>
Date: 5 Apr 2012 05:44:33 -0000

>ARF report streams MUST be established proactively between Report
>Generators and Mailbox Providers.  Recommendations for preparing to make
>that request are discussed in Section 4.1 of <xref target="RFC6449"/>.

I don't see why 2119 language is appropriate here.  This is basically
a definition -- a solicited stream is one where there's an agreement,
an unsolicited stream where there isn't.  It's possible to
interoperate either way.

>> > sending/[MUST/SHOULD] NOT send ?

On the other hand I do think that 2119 is appropriate here.  Senders
of unsolicited reports SHOULD avoid gratuitously annoying people, and
MUST stop bothering people who've told them to stop.  If they don't,
recipients are likely to stop accepting reports which would mean they
don't interoperate.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 Apr 2012 17:16:51 +0000

> From: John Levine [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2012 10:45 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> >Generators and Mailbox Providers.  Recommendations for preparing to
> >make that request are discussed in Section 4.1 of <xref
> target="RFC6449"/>.
> 
> I don't see why 2119 language is appropriate here.  This is basically a
> definition -- a solicited stream is one where there's an agreement, an
> unsolicited stream where there isn't.  It's possible to interoperate
> either way.

That works for me.  I've struggled a bit to figure out when it's right to use 2119 language and when it's okay to just be pedagogical in an applicability statement, but I think I've gotten it now.

So this is now:

5.1.  General Considerations

   1.  ARF report streams are established proactively between Report
       Generators and Mailbox Providers.  Recommendations for preparing
       to make that request are discussed in Section 4.1 of [RFC6449].

> >> > I don't get why 2119 language is being avoided in the above. Why
> >> > not s/need to be aware of this and do all they reasonably can to
> >> > avoid sending/[MUST/SHOULD] NOT send ?
> 
> On the other hand I do think that 2119 is appropriate here.  Senders of
> unsolicited reports SHOULD avoid gratuitously annoying people, and MUST
> stop bothering people who've told them to stop.  If they don't,

This is now:

6.2.  When To Generate Reports

   1.  Handling of unsolicited reports has a significant cost to the
       receiver.  Senders of unsolicited reports, especially those
       sending large volumes of them automatically SHOULD NOT send
       reports that cannot be used as a basis for action by the
       recipient, whether this is due to the report being sent about an
       incident that is not abuse-related, the report being sent to an
       email address that won't result in action, or the content or
       format of the report being hard for the recipient to read or use.

How's that?

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 05 Apr 2012 19:25:36 +0200

On Thu 05/Apr/2012 18:12:41 +0200 Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>

More or less yes.  It's not a sharp concept, however tweaked.  I was
just trying to make sure we're not introducing wrong interpretations,
such as "always put the same type since recipients may not care"...

> Ah, right, this was lost to memory when Pete and I discussed it in
> Paris.  So how about this, re-inserted as 6.3/1:
> 

As long as "make abuse reports back" is clear, that may work.  MUAs
could use any of John's taxonomy techniques[1], I don't know if it
could be acceptable to refer to that page...

[1] http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs

> ...with a reference to Section 3.2 of RFC6449 thrown in there, now

Neat idea, IMHO.

For a nit, the I-D uses the term "report generator".  Its meaning is
obvious.  However, RFC 6449 uses "Feedback Provider" instead.  Would
the addition of a definition in Section 2 ease such references?  E.g.
something like so:

   A "report generator" is the entity or process that generates and
   sends reports.  For feedback reports, it belongs to a "Feedback
   Provider" in the sense of [RFC6449].  This memo uses the term
   Mailbox Provider to refer to these facets too.

> (The deviation from the SHOULD would be cases where, for example,
> there is no mailbox provider separate from the end user.)

More commonly, when its mailbox provider doesn't do reporting.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 Apr 2012 17:53:30 +0000

> From: Alessandro Vesely [mailto:[email-masked]]
> Sent: Thursday, April 05, 2012 10:26 AM
> To: Murray S. Kucherawy
> Cc: Pete Resnick; [email-masked]

It's meant to be a level-set of assumptions.  If you don't know how your report recipient will handle types other than "abuse" (which all of them use), then you can't make any assumptions.

> could be acceptable to refer to that page...

I'll note here that there's no standard signaling mechanism for use between MUAs and ISPs to trigger reports.

> [...]

Actually changing "report generator" to "Feedback Provider" is a better idea because it makes the two documents even more consistent with each other.  So I'll do that as well.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 5 Apr 2012 18:54:16 -0000

>       format of the report being hard for the recipient to read or use.

Ship it.

R's,
John

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 05 Apr 2012 08:09:48 -0400

In <[email-masked]>, on 04/04/2012

>Is there a better way to convey that?

Perhaps split it into what the MUA should do if the MSA provides for
ARF collection and what the MUA should do if it is on its own. I'd
like to say that the MUA MUST take advantage of centralized ARF
processing if available, but don't see how to square that with RFC
2119, "6. Guidance in the use of these Imperatives".

BTW, that issue applies to some of the other MUST language; in most
cases, we haven't shown that "it is actually required for
interoperation or to limit behavior which (sic) has potential for
causing harm (e.g., limiting retransmisssions)". 

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Pete Resnick <[email-masked]>
Date: Thu, 5 Apr 2012 18:03:57 -0500

On 4/5/12 7:09 AM, Shmuel Metz wrote:
> I'd

I went through them with all and I'm at least comfortable that all of 
the ones that are left are there to either improve interoperability or 
limit damaging behavior. If you see one that isn't, call it out.

pr

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Apr 2012 11:26:14 +0200

>        to make that request are discussed in Section 4.1 of [RFC6449].

s/Mailbox Providers/mail operators/.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Apr 2012 11:26:19 +0200

On Fri 06/Apr/2012 11:20:35 +0200 Murray S. Kucherawy wrote:
> I'll note here that there's no standard signaling mechanism for use
> between MUAs and ISPs to trigger reports.

Thanks.

> Actually changing "report generator" to "Feedback Provider" is a
> better idea because it makes the two documents even more consistent
> with each other.  So I'll do that as well.

Do you mean to extend Feedback Provider to also cover auth failures?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Apr 2012 14:18:22 +0000

> Sent: Friday, April 06, 2012 2:26 AM
> To: [email-masked]

Actually no, it's Feedback Providers and Feedback Consumers, per RFC6449.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Apr 2012 14:20:34 +0000

> Do you mean to extend Feedback Provider to also cover auth failures?

Sure.  Although the process in that case is automated, the definition still applies.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Apr 2012 18:01:24 +0200

> definition still applies.

In that case, I see no contraindication.  Please go ahead.

You may want to import RFC 6449's "Glossary of Standard Terms",
instead of (or in addition to) redefining Mailbox Provider.