On 15/May/11 18:27, J.D. Falk wrote: > http://datatracker.ietf.org/doc/draft-jdfalk-marf-as/ > > I've already noticed a couple of minor things I need to correct, > but I'll wait until there've been more comments before uploading > another version. > > What do y'all thank?
Would it be possible to expand treatment of non-FBL data? I heard rumors about FBL being considered illegal in Europe. I'd bet it's not, although EU law requires users' consent. At any rate, for clarity, I'd avoid calling "FBL" the unsolicited feedback generated without prior agreement. Appendix C in the CFBL BCP has some preliminary work on non-FBL. A topic that I think should be worked out a little bit more is the choice between mailbox and access providers. In section 2 of ARF-AS I would say that a report can alternatively be sent to one of a) a sender authenticated with DKIM or SPF, b) the abuse-mailbox found in the RIR WHOIS database for the IP address of the boundary relay, or c) a network provider higher in such allocation hierarchy. In section 3, I'd complement bullet (c) above with the suggestion that a network provider who receives a report relative to an IP that they gave to a mailbox provider, may forward that report to that provider's abuse-mailbox, besides possibly doing their own trending. Bullet (a) should also be cross-checked with WHOIS data, according to the last paragraph of section C1 of CFBL BCP. I'm not sure how. Should abuse-mailbox's parent entries have a (repeatable) "domain" attribute? Domain WHOIS apparently don't have abuse-mailboxes. The CFBL BCP says to ignore abuse-reports sent by mistake. Perhaps, this is where the non-spam ARF type has to be used, sending back the message to the author's mailbox provider so that they can undo any learning they had imparted to their spam filtering systems. Of course, the non-spam report needs to be acknowledged by the user who originally reported the message as spam. In case the user and the remote provider don't agree, either one or both of them deserve being categorized as bogus abuse-report sources. (As silly as this may seem, it may turn out to be a good way to categorize gullible spammers and unreliable users.) For a minor point, the possibility to redact reported messages is not mentioned. _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
