[Avcheck] messages to the listserv

Michael Tokarev mjt@tls.msk.ru
Thu, 30 Aug 2001 15:43:49 +0400


Piotr Klaban wrote:
> 
> Hi,
> 
> I have a question not related directly to the software,
> but to the design. What you do if the virus is directed
> to the LISTSERV or listserv list (like avcheck).
> 
> Example situation:

[notifying all list members about virus sent to list]

> It would be good if some recipients would not get
> the virus warning - a type of map db needed.

This is exactly why I split av(p)check into two pieces,
executable that runs fast and a (shell) script that
deals with infected mails and can be changed easily.
I wan't call `infected' examples "official *parts*"
of a package -- them all are examples only.  For now,
there are no examples on how to customize "virus
handling" on per-recipient or per-sender basis (with
one small exception: handling mail from MAILER-DAEMON@* --
current `infected' will not notify such "senders").

I'm afraid I can't write a handler that suit all needs --
the whole set of various `infected' handlers are more
like a "do it yourself" kit that should be modified
for particular needs.  Well, more different examples
can be provided...

BTW, this problem isn't unique to LISTSERV, it is
a generic problem.

> There is also the second problem - possible looping (not tested):
> -----------------------------------------------------------------
> 
> The letter with virus is bounced to the sender
> with whole virus inside. If there is
> a virus checker at the sender's server,
> the letter can be banned and loop.

Yes and no.  There will be a loop when one side is misconfigured.
Current examples uses empty return address (aka mailer-daemon)
in envelope from.  So *all* notifications from avcheck should
not bounce back to it -- unless there is a broken software
somewhere that will use header from address for bounces.
Another questions is -- what envelope sender used by other
side when bouncing avcheck's notification -- if that address
is again empty, then avcheck will not send a note back.

> I changed the source of "infected" program (from avcheck-0.3)
> for my internal use and there are no virus content
> send to anyone, but only the headers (AVP can
> save the infected and suspicious mails to tmp/infected
> and tmp/suspicious folders). I do not want to argue
> if the sender should receive the whole message or only
> the headers.

I use avcheck with content_inspector, not content_filter.
And with inspector, there is currently no way to turn
off standard postfix bounces -- in fact, our senders
receives *two* bounces for every infected mail -- one
standard from postfix and another from avcheck (with
only headers) that explains (in Russian, see infected.ex2)
what to do and why them received bounce.  This is ugly
like a hell, this is doubling a traffic etc etc, but
most of our customers are non-technicians that even
can't read English... :(   Just another situation...

>    Maybe there is another possibility
> - maybe the sender address of virus warning should be
> always empty (MAIL FROM:<>). BTW - I have had some virus
> warings (on the linux with old avcheck) send to
> the sender called MAILER_DAEMON ;-).

See above, and see Ralf's HOWTO that mentioned this.
I know many antiviruses saves messages to some
temp folder and uses "incident id" referred to
that temp copy in notifications.  This scheme shurely
will work, but has some drawbacks (or incomplete).

For example, DrWeb's script sends notification to
sender in a form, something like:

  Mail syste received infected message from you.
  Your message was saved in temp folder with
  id=12345.  If you want to get your message
  back, write a mail to <virusmaster@ourdomain.com>
  asking returning saved mail with id=12345.

Now imagine what should do a <virusmaster> (aka
local postmaster) with requests sent in response? ;)

Alternative is to refer to some www page that will
show original message -- but what to do with authorization?
It is ok for local users, but for remote?  Well, there
are possible schemes (like using some random id in
url that will expire etc -- like e.g. many list managers
uses to confirm subscriptions), but this requires some
more "coding", and not only in avcheck's side.

Anyway, per-sender or per-recipient customization needed
in this case too.

Next, saved messages should expire (trivial to do but
still needs to be done).


> And here is a suggestion
> ------------------------
> 
> I have two servers, that uses avcheck to check messages
> in our network for now. Unfortunately many mails are checked
> for viruses twice.

I used a trick here to avoid this -- I defined special transports
on both servers, like:

                 server A:            server B:
transport_map    B  smtp:[B]:1025     A  smtp:[A]:1025

and have 1025 port defined in master.cf the same as for reinjecting
mails from avcheck (blocking access to this port for others).

Ugly, but works well.

The key term here is "trust relationship", i.e. I set up servers
that I trust will not send virus mails.

Another variant for this will be to modify postfix to *conditionally*
include content_{filter,inspector} record based on e.g. client IP
or the like, but I don't think it is worth an effort.

>          Should not be there something as
> PGP signature or something alse that can be checked
> by the second server - it can know then that the viruses
> were checked already.

I thought about this before -- it looks too complicated.
Anyway, you will need to add and sign keys of various
servers that you trust (just like setting transport maps
entries), and there is no standard header for this
defined (e.g. amavis will not add it (at least for now),
kavkeeper will not add it and so on) -- so this method,
while not standartized, will not help alot.

> But ... I do not know if for small letters the PGP
> verify phase can be more CPU intensive than AV check.
> Then PGP signature (it is only additional header
> in pgpverify in usenet news, not the additional text body)
> could be checked only for mails with attachments etc.

This is in my todo list -- parsing a message in avcheck.
There is no need to call antivirus for plain text mails
without "begin ddd xxx" lines.  Now, avcheck is very simple
program, adding a mime parser will made it like amavis... ;)
Well, some little parsing may help anyway (to see if particular
regexp exists in headers or body), but not very mach --
most of mails today sent from ms outgluck or the like
configured by default to send multipart/alternate mails
in html and text formats -- so this mail should be checked
anyway.  So I don't know if that really needed to include
a parser at this stage.

Regards,
 Michael.