Re: RFC: virus handling

[Craig Morrison <craig () fishpalace org>]

And since I missed the Reply all.. For the list at large:

Thomas Zehetbauer wrote:

> Looking at the current outbreak of the Mydoom.A worm I would like to
> share and discuss some thoughts:

Glad to oblige..

> 1.) Virus Detected Notifications
> After filtering out the messages generated by the worm itself there
> remain a lot of messages generated by automated e-mail scanning
> solutions.

Shut off notifications.

> 1.1.) Configuration
> Unless the virus scanner provides special handling for worms and virii
> which knowingly use a faked sender address it should not send out
> notification messages unless the administrator has been warned that
> these notification messages may not reach the intended recipient and has
> still enabled this feature.

Shut off notifications.

> 1.2.) Format
> These messages cannot be easily filtered because they come in many
> different formats and do often not contain any useful information at
> all.

Shut off notifications.

> 1.2.1.) Standardization
> To allow filtering of these messages they should always carry the text
> 'possible virus found' in the subject optionally extended by the name of
> the virus or the test conducted (eg. heuristics).

Shut off notifications.

> 1.2.2.) Virus Information
> The message should always include the name of the virus found or the
> test conducted (eg. forbidden file type).

Shut off notifications. (Is there a trend appearing here?)

> 1.1.2.) Original Message
> The notification should never include the original message sent as
> otherwise it may send the worm/virus to a previously unaffected third
> party or re-infect a system that has already been cleaned.

Shut off notifications.

> 1.2.) Notification
> Regarding wasted time and storage capacity the false notifications sent
> out to innocent third parties by many systems are already causing more
> damage than the actual worm or virus. Given the current situation of
> many unaware or ignorant administrators everyone capable to do so should
> tell these people to fix their badly configured e-mail scanners.

Fire the admins..

Shut off notifications.

> 2.) Non Delivery Notifications

[much snippage]

Just about everything you have stated to this point can be covered by
shutting off notifications. As we have all seen over the past 3 years,
the notifications are useless and only serve to clog up bandwidth and
bring systems down.

> 3.1.2.) e-mail Alias and Web-Interface
> Additionally providers should provide e-mail aliases for the IP
> addresses of their customers (eg. customer at 127.0.0.1 can be reached
> via 127.0.0.1 () provider com) or a web interface with similiar
> functionality. The latter should be provided when dynamically assigned
> IP addresses are used for which an additional timestamp is required.

Excuse me?

I need to hear more about how this could be implemented and _maintained_
easily.

> 3.2.) Disconnect
> Providers should grant their customers some grace period to clean their
> infection and should thereafter be disconnected entirely or filtered
> based on protocol (eg. outgoing SMTP) or content (eg. transparent
> smarthost with virus scanner) until they testify that they have cleaned
> their system.

Any admin worth their salt is already doing this. If they aren't, they
need to find a new job.

> Regards
> Tom


--
Craig Morrison

http://www.mtsprofessional.com/
  A Win32 email server that works for You.