Re: RFC: virus handling
There is one standardized feature for virus and other bounce messages, (which
isn't mentioned in the original proposal), which I believe would really help:
A bounce should *always* include a MIME attachment of type
message/rfc822-headers which contains the full headers from the original
mail. This makes it relatively easy to check on the receiving side if the
original "Received: from" headers are valid, and simply drop bounces that
relate to messages that were originally sent with forged headers.
In terms of the general traffic levels that email virus filters generate, it
strikes me as moronic that anti-virus vendors do not implement a flag to
indicate whether a particular virus signature relates to a virus that is
likely to have come from a forged address, (in which case the mail should
simply be dropped, or stored for administrative review). <rant> Given that
they can't even manage that much, it's little surprise that they don't
understand the value in standardizing the bounce or reading a few RFCs.
</rant>
John Fitzgibbon.
On Wednesday 28 January 2004 07:45 am, Thomas Zehetbauer wrote:
> Looking at the current outbreak of the Mydoom.A worm I would like to
> share and discuss some thoughts:
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
> 1.2.2.) Virus Information
> The message should always include the name of the virus found or the
> test conducted (eg. forbidden file type).
>
> 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.
>
> 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.
>
> 2.) Non Delivery Notifications
> It seems that this worm is trying to avoid people getting treacherous
> non delivery notifications by using obviously faked but otherwise
> plausible e-mail addresses. This may cause double bounce messages or
> even message loops at badly configured sites.
>
> 2.1.) Avoid
> Virus filters should therefore be designed and implemented before
> checking the legitimacy of the intended recipient. This would also avoid
> helping the virus spread by bouncing it to a previously unaffected third
> party.
>
> 3.) ISPs
> It is worth to note that once again primarily individuals using a
> commercial provider have been affected by this worm.
>
> 3.1.) Notification
> As these people do mostly not run a SMTP server on their system it is
> unfortunately almost impossible to contact them when only knowing their
> IP address.
>
> 3.1.1.) Abuse Role Account
> Providers should provide an adequately stuffed abuse role account to
> allow the affected users beeing notified. To ease efficiency messages
> sent there should include the IP address, the exact time and date of the
> incident and the name of the virus on the subject line.
>
> 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@xxxxxxxxxxxx) 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.
>
> 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.
>
> Regards
> Tom