On 25/Jul/11 00:53, Murray S. Kucherawy wrote: > 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.
This is already provided for, albeit not recommended. > 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. Err... wouldn't it be safer to prohibit people from sending viruses in the first place? > 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. Sounds good. "Reported-Malware" better conveys that the "virus" Feedback-Type is somewhat of a misnomer (see below). > 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. "Scanner" may better distinguish it from "User-Agent". Is it useful? (It can often be inferred from the virus names it reports.) I'd recommend it be fully optional, anyway, especially its update version :-/ > 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). Sticking to established albeit wrong names seems to be more orthodox than correcting them (remember the "Referer".) For a partial justification, let me note that worms and other malware are often detected by products commonly called "anti-virus". > 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. ARIN's announcement was posted on Mon, 18 July 2011 https://www.arin.net/announcements/2011/20110718.html RIPE hasn't yet said so, AFAIK. I don't know whether they will recommend ARF, but the fact that they strive to avoid rate-limit for that data suggests that they intend it to be for automated use, the same as _report.domain. So, yes, there seems to be some overlapping here. > 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. Good point. Ideally, ISPs could set abuse@ISP in the RIR's DB, and then count and redirect complaints to the relevant postmasters. It would be great if they also checked that complaints are actually acted upon. More likely, ISPs will just set POCs as clients tell them to, including /dev/null. Reporters can also compare WHOIS data with _report.domain, and send to whomever they like. IMHO, our docs should * mention RIRs and registrars WHOIS databases, * cover comparison considerations, and * insist that end users should report to their postmasters if at all possible. jm2c _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
