I'm beginning to find that some of my clients who operate e-mail services are facing some very real ongoing operational issues with the likes of the Sircam worm/Trojan. At the moment the clients with the most pressing problem is a small cable-modem and dial-up operator. So far I've been advising all of my clients to treat these kinds of worms as valid e-mail and to simply help their end users, where possible, to eliminate it and deal with its impacts. I.e. if we're going to accept any e-mail from a given SMTP client to a given recipient then we accept it and deliver it without regard to its content. Now that we've ironed out tuning and configuration issues so that our systems can actually handle the increased SMTP load, especially that caused by Sircam in particular, we're finding that our users simply can't handle the load. There are far more users with constantly over-quota mailboxes (Sircam being particularly evil at sending large files). This is just as effective a denial of service for those users as any failure in the SMTP transport or mailbox access protocols would be. The users can still retrieve what e-mail they receive just fine, even most of the dial-up users, but there's so much of it now that most users, especially home users, don't keep up with the flow. Last night alone (eg. over an ~12hr period) we had over 1000 copies of the Sircam worm itself (with attached files, of course) dumped into the error queue because both the sender's and the recipient's mailboxes were over quota (and of course not all the senders were local either). I've given up counting the number of copies that have likely been delivered -- it's just way too many to comprehend. We're working under the general assumption that a large segment of these users would undoubtably become very angry if we simply filtered out all attachments, or even just those with filename extensions that losing software might try to "execute" (though in general that means anything that might include "macros" with the data too!), however I don't see any other manageable way to stop this kind of attack (other than eliminating or fixing all of the broken software that can be exploited in this way!). We're also working under the general assumption that a large segment of these users would become very angry if we dropped the maximum message size to a limit that at least Sircam and its ilk couldn't quickly overflow our average mailbox quotas. We've done this temporarily overnight and over weekends before we upgraded system capacities, and that did cause a lot of extra load on the support lines, but it stopped transmission of at least Sircam in its tracks (being it's always >135KB). How many of you who are also operators of e-mail services including mailboxes have implemented (for your customer mailboxes) such draconian indiscriminate attachment filters; and/or lowered your maximum allowed message size to something that would once upon a time have been considered overly generous, such as 100-150KB or so? How many of you have implemented more selective signature-based filtering, and of you how many are paying some (hopefully respected and trusted) third party to access regular updates of the signature list? How many of you consider signature based filtering to be bogus even though it would mostly mitigate the ongoing after-effects of something nasty like Sircam? How many of you have implemented per-mailbox restrictions so that end users must choose for themselves whether or not they'll ignore/drop/reject some of their e-mail? Please respond with any basic yes/no answers directly to me (if you can! ;-), and I'll post a followup summary by Tuesday or so if there's anything significant. My clients will generally be able to manage the expectations of their users better if they can point to other larger service providers who've taken equally, or more, draconian measures.... :-) ("I'm too scared to jump! Why don't the big boys jump first?" ;-) I've seen some de-fanged copies of Sircam that still matched my primitive signature check from Yahoo.... -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <woods@robohack.ca> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>