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

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.

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.

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.

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.