<co-chair> Barry and I received the following feedback about the ARF base document from someone who does not wish to join the mailing list and does not wish to participate in the working group directly. We've agreed to forward these comments to the working group for its consideration, but also agree that one person's concerns (especially when that person doesn't want to do the work of advancing them through the working group) are not sufficient to spin up an update effort.
So, if the working group wants to do something with some or all of this material, great, we can talk about starting that effort. If not, then that's fine too. Some of this stuff also applies to a couple of our open documents, so the various authors (JD mostly, I think) could consider them there. </co-chair> <participant> As far as the base stuff goes, some of this stuff looks reasonable, but none of it looks critical to me. Thus, if there's no critical mass to create an RFC5965bis effort, they could just be logged as errata or something like that so they fall in the "deal with this someday" bucket. </participant> <feedback> I am just working through the most recent version to update our filters to use the latest proposal, and am in the process of also converting our virus reporting to the ARF. In that process I found a number of concerns with ARF and aborted that conversion: 1) I consider it extremely rude and dangerous to transmit malware across the Internet even in the form of an ARF, apart from the fact that virus filters at the ISP level and/or the recipient's level may well catch the malware, create a report of that malware (thus creating a loop), and at the same time firewall the offending IP (our mail server). Hence the proposal to return the complete message in case of reporting a virus is a very bad idea. Instead, only the header of the offending message should be returned. The proposal should therefore prohibit the return of the full message in case of feedback type virus and instead require the return of the mail header only. This also requires to change the content type of the last ARF section from message/RFC822 to text/RFC822-Headers (or whatever else is deemed suitable). 2) Because with just returning the header the recipient is no longer able to determine which malware was being sent, an according reporting field is needed in the ARF. I'd propose to use: Reported-Description: or Reported-Malware: the first of which can be used not only for virus reporting, but should be required for feedback type virus and should contain the full name of the virus as reported by the virus scanner. 3) Because the virus names vary from each virus scanner tool, we also need to identify the virus scanner reporting the malware. The name of the virus scanner should therefore be included as: Reporting-Utility: Required for feedback type virus, optional for other feedback types. 4) The Source IP address should be mandatory for feedback type virus. 5) I'd phase out the feedback type virus in favour of feedback type malware (which is the same, just broadening the use to include worms, downloaders, .. which are not virus type), alternatively introduce malware as equivalent to virus (keeping both feedback types permanently alive). I feed virus would be too limiting for that type of reporting (virus by definition is self re- producing, while worms, downloaders etc. are not self re-producing and therefore by definition are not virusses). That concludes my virus/malware-related comment to your excellent tool. A suggestion may be whether the keyword virus should not be phased out in favour of the word malware to open the abuse report for more generic purpose (although virus generally is now being understood like malware anyway). Another comment regarding the _report.domain DNS TXT entry ... In principle that seems to be a reasonable idea, however, there's a duplicate created that way. Right now abuse addresses are mandatory for the IP address entries in ARIN, RIPE, ... The problem there, the databases are not really consistent, but consistent enough that parsing of the entries for abuse addresses is possible indeed. I'd rather leave the (legally binding, because that is part of the contract between ARIN/RIPE/... for IP address assignment) abuse reporting facility with the IP assigning entities and create a standard there in either their databases (whois) or via a global abuse address server under control of one entity (ARIN or whoever, supplied and updated only by ARIN and IP assigning authorities delegated by ARIN) with the entry of the source IP address and return of the abuse mail address (could be name server, http, whois, ...) There is actually a huge problem with the _report.domain ... The name server may not be under control of the ISP, subdomains may well be added by the client. Hence a malicious client could redirect the abuse reporting to his own mail address that way and as such completely disable abuse reporting. Hence I consider the proposal for _report.domain TXT field to publish the abuse mail address as serious risk and detrimental to the purpose of ARF. I'd therefore recommend to drop that proposal in favour of what I lined out above, most likely and easiest by creating consistency across the whois databases (introduce a specific abuse report field there, which is currently missing and abuse e-mail addresses are only published in the comment fields!). To give you an idea: our spam- and virus reporting utilities fetch the abuse address of the ISP via whois indeed and do all the necessary parsing of the whois entries via the source IP address. </feedback> _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
