handling Sircam and the like from the e-mail service operator's perspective...

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

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.... :slight_smile:

("I'm too scared to jump! Why don't the big boys jump first?" :wink:

I've seen some de-fanged copies of Sircam that still matched my
primitive signature check from Yahoo....