Complaint Feedback Loop Operational Recommendations
draft-jdfalk-maawg-cfblbcp-03

Received changes through RFC Editor sync (changed abstract to 'Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.

This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. This document is not an Internet Standards Track specification; it is published for informational purposes.')

[Ballot discuss]
Please reword the Abstract to remove the phrase "contributed to the
  IETF standards repository".  Since this is an Informational document,
  I believe this phrase will be confusing.  Suggestion:

  This document was originally produced by the Messaging Anti-Abuse
  Working Group (MAAWG), a trade organization separate from the
  IETF.  The original MAAWG document was published in April 2010.
  This document is being published as an Informational RFC to make it
  widely available to the Internet community and simplify incorporation
  of this material into IETF documents.

[Ballot comment]
These are recommendations from MAAWG, and they are being published as an informational, non-consensus document so that a WG can refer to the document. Such a WG may agree with all of the recommendations, but more likely will have some alternative advice when referring to this document. The IESG should decide whether an IESG note explaining this is necessary, but I think the standard template for a non-consensus document ("This document is not an Internet Standards Track specification; it is published for informational purposes. It has been approved for publication by the Internet Engineering Steering Group (IESG).") is probably sufficient.

[Ballot comment]
The point below was originally a discuss. On the basis that the
boilerplate will make it quite clear that the content here is not
IETF work, and that WG documents referencing this will be open to
discusses in how they reference this, I've cleared. I would
*really* like to see this addressed if maawg are willing since
it stands out like a sore thumb in what is an otherwise fine and
useful document.

It seems wrong to recommend ways to figure out the actual
recipient email address from which the complaint originates, when
that has been (perhaps badly) redacted by the feedback provider.
I doubt such text would be accepted as-is in an IETF WG
document. Shouldn't the text on p25 ("It can be very difficult to extract...")
down to "...and trending analysis).") that hints at how to do that
also at least say that doing so is acting contrary to the wishes of
such a feedback provider and perhaps the end user that originated
the complaint? Or, perhaps you should give some more effective
advice to the privacy sensitive end-user or feedback provider?
(Which may practically amount to "don't *ever* send feedback";-)
Note: I'm not asking that the mail industry reform itself and I'm not
sure how effective it may be to put a discuss on a document like
this, but I'd be much happier if this could be fixed somewhat.

The remainder were my original comments about which I am a
good bit less concerned.

There are quite a few comments here. Given the provenance
of this document, I'm pretty much fine if they're entirely ignored
and just offer than as a potential ways to improve the text if
doing so is possible at this point in time.

- It seems a bit odd that this I-D is justified as being a way to
allow MAAWG work items to be more easily referenced, but yet, this
document refers to other MAAWG without apparent difficulty. (Refs,
[2,5]) I've no objection to this, but it does make me curious.

- secdir review comment: The security considerations consist of a
single line that refers readers to 3 other sections of the draft,
none of which it appears to me deal with security. I would suggest a
rewording of this to make the section broadly address the security
implications of implementing, joining, or contributing to a
"complaint feedback loop". Maybe also have a little something about
countermeasures or dealing with spammers trying to game the system.

- Definition of FBL - why bother? if you leave it in then maybe s/in
this document/in the rest of this document/ because the current
statement is false and self-contradictory.

- Just to note that the term "loop" is a bit misleading here since
the spammer sender is rarely going to get their spam back which
would be required for these to be loops. It might just be worth
noting that (probably at 3.1, 3rd para where you almost but not
quite say this).

- p10 says "every complaint is sent immediatedly" which is not quite
right, perhaps s/sent/forwarded/ would be more accurate?  (I might
not read mail for the weekend and then the complaint won't be sent
"immediately" for example.)

- (p10, last para) If there's evidence that message recipients
*often prefer* "this method" then referencing that would be good,
otherwise this reads like it might be just a self-serving claim.
(I'm not saying it is, I'm just saying how it looks.) More
generally, supplying references to studies etc. that backup the
claims made as to user preferences and effectiveness of the various
options would make this a much more convincing read. (I understand
that such studies may not typically be openly available in this area
- however that does substantially weaken the claims made.)

- p11, presumably real usability studies will take account of
selection bias, so s/average// would seem slightly better.

- p11, last para - this reads like having mailbox providers also
provide an MUA or plug-in or whatever is an unqualified good thing.
I think that's a little overstated, since the ability to be migrate
between mailbox providers is also a (conflicting) good thing. It
might be good to note that there are downsides to having a mailbox
provider provide s/w to end users as well.

- p12, I'm not quite sure what "keyed to" means here.

- p16, the bullets at the top - the 4th last bullet says "other
unspecified stuff" basically which is fine, but then subsequent
bullets are listing "optional" things - I can't see how "other
unspecified stuff" can be anything except optional, so I suggest
marking that bullet as optional as well.

- p16, section 3.6.1 is titled "IP validation" but makes no mention
at all of IP, suggest changing the title to "Re-validation" maybe?

- p17, 1st para: 3.6.2 talks about validating the addresses
"associated with an IP", and 3.6.3 talks about "one's own IP" - I
think this is showing up a set of IPv4 specific assumptions that
have been made in these systems that will be changing with the
deployment of IPv6 or maybe CGN and would suggest that rephrasing
sentences like this to not refer to IP, except where that's really
needed would be an improvement.

- p19, point 3 says "a list of IP addresses" but I don't get why
this might not be based on mail domain names or FQDNs as well (esp.
with DKIM). In the same bullet, I don't think the mechanisms given
"prove" ownership (if we ever "own" IP addresses?), so saying that
these are checks that tend to get made would be a better phrasing.

- p22, is keeping the "customer" happy the right phrase here?  The
complainant is probably not a customer of the feedback consumer.

- p22, s/broken down/analysed/ would be better

- p22, seems like there's an assumption in 4.3.2, para 2, that an IP
address is the same as a server which isn't really the case these
days and I guess can cause problems with IPv4 addesses and maybe
more with IPv6. I'd say just calling out that this is generally
assumed these days (if that's the case) is enough at this point,
though I do wonder how VMs of various kinds are affected by this.

- p22, 432, 3rd para - at the end you use the term "problem
customers" but its not quite clear that you're referring to
problematic customers of the ESP sending mail that generates more
complaints than most, or if you're referring to a complainant that
complains more than most (the former I assume).

- p23, I'd be interested in some backup as to why a 2% complaint
rate is grounds for immediate blocking. Has anyone published data
about best practices or what some large mail senders/receivers
actually do?

- p23, I don't think you really mean "smallest of users" since
height is probably not well correlated with email behaviour:-)
Perhaps "Even a feedback consumer with very minimal demands..." 
or something?

- p24 - s/originating sending/originating/ ?

- p25 - s/sent from/sent/ in the bullet at the top of the page

- p33 - I suggest s/take responsibility/take some responsibility/
which was the semantic understood (by me at least:-) in the DKIM WG.

[Ballot comment]
In order to resolve my concern below (originally a Discuss), could you change the (a) the boilerplate text as agreed in other discussions and (b) change the abstract to say s/easier to incorporate this material into IETF work/easier to reference this material from IETF work/

----

It is a good idea to publish this, thank you for bringing it to an internet draft form and the IETF.

However, I think the copyright disclaimer statements are currently in an unacceptable form. Is this a mistake, or were these settings deliberate? I think we need to discuss this. The document is also internally inconsistent:

  While not originally written as an
  Internet Draft, it has been contributed to the IETF standards
  repository in order to make it easier to incorporate this material
  into IETF work.

....

  This document may not be modified,
  and derivative works of it may not be created, and it may not be
  published except as an Internet-Draft.

and yet it is brought to the IETF to incorporate material into IETF work, and to publish as an RFC!

[Ballot discuss]
Please reword the Abstract to remove the phrase "contributed to the
  IETF standards repository".  Since this is an Informational document,
  I believe this phrase will be confusing.  Suggestion:

  This document was originally produced by the Messaging Anti-Abuse
  Working Group (MAAWG), a trade organization separate from the
  IETF.  The original MAAWG document was published in April 2010.
  This document is being published as an Informational RFC to make it
  widely available to the Internet community and simplify incorporation
  of this material into IETF documents.

[Ballot discuss]
It is a good idea to publish this, thank you for bringing it to an internet draft form and the IETF.

However, I think the copyright disclaimer statements are currently in an unacceptable form. Is this a mistake, or were these settings deliberate? I think we need to discuss this. The document is also internally inconsistent:

  While not originally written as an
  Internet Draft, it has been contributed to the IETF standards
  repository in order to make it easier to incorporate this material
  into IETF work.

....

  This document may not be modified,
  and derivative works of it may not be created, and it may not be
  published except as an Internet-Draft.

and yet it is brought to the IETF to incorporate material into IETF work, and to publish as an RFC!

[Ballot comment]
The definition in Section 1 has one instance of "spam" (all lowercase) but in the remainder of the document aside from Appendix C the only form used is "Spam" (initial caps).

In Section 3.2, does "proprietary desktop client" exclude open-source implementations?

In Section 3.5, why not cite RFC 2142? Such as: "best sent to abuse@ or postmaster@ the domain in question, per [RFC2142]".

Appendix A.2 cites RFC 5965 and two websites as sources of canonical documentation for ARF, one of which points to draft-shafranovich-feedback-report-01 whereas the other points to draft-shafranovich-feedback-report-05. How is a developer to know which specification is in fact canonical? Please just point to RFC 5965 for documentation and to the websites for additional information.

[Ballot comment]
There are some characters misaligned in Figure 1 that should be fixed.

It's probably not right to say "IETF standards repository" in the abstract; I think you really just mean "the RFC Series" or something like that.

[Ballot discuss]
This is a discuss-discuss. No action from the editors is requested at this time.

Pete's comment indicates this is intended to be published as a non-consensus document
(even though it's been last called). That would mean 2nd paragraph of boilerplate (per 5741
section 3.2.2) would be:
  This document is a product of the Internet Engineering Task Force (IETF).  It has been
  approved for publication by the Internet Engineering Steering Group (IESG).

And would _not_ contain "It represents the consensus of the IETF community."

Is that the intent? If so, how does that get captured and passed to the RFC Editor?

[Ballot discuss]


This draft contains the following restrictions on publication from 6.c.ii of the TLP:

  This document may not be modified,
  and derivative works of it may not be created, and it may not be
  published except as an Internet-Draft.

I'm thinking you meant to include the text from 6.c.i:

  This document may not be modified, and derivative works of it
  may not be created, except to format it for publication as an RFC
  or to translate it into languages other than English.

Otherwise, it can't be published as an RFC.

Need to split references between normative and informative.  If they're all one kind just put informative or normative in front of references in the title.

Needs an IANA Considerations section.  If there are none, then the section can simply be:

  IANA Considerations

  None



Pete: Are you planning on publishing it with this boiler plate:

  This document is a product of the Internet Engineering Task
  Force (IETF).  It represents the consensus of the IETF community.
  It has received public review and has been approved for publication
  by the Internet Engineering Steering Group (IESG)."

or this boiler plate:

  This document is a product of the Internet Engineering Task
  Force (IETF).  It has been approved for publication by the Internet
  Engineering Steering Group (IESG)."

[Ballot comment]
s*: r/paper/document  Normally I-Ds/RFCs use document rather than paper.  So much more official ;)

s1: Complaint Feedback Loop - There isn't a taxonomy section so maybe it should just be "See Overview section." ?

s1: FBL - I had to chuckle there's an extremely long list of acronyms not used and they got left out - why mention this one?  BTW - fbl it's in s4.1 step 2 and in s4.4 ;)

s*: The concept of the loop is odd in that spammer isn't really going to be in the loop.  In fact, you want to get rid of them.

s2: Uses the term authorized Feedback Consumer.  The definition in s1 didn't make any distinction between Feedback Consumers.  I guess this my round about way of asking if all Feedback Consumers are authorized?

s3.3: "keyed to" maybe "assigned to"?

s3.4.2: r/approved entity/authorized entity - to match s2.

s3.4.1 & 3.4.2: Often folks quote the Fair Information Practices when dealing with privacy issues.  Maybe instead of munging them together in the terms of use you could just list them like:

- Notice and Consent:
- Collection Limitation:
- Use/Disclosure Limitation:
- Retention Limitation:
- Accuracy:
- Access:
- Security:

I've got no idea how you'd implement access, because of course spammers want to know what people have said about them.  Then again maybe they don't because then you could track them?

s8: Update references to RFC 4871 to RFC 6376.

[Ballot comment]
s*: r/paper/document  Normally I-Ds/RFCs use document rather than paper.  So much more official ;)

s1: Complaint Feedback Loop - There isn't a taxonomy section so maybe it should just be "See Overview section." ?

s1: FBL - I had to chuckle there's an extremely long list of acronyms not used and they got left out - why mention this one?  BTW - fbl it's in s4.1 step 2 and in s4.4 ;)

s*: The concept of the loop is odd in that spammer isn't really going to be in the loop.  In fact, you want to get rid of them.

s2: Uses the term authorized Feedback Consumer.  The definition in s1 didn't make any distinction between Feedback Consumers.  I guess this my round about way of asking if all Feedback Consumers are authorized?

s3.3: "keyed to" maybe "assigned to"?

s3.4.2: r/approved entity/authorized entity - to match s2.

s4.3.1 & 3.4.2: Often folks quote the Fair Information Practices when dealing with privacy issues.  Maybe instead of munging them together in the terms of use you could just list them like:

- Notice and Consent:
- Collection Limitation:
- Use/Disclosure Limitation:
- Retention Limitation:
- Accuracy:
- Access:
- Security:

I've got no idea how you'd implement access, because of course spammers want to know what people have said about them.  Then again maybe they don't because then you could track them?

s8: Update references to RFC 4871 to RFC 6376.

[Ballot discuss]


This draft contains the following restrictions on publication from 6.c.ii of the TLP:

  This document may not be modified,
  and derivative works of it may not be created, and it may not be
  published except as an Internet-Draft.

I'm thinking you meant to include the text from 6.c.i:

  This document may not be modified, and derivative works of it
  may not be created, except to format it for publication as an RFC
  or to translate it into languages other than English.

Otherwise, it can't be published as an RFC.

Need to split references between normative and informative.  If they're all one kind just put informative or normative in front of references in the title.

Needs an IANA Considerations section.  If there are none, then the section can simply be:

  IANA Considerations

  None



s3.4.2: When reading s3.4.1 and s3.4.2, I'm curious why the Terms of Use doesn't include the Message Recipient/End User who says this message is spam.

[Ballot comment]
There are quite a few comments here. Given the provenance
of this document, I'm pretty much fine if they're entirely ignored
and just offer than as a potential ways to improve the text if
doing so is possible at this point in time.

- It seems a bit odd that this I-D is justified as being a way to
allow MAAWG work items to be more easily referenced, but yet, this
document refers to other MAAWG without apparent difficulty. (Refs,
[2,5]) I've no objection to this, but it does make me curious.

- secdir review comment: The security considerations consist of a
single line that refers readers to 3 other sections of the draft,
none of which it appears to me deal with security. I would suggest a
rewording of this to make the section broadly address the security
implications of implementing, joining, or contributing to a
"complaint feedback loop". Maybe also have a little something about
countermeasures or dealing with spammers trying to game the system.

- Definition of FBL - why bother? if you leave it in then maybe s/in
this document/in the rest of this document/ because the current
statement is false and self-contradictory.

- Just to note that the term "loop" is a bit misleading here since
the spammer sender is rarely going to get their spam back which
would be required for these to be loops. It might just be worth
noting that (probably at 3.1, 3rd para where you almost but not
quite say this).

- p10 says "every complaint is sent immediatedly" which is not quite
right, perhaps s/sent/forwarded/ would be more accurate?  (I might
not read mail for the weekend and then the complaint won't be sent
"immediately" for example.)

- (p10, last para) If there's evidence that message recipients
*often prefer* "this method" then referencing that would be good,
otherwise this reads like it might be just a self-serving claim.
(I'm not saying it is, I'm just saying how it looks.) More
generally, supplying references to studies etc. that backup the
claims made as to user preferences and effectiveness of the various
options would make this a much more convincing read. (I understand
that such studies may not typically be openly available in this area
- however that does substantially weaken the claims made.)

- p11, presumably real usability studies will take account of
selection bias, so s/average// would seem slightly better.

- p11, last para - this reads like having mailbox providers also
provide an MUA or plug-in or whatever is an unqualified good thing.
I think that's a little overstated, since the ability to be migrate
between mailbox providers is also a (conflicting) good thing. It
might be good to note that there are downsides to having a mailbox
provider provide s/w to end users as well.

- p12, I'm not quite sure what "keyed to" means here.

- p16, the bullets at the top - the 4th last bullet says "other
unspecified stuff" basically which is fine, but then subsequent
bullets are listing "optional" things - I can't see how "other
unspecified stuff" can be anything except optional, so I suggest
marking that bullet as optional as well.

- p16, section 3.6.1 is titled "IP validation" but makes no mention
at all of IP, suggest changing the title to "Re-validation" maybe?

- p17, 1st para: 3.6.2 talks about validating the addresses
"associated with an IP", and 3.6.3 talks about "one's own IP" - I
think this is showing up a set of IPv4 specific assumptions that
have been made in these systems that will be changing with the
deployment of IPv6 or maybe CGN and would suggest that rephrasing
sentences like this to not refer to IP, except where that's really
needed would be an improvement.

- p19, point 3 says "a list of IP addresses" but I don't get why
this might not be based on mail domain names or FQDNs as well (esp.
with DKIM). In the same bullet, I don't think the mechanisms given
"prove" ownership (if we ever "own" IP addresses?), so saying that
these are checks that tend to get made would be a better phrasing.

- p22, is keeping the "customer" happy the right phrase here?  The
complainant is probably not a customer of the feedback consumer.

- p22, s/broken down/analysed/ would be better

- p22, seems like there's an assumption in 4.3.2, para 2, that an IP
address is the same as a server which isn't really the case these
days and I guess can cause problems with IPv4 addesses and maybe
more with IPv6. I'd say just calling out that this is generally
assumed these days (if that's the case) is enough at this point,
though I do wonder how VMs of various kinds are affected by this.

- p22, 432, 3rd para - at the end you use the term "problem
customers" but its not quite clear that you're referring to
problematic customers of the ESP sending mail that generates more
complaints than most, or if you're referring to a complainant that
complains more than most (the former I assume).

- p23, I'd be interested in some backup as to why a 2% complaint
rate is grounds for immediate blocking. Has anyone published data
about best practices or what some large mail senders/receivers
actually do?

- p23, I don't think you really mean "smallest of users" since
height is probably not well correlated with email behaviour:-)
Perhaps "Even a feedback consumer with very minimal demands..." 
or something?

- p24 - s/originating sending/originating/ ?

- p25 - s/sent from/sent/ in the bullet at the top of the page

- p33 - I suggest s/take responsibility/take some responsibility/
which was the semantic understood (by me at least:-) in the DKIM WG.

[Ballot discuss]
It seems wrong to recommend ways to figure out the actual
recipient email address from which the complaint originates, when
that has been (perhaps badly) redacted by the feedback provider.
I doubt such text would be accepted as-is in an IETF WG
document.

Shouldn't the text on p25 ("It can be very difficult to extract...")
down to "...and trending analysis).") that hints at how to do that
also at least say that doing so is acting contrary to the wishes of
such a feedback provider and perhaps the end user that originated
the complaint? Or, perhaps you should give some more effective
advice to the privacy sensitive end-user or feedback provider?
(Which may practically amount to "don't *ever* send feedback";-)

Note: I'm not asking that the mail industry reform itself and I'm not
sure how effective it may be to put a discuss on a document like
this, but I'd be much happier if this could be fixed somewhat.

So I guess the first part of my discuss to think about is:

Is there some way to fix this for the IETF version of the document?

[Ballot comment]
There was some last call discussion that indicating that some people found the "About MAAWG" paragraph in the Abstract untoward. Personally, I think it would be better to put the paragraph in the Acknowledgments section, or it could be simply put as a paragraph in the References section under reference [1].

These are recommendations from MAAWG, and they are being published as an informational, non-consensus document so that a WG can refer to the document. Such a WG may agree with all of the recommendations, but more likely will have some alternative advice when referring to this document. The IESG should decide whether an IESG note explaining this is necessary, but I think the standard template for a non-consensus document ("This document is not an Internet Standards Track specification; it is published for informational purposes. It has been approved for publication by the Internet Engineering Steering Group (IESG).") is probably sufficient.

I have an RFC Editor note to change the page header from "CFBL BCP" to "CFBL Recommendations". If the authors wish something different, they are free to suggest.

[Ballot comment]
There was some last call discussion that indicating that some people found the "About MAAWG" paragraph in the Abstract untoward. Personally, I think it would be better to put the paragraph in the Acknowledgments section, or it could be simply put as a paragraph in the References section under reference [1].

These are recommendations from MAAWG, and they are being published as an informational, non-consensus document so that a WG can refer to the document. Such a WG may agree with all of the recommendations, but more likely will have some alternative advice when referring to this document. The IESG should decide whether an IESG note explaining this is necessary, but I think the standard template for a non-consensus document ("This document is not an Internet Standards Track specification; it is published for informational purposes. It has been approved for publication by the Internet Engineering Steering Group (IESG).") is probably sufficient.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Complaint Feedback Loop Operational Recommendations) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Complaint Feedback Loop Operational Recommendations'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Complaint Feedback Loops similar to those described herein have
  existed for more than a decade, resulting in many de facto standards
  and best practices.  This document is an attempt to codify, and thus
  clarify, the ways that both providers and consumers of these feedback
  mechanisms intend to use the feedback, describing some already-common
  industry practices.

  This paper is the result of cooperative efforts within the Messaging
  Anti-Abuse Working Group, a trade organization separate from the
  IETF.  The original MAAWG document upon which this document is based
  was published in April, 2010.  While not originally written as an
  Internet Draft, it has been contributed to the IETF standards
  repository in order to make it easier to incorporate this material
  into IETF work.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-jdfalk-maawg-cfblbcp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-jdfalk-maawg-cfblbcp/


No IPR declarations have been submitted directly on this I-D.

PROTO writeup for draft-jdfalk-maawg-cfblbcp-02

Publication of draft-jdfalk-maawg-cfblbcp-02, an individual submission, is requested as an Informational RFC.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Barry Leiba is the document shepherd.  I have reviewed this version, and am satisfied that it's ready.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document is a re-publication of a document from an industry consortium, the Messaging Anti-Abuse Working Group (MAAWG), with which the IETF has a liaison relationship (I am the IETF liaison to MAAWG).  It has had extensive review within MAAWG and has been approved for publication by the MAAWG board.  Within the IETF, it has had significant review from the MARF working group, to which it is related, and I have no concerns about the level of review.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

I have no concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There is no IPR involved.  The document is the work of MAAWG, and MAAWG does wish to retain change control.  Because of that, publication is being requested as re-publication of work from an industry consortium, as noted in BCP 78 (RFC 5378), section 3.3, last paragraph.  The text from the Trust Legal Provisions 4.0 section 6.c(i) is included in this document.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

There is consensus of MAAWG, as well as general agreement in our MARF working group.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

I have so verified.  There are nits identified by the tool, but they're due to the fact that this is a re-publication.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

All references are grouped together, as is the manner for MAAWG documents.  As this is intended to be Informational, there are no issues with normative or downward references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

There are no IANA issues with this document, and, as a re-publication, no IANA Considerations section is included.  The Area Director may want to place a note to IANA with this document, to make that clear.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

There is no formal language in this document.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

The intent of a Complaint Feedback Loop is to provide Feedback Consumers with information necessary to mitigate Spam or the perception of Spam.  Thus, feedback was originally only offered to mailbox, access and network providers - in other words, to ISPs - who would use the feedback to identify network compromises and fraudulent accounts, or to notify their downstream customer that there may be a problem.

Senders of bulk, transactional, social or other types of email can also use this feedback to adjust their mailing practices, using Spam Complaints as an indicator of whether the Recipient wishes to continue receiving email.  Common reactions often include refining opt-in practices, mailing frequency, list management, message content and other measures.

This document re-publishes practices recommended by the Messaging Anti-Abuse Working Group (MAAWG) related to Complaint Feedback Loops.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

Nothing to note; this document was developed in MAAWG, an industry consortium.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?
       
A number of MAAWG member organizations have endorsed these recommendations and are implementing them in their mail systems.