North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Roeland Meyer
  • Date: Fri Aug 03 13:59:45 2001

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, August 03, 2001 9:32 AM

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

That last part is the problem. Why not filter on SirCam, at the mail host?
We had to do the LoveBug and it worked well. The issues were almost
identical, except that LoveBug was smaller.

> 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!).

Run virus scanners on all inbound mail. Yes, I know that burns CPU cycles
like mad. It does a pretty good job of thrashing DASD as well.

> 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).

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

Since you have a working signature, for SirCam, why not use it in