[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: virus handling
You wrote to <bugtraq@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx) 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@xxxxxxxxxxxx