Apologies for not replying to this sooner. The Quebec City IETF conference was quite busy, and I'm only now de-queuing various pending MARF work.
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of zav961 > Sent: Thursday, July 28, 2011 5:15 PM > To: [email protected] > Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain > > Of course, MARF also has its use in Outlook or similiar Mail Software > where a user can push a button to mark a mail spam, or not spam, and > the sending ISP (and/or filter provider) automatically gets informed > upon that user intervention. A fully manual MARF report would seem over > the top however. I don't think anyone envisioned construction of ARFs by hand, the same as one would never imagine generating an MDN or DSN by hand. But getting support for it in more MUAs would be very desirable. I imagine it's a lot like any new mail protocol though: Producers are waiting for consumers, and vice-versa. To the general question of sending malware payloads in ARF reports, perhaps this is something JD could add to the reporting discovery draft, i.e., whether or not an FBL consumer expresses willingness to accept malware payloads. > Well, if that claim of no-one ever reporting malware automatically ever > existed, our implementation is the living example to the contrary. Naturally any such claim is based on one's own knowledge. It just means we've never heard of one, which in turn means we have no experience with them. > > If people concur that this is an issue, I would suggest > > updating the base document to provide a requirement that a > > virus report include the name of the reporting software and > > the virus name it used, and restrict the third MIME part to > > be text/rfc822-headers. > > I obviously support that motion! I would suggest then that you or someone interested in seeing that change made take some time to produce an individual submission draft and then submit it to the working group for consideration. I'm happy to provide guidance on how to do that if needed. > When I mentioned advertising the IP address of the potential MARF > report transmitter similiar to SPF, I overlooked an important security > question (that's always the danger of a single brain thinking). SPF and > MARF have a decisive difference in the use for the bad boys. SPF is > hardly exploitable even if it gets under full control of a malicious > user. However, MARF could become a dangerous tool in the hands of a > malicious user misleading ISPs/regulating bodies or launching DoS > attacks against abuse departments. Which leads me to think on a second > thought that the MARF senders should be identified through ARIN and > their delegated authorities, too, just like the abuse mail addresses. > That approach immediately puts the out of band topic to rest, too. There's a separate document in the working group (which I think you've seen) discussing a method to advertise the preferred destination for feedback reports. I think, for both political and technical reasons, that venue is a lot more likely to be successful than an attempt to change what's available through WHOIS. We already do say (or at least, I'm pretty sure we do) that ARF reports shouldn't be accepted or trusted other than by prior arrangement, specifically to reduce the threat of injection of false reports. Some of that includes suggestions like ensuring reports are signed somehow so that their authenticity can be verified. I'm sure some implementations also check SPF. > A) feedback-type: virus > > I propose to change the keyword virus to malware. A straight rename is probably a problem in case it's already in widespread use. You might get away with defining "malware" and deprecating "virus", although I have some doubts about that too. > In the report section following fields become mandatory: > [...] I suggest putting this stuff in a draft and bringing it to the working group. > B) MARF Discovery (_report subdomain) > > B.1 Rethink the whole draft in view of automated responders, malicious > abuse and ongoing ARIN database extensions, I'd think the current > proposal could be dropped > > B.2 Require ARIN/delegated authorities published abuse addresses to > unconditionally accept MARF reports (they automatically do as it stands > due to the humanly readable first part and third part containing the > relevant evidence) > > B.3 Introduce a MARF sender identification (via IP address(es)) with > ARIN/IP assignment authorities similiar to abuse address registration > > B.4. As long as ARIN/IP assignment authorities are not featuring such > MARF database entries import the SPF RFC replacing selector SPF with > MARF for identifying authorised MARF transmitters. As I'm learning now with the fledgling WEIRDS effort, the IETF has no purview to cause ARIN or any RIR to do anything in terms of what data they require from registrants or make available via WHOIS. That's something you'd have to pursue with ICANN, as it's entirely a matter of policy and not one of technology. (I'm not sure how that logic jives with RFC2142, however.) If this is important to your vision, I suspect dropping the reporting-discovery document is in fact the wrong thing to do, and instead we should work at updating it to match your needs in a way that achieves consensus. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
