> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Simon > Hradecky > Sent: Thursday, July 28, 2011 11:18 AM > To: [email protected] > Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain > > If we start to discuss, whether that combination of virus name and > virus scanner is really sufficient as evidence, then we will also need > to raise the question, whether the full message is any evidence at all. > The message could be tampered with (could be modified), the message > could never ever have been sent, ... The MARF could actually be sent by > a bad guy trying to lure the ISP's abuse department into taking action > against an innocent customer! With that in mind, it does make perfect > sense to publish the IP address of permitted MARF senders for a > particular domain, similiar to SPF.
My understanding is that the general practice of an FBL is that they are not typically established in an automated fashion. That may change a little as we do the reporting discovery work, but at the moment I don't think there are any parties that just start sending or accepting FBLs and assuming they're all valid. Thus, there's already an out-of-band component to establishing an FBL, and it makes sense to prearrange a list of authorized IP addresses in that process rather than in the base protocol. That said, we could entertain the idea of supporting this in the reporting discovery work. I suggest you write actual text you'd like to see added to that document to support this idea, and then we can debate it. > Now, in order to enforce a regulation is it possible to violate the > regulation? Certainly not. So, as we agree that malware should not be > transmitted over the Internet (and Netiquette as well as RFCs actually > require to not send such abuse), why would we then ENFORCE sending such > malware in abuse reports? We agree, malware should not be sent, hence > the abuse reporting mechanism should provide for that. That's the > generic idea behind my proposal. You cited RFC3834 in previous email as your basis for the "RFCs" claim above. I disagree that it applies to FBLs, which are typically activated by humans and not by software to report spam, and thus aren't automated messages. I believe someone (you or someone else) claimed that nobody has implemented an FBL that reports viruses so far. If that's the case, we could consider updating the registry to mark it as historic. Those are the places where RFC3834 might apply. But later you say virus FBLs are likely, so then the above text doesn't apply. > ad input from malware folks, drop malware reporting altogether: > --------------------------------------------------------------- > > I suspect that just like me those good folks didn't see a lot of need > so far, more or less free format mails were generated so far. However, > a number of ISPs have started to require ARF format for all mail > arriving at their abuse department, so malware reporting has started to > become an issue and feedback will probably start to flow in. > > MARF represents mail abuse reporting format, not just spam reporting > format, hence it should be able to cater for proper malware reporting, > too. By dropping, or not supporting a proper malware reporting, MARF > could actually contribute to malware authors escaping any form of > control/abuse handling. 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. > ad "Reported-CVE-Id": > --------------------- > > Full support on my side, I actually forgot about that. I'd treat this > as an optional field for those virus scanners, the database of which > permit to identify attached CVE IDs. The scanners I am aware of > currently do not cater for that facility. Can you (or someone) propose specific new text to the base document we should be considering? > ad encryption of malware: > ------------------------- > > Bandwidth is an issue despite encryption, as I said above, identifying > the virus can be seen as a very effective compression, and at the same > time removes the requirement of sending malware across the internet (to > a possibly unexpecting receiver). There may be FBLs (such as one run by a malware analysis company) that want to get every variant of a virus. Reporting only the virus name and detection software would mean the details of a variant are lost. I don't know if this is an issue or not. > Who does need and can take use of the actual malware body? Those who > write virus scanners, obviously, they however had according (expecting) > reporting channels already via their websites. They might wish to switch to FBLs as a standard way of doing this. Perhaps we should ask them. > If we don't trust that the MARF report contains accurate data, why > would we assume the contained message is accurate? It could as well be > just produced from any place without any actual mail having been > received. This, I believe, is a restatement of the out-of-band issue; we know (or at least assume) that reports from random sources can't be trusted. > ad FBL: > ------- > > The MARF contains a clear free text section, feedback section and > evidence section for good reason. The MARF can that way be processed by > either any human monitoring an abuse mailbox, an automatic handling > tool and/or both. So, why then restrict the use of MARF to only those > who actually expect a MARF? Would the abuse department not requiring > nor being prepared for MARF not be interested in seeing the spam mail, > or know about what malware was sent from where? So, whether or not it > is MARF, the abuse report does need to contain such stuff. So, why not > send MARF (and "promote" it that way) on ANY abuse report if the > complainer's reporting utility is capable of MARF? > > However, then MARF must not assume that the recipient is expecting and > capable of handling such unsafe content, which again is another > argument of shaping the evidence section according to need. It's not clear to me what change you're proposing here. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
