I am the author of the message forwarded regarding the virus feedback type and the _report subdomain. I decided to now join the mailing list and comment on a couple of points raised. This mail may not get properly threaded though for the lack of in-reply-to and reference fields that I can't insert into the mailer.
ad Point evidence ----------------- I see the name of the virus together with the name of the virus scanner producing the identification as equivalent to the actual byte stream, I actually compare it to a compression utility in that sense, just that there's a lot better compression factor. 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. ad point prevent sending malware in first place ----------------------------------------------- Of course, that would be the ideal case. However, as always with regulations and law, there are always people not adhering and sending such stuff nonetheless. 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. ad ARIN database: ----------------- thanks, Alessandro, I am delighted about that announcement. 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. 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. 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). The malware may well be in the order of several 100K, maybe even MBs of attachment, while the virusname is a matter of possibly 128, maybe 512 bytes. Is that line as well as mailbox congestion really worth sending an attachment, that is fully identified by the virusname anyway so that the recipient could go in his database, fetch a sample of that thing and knows the identified malware exactly byte by byte? 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. What would the ISP do with the binary file he gets sent? The human eye wouldn't see anything, he might run his own virus scanner over it to get the same result the sender already had, and all we achieve is using up bandwidth on Internet and CPU power. And I'd need to again raise the question whether that attachment has any value as evidence whatsoever. 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. If the receiver of the MARF report doubts the identification, he'd certainly inquire with the sender and they both will agree how to produce something that both accept as reliable evidence. 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. Sorry again for the long sermon, and sorry for most likely breaking the threading of this discussion. _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
