bugtraq - Re: RFC: virus handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <002201c3e6a7$fa738ef0$0f1fa8c0@squirrel>
Date: Thu, 29 Jan 2004 23:39:19 +0300
From: "Pavel Levshin" <flicker@...iinsky.ru>
To: "Thomas Zehetbauer" <thomasz@...tmaster.org>
Cc: <bugtraq@...urityfocus.com>
Subject: Re: RFC: virus handling

Hello, Thomas!
You wrote to <bugtraq@...urityfocus.com> on Wed, 28 Jan 2004 16:45:39 +0100:

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

Antivirus software MAY be configured to send notifications to local senders
and/or recipients, i.e. to domains which are handled by this server.
Antivirus filtering software SHOULD NOT be configured to send out
notifications to senders or recipients other than local, unless it
distinguishes between faked and real addresses.

I know many administrators who do not care of a few thousands antivirus
reports per day. No "warnings" are accepted. I would like to have some RFC
which disallows such behaviour, so I could send them all to RFC-ignorant BL.

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

It is unfair in relation to other languages. Many users do not read in
English, and Subject is supposed to be human-readable field. This
information could have standard form in other header.

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

It tends to be non-standard interface, which is very hard to find and use.

With best regards, Pavel Levshin.  E-mail: flicker@...iinsky.ru