OK, I guess I'll brave the storm of incompetently-run "out of the office" autoresponders and boneheaded C/R systems yet again. > 1.It is clear that as notifications are today, they are *mostly* > plain and simple spam. I agree with you. They are unsolicited, bulk, and email; ergo, spam. > Why do I believe that? > Since they usually contain information regarding getting a brand new > AV, but not about the virus or how to get cleaned. Adding information about the virus or how to disinfect would not help one bit. I do not have the virus, I cannot have the virus, I have no use save academic interest in details about the virus or about how people who have it might get rid of it; adding such information to the already-useless notifications I get will make them no more useful (and in fact less so because it will make them bigger). Also, it will not make them any less unsolicited, any less bulk, or any less email; they will still be spam. > 2. In a broader view, notifications ARE currently the problem rather > than a solution. Agreed. > The AV industry is built on reaction rather than prevention. Adding > new signatures is still the #1 tool in the fight against malware. [...] > If backbones filtered the top-10 current outbreaks, I suggest you talk to a backbone network engineer before making such suggestions. The backbones do not handle email as such; they handle packets that, taken together, make up email sessions (and many other things). The difference is immense. In particular, the backbones cannot associate one packet in an SMTP session with the next in the same session; while in theory they could be made to, in practice it would be far, far too resource-intensive, especially given how close to the line they are running as it is. > with non-intrusive means such as for example running MD5 checksum > checks against attachments, Can't be done. Some of the reasons why: - Knitting packets together into TCP data streams (necessary to identify attachment boundaries) demands orders of magnitude more resources (both cycles to inspect the packets and memory to store them) than are available. - Knitting packets together into TCP data streams demands that all packets making up the stream follow the same path. Anyone who thinks the core routing tables are that stable needs a reality check. (Granted, 50% success would be better than nothing, but not much, especially in view of the cost in the form of half-completed state sitting around waiting for packets that went another way.) - MD5 is a relatively expensive checksum to compute, thus even further overdrawing the cpu-cycle budget; since many MD5s will have to be in progress at any one time, this also exacerbates the memory lack. - Slight randomizations in virus payload have been a standard tactic for years; if this is done, it will simply become universal (since then each viral payload will have a different MD5). - Even if somehow all the above went away, by the time the attachment ends and the MD5 is computed, it's too late; it's already been sent. All that can be done at that point is to disrupt the SMTP connection, such as by RSTing it rather than sending the closing dot, and even that will simply make the sender retry repeatedly, thus replicating the waste many times. (If it's a smarthost's MTA, that is. It will stop viral SMTP engines that don't bother retrying, but again, such measures will simply make smarthost-using viruses even mroe ubiquitous than they already are.) - People won't stand for it. I know I certainly wouldn't. > True, it may cause a cry of "the government spies on us, but with the > current economic troubles outbreaks cause, can we really use that > excuse anymore? Doesn't the police regulate speeding? Roads are a shared public resource. The backbones you are making so free with are privately owned. If you want the various national governments (yes, plural) to expropriate them all as a first step, you should at least be upfront about it - and you will get a _lot_ more resistance to your plan. > There are enough solutions out there for spam and malware, they are > mostly not being implemented for different political and commercial > reasons. Sure. Many of the solutions I've seen are akin to killing off a tumor by cremating the patient: they'll work but are excessive. The others won't work. There may be something that avoids both those problems, but I've yet to see it. > 4. As far as the IP-ADDRESS@isp goes, it IS a good idea, but not a > very practical one in my opinion. Allow me to explain why. You've explained why it's not practical. How about explaining why you think it's a good idea? (I think it's a terrible idea; it has endless downsides and, as far as I can see, no real upside at all - suppose I get hit from 12.34.56.78. So I send to 12.34.56.78@...where? If I'm going to look it up in ARIN/RIPE/etc, I might as well just use the abuse contact listed there anyway. Furthermore, if it's a dynamic dialup, it could easily have been used by a dozen different users during the time between the offense occuring and my sending a report; which one gets it? What if my computer's clock is 47 minutes wrong?) > [...] the real problem which is ISP's not doing much about ABUSE > REPORTS or USER SECURITY. Right. But what can be done about it? You mention "the law"; what do you think "the law" (as if there were a single "the law" on the net) should, or even could, dictate? > I don't understand why the biggest problems of the Internet should be > commercialized and thus become static, rather than solved. Because nobody's managed to solve them yet. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B