[Avcheck] Problem (what else?)

Michael Tokarev mjt@tls.msk.ru
Mon, 27 Aug 2001 01:24:47 +0400


"Milan P. Stanic" wrote:
> 
> Hi!

Hello!

> I tried to set next programs:
> avcheck-0.3.tar.gz
> AvpDaemon Version 3.0 build 135.2 (trial version without key)
> Postfix release-20010228
> 
> I set it according to README.AVP and it works as Michael described, an
> until that it works.

Not quite understand this:  Is it works or not? ;)  Ok, I'm reading...

> But when I tried it with postfix (strictly following instructions from
> README.Postfix) I see in log that postfix relays mail to avcheck (like to a
> blackhole). It does not detects EICAR.TXT virus.
> 
> master.cf file
> -------------------
> # service type  private unpriv  chroot  wakeup  maxproc command + args
> #               (yes)   (yes)   (yes)   (never) (50)
> # ==========================================================================
> smtp     inet  n       -       n       -       -       smtpd
>     -o content_filter=avcheck
> pickup    fifo  n       n       -       60      1       pickup
> cleanup   unix  -       -       -       -       0       cleanup
> qmgr      fifo  n       -       -       300     1       qmgr
> rewrite   unix  -       -       -       -       -       trivial-rewrite
> bounce    unix  -       -       -       -       0       bounce
> defer     unix  -       -       -       -       0       bounce
> smtp      unix  -       -       -       -       -       smtp
> showq     unix  n       -       -       -       -       showq
> error     unix  -       -       -       -       -       error
> local     unix  -       n       n       -       -       local
> localhost:1025 inet n   -       n       -       -       smtpd
>     -o content_filter=
> avcheck   unix  -       n       n       -       -       pipe
>      user=avpc argv=/var/spool/avp/avcheck
>      -d /var/spool/avp/./tst -s AVP:/var/spool/avp/ctl/AvpCtl
>      -f ${sender} -S 127.0.0.1:1025 -- ${recipient}
> flush     unix  -       -       n       1000?   0       flush
> --------------------
> 
> ps au | grep Avp  gives:
> avpd 2013  0.0  0.1 4504   56 ?  S  21:04 0:00 /AvpDaemon -dl -f=/ctl /tst

This all looks ok.

> and excerpt from mail.log
> ----------------------------
> Aug 26 21:19:04 dl postfix/qmgr[2310]: 607E617BFD:
> from=<mps@rns-nis.co.yu>, size=597, nrcpt=1 (queue active)
> Aug 26 21:19:04 dl postfix/smtpd[2319]: disconnect from localhost[127.0.0.1]
> Aug 26 21:19:04 dl postfix/pipe[2315]: 641C217B3B: to=<mps@rns-nis.co.yu>,
> relay=avcheck, delay=38, status=sent (dl.rns-nis.co.yu)
> Aug 26 21:19:04 dl postfix/local[2321]: 607E617BFD: to=<mps@rns-nis.co.yu>,
> relay=local, delay=0, status=sent (mailbox)
> ----------------------------------------
> 
> I don't understand why postfix sends it to the "local" relay?

You posted somewhat incomplete log.  We see here two messages (actually
second one is reinjected back first) -- with ids 607E617BFD and
607E617BFD. 607E617BFD sent to local mailbox (where it should be
delivered? I suppose it is your local domain, is it?) -- but it was
already checked -- it was 641C217B3B before.  And 641C217B3B was
successefully "sent" to avcheck.  Order of lines is somewhat strange,
yes, but this is normal.

> I hacked avcheck to add syslog support and then I saw that AvpDaemon always
> answers with "uexpected" return code.

This is not good.  It is not necessary to hack avcheck at all: all
situations it can't handle it will log via postfix's mechanisms.  This
includes unexpected result codes and any other things.  If AvpDaemon
returns something strange, mail will be *deferred*, with message
describing that, and the same message will be logged by postfix's
pipe(8) agent.  From log above I guess (there is no real evidience)
that a message sent to mps@rns-nis.co.yu was successefully checked.
Now, when you modified avcheck, it want' work...  Strange, yes? ;)

> Should I say that I read mailing list archive for July and August and
> didn't found solution :(
> 
> Can anybody tell me what is wrong?

First, you said that your modified avcheck logs "unexpected return
code", but not provided what code it received.  I strongly suggest
you to use unmodified one -- all required info will be available
anyway (no, I don't want to say that you did some bad things with
code, but it was just unnecessary, and a *possible* source for other
errors).  And then post message it logs (or reason for deferred mail
message).

Next, it is better to actually test your configuration manually.
The procedure described inside avcheck tarball.

Regards,
 Michael.