> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Thursday, December 29, 2011 4:38 AM > To: [email protected] > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.txt > > Sections 6 and 7 are dedicated to solicited feedback. However, there > is a number of points that should be valid also for unsolicited > reports. If the order is not important, the common points could be put > in a common section. Specifically, for the sending part, Section 6, > here's the points I think should be common and why: > [...]
It doesn't seem to me the document is improved any by common factoring points out of those two sections into one that's common for both. Your comment does point out, however, that Section 8 should include a set of numbered "rules" as Sections 6 and 7 are; there's no reason for them to be inconsistent. So I'll do that. > 1. End-users report to mailbox providers, they shouldn't go > searching whois databases and similar stuff. This point is > partially repeated already in Section 8, where it says that > sending criteria "might include direct complaint submissions > from MUAs". Using ARF for MUA-to-MP is not discussed. I think "direct complaint submissions" in this context means that an unsolicited report is triggered by MUA action, not that the MUA complains directly to something found in a WHOIS database. I'll adjust the wording. > 2. Reports can be used to instruct filters. Section 3.1 of RFC6449 makes a vague allusion to this idea. I don't think this AS needs to re-state it, unless that's known to be a popular use of feedback reports. > 4. "Feedback-Type: abuse" is fine for unsolicited reports too. Copied. > 5. Ditto for other optional fields. Copied. > By contrast, points (3) and (6) cover solicited-specific stuff. > > For the receiving part, Section 7, the points are: > > 2. ARF over SMTP is fine for unsolicited feedback too. It doesn't strike me as reasonable to talk about receiving syntax and protocol requirements for the case where the feedback is unsolicited. We'd basically be forcing processing requirements on a non-participant. > 5. Optional fields may vary in unsolicited feedback too. Same deal; if they're not participating, that advice falls on deaf ears. For the unsolicited case, we really can only speak to the sender. > * Neither the RFC nor the draft mention degrading the offending IP's > profile at the firewall. Does it need to? As I said above, Section 3.1 of RFC6449 talks about filtering resulting from complaints but doesn't say what kind of filtering. > * The RFC says replying to feedback is useless. For unsolicited > feedback, especially the first times it's being sent, some sort of > acknowledge may be meaningful. I think that's a reasonable suggestion. I'll add something for -04. > * Both senders and receivers should keep a database of contacts and > annotate it regularly. The draft only mentions such operations for > the solicited case, referring to Section 4.4 of the RFC --point (3). I think that's a MAY at best, but I'll see if I can work that in to the previous point as well. > For Section 8, unsolicited complaints, the second paragraph needs to > clarify that "Senders" means "mailbox providers who are forwarding > their users' complaints". We are not stopping end-users from reporting > to whoever they like, e.g. SpamCop, are we? I'll change it to "report generators". > This WG already agreed that ARF messages are automated and the human- > readable part is boilerplate. Conversely, technical data for an abuse > team has to be sent in non-ARF messages unless it can fit into the > provided ARF fields. This concept needs to be stated, though. > The beginning of the third paragraph of Section 8 can be changed so as > to read like so: > > Recipients of unsolicited ARF reports SHOULD, in general, handle them > the same way as any other abuse reports. However, they can take > advantage of the ARF format to automate processing. Lacking [etc.] OK. > The converse can be put in the beginning of the last paragraph of > Section 8, e.g. like so: > > Published abuse-mailbox addresses SHOULD NOT reject non-ARF messages, > because producing ARF messages may occasionally be unavailable or not- > applicable. Nevertheless some large messaging service providers > specifically request that [etc.] OK. > Finally, I propose to add the following paragraphs to the Security > Considerations section: There's a common practice in IETF documents to avoid putting normative stuff in Security Considerations, which is supposed to be strictly informative. Not all documents follow this practice, but I prefer it. That said: > Mailbox Providers SHOULD perform any possible checks to ascertain > that the messages reported by their users, that they are about to > report in turn, really originated at the domain they intend to forward > it to. This includes checking that the reporting user did not > inadvertently or maliciously alter the reported message. Mailbox > Providers MAY digitally sign received messages on delivery in order to > perform this check. That seems reasonable. > Mailbox Providers SHOULD manually inspect the messages reported by > their users if their spam score is noticeably low --which might > indicate that the user hit the spam-button by mistake. Do users have spam scores? I don't know that that's a known implementation. We'd need to flesh this out quite a bit more for it to fly. > Mailbox Providers should evaluate the trustworthiness of the target > abuse team, possibly using external reputation providers. It is not > worth to send any information to domains that exist for the sole > purpose of spamming. Mailbox Providers MAY redact the reported > message, according to its policy and to the reputation of the > destination. Redacting techniques are discussed in [REDACT]. I think this is best added to the section on unsolicited reports, actually. > The obvious correction for an acknowledged policy contravention is to > remove the email address of the original recipient from whatever > storage it was retrieved from for sending the reported message, > including mailing lists. An abuse team may need to investigate > whether email addresses are stored legitimately on their customer's > systems, or if any malware is running there. I think this is already covered in general in RFC6449, to which the applicability statement draft refers. Thanks, I'll go through the replies to this and prepare a new version. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
