Mailing List Archive

Feature Request for clamav-milter
Hi,

we would like to have a flag in clamav-milter to turn on/off the recipient getting information about the virus. In our environment it is ok to bounce it back and to send it to the postmaster, but not to flood the normal user with e.g. hundreds of Sobig.F mails. For now we compile a specific version for our company.

If others would find it useful too, we could make the changes and send a diff.

E.g. clamav-milter -blor .....
where r is the recipient flag.

Regards
--
Helmut Koeberle Tel. : +49-(0)7541-585-1005
Service Director Fax : +49-(0)7541-585-2005

BYTEC GmbH mailto:helmut.koeberle@bytec.de
Hermann-Metzger-Str.7 http://www.bytec.de
88045 Friedrichshafen
Re: Feature Request for clamav-milter [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 27 Aug 2003 10:46 am, Helmut Koeberle wrote:
> Hi,
>
> we would like to have a flag in clamav-milter to turn on/off the recipient
> getting information about the virus.

Don't use the -b/--bounce flag when starting, and a bounce won't be sent.

- -Nigel

- --
Nigel Horne. Arranger, Composer, Conductor, Typesetter.
Owner of the brass band group of the Internet. ICQ#20252325
njh@bandsman.co.uk http://www.bandsman.co.uk/music.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/TICdOv/MqfDWaY8RAiA+AJ42Xn2EG67O1Gt/EZmUoq3RJinJAACghNot
ER1e8Bysu9VpikLyXyvj24w=
=gYX0
-----END PGP SIGNATURE-----
Re: Feature Request for clamav-milter [ In reply to ]
On Wed, 27 Aug 2003 10:57:47 +0100
Nigel Horne <njh@bandsman.co.uk> wrote:

> On Wednesday 27 Aug 2003 10:46 am, Helmut Koeberle wrote:
> > Hi,
> >
> > we would like to have a flag in clamav-milter to turn on/off the recipient
> > getting information about the virus.
>
> Don't use the -b/--bounce flag when starting, and a bounce won't be sent.
>
> - -Nigel
>

If we don't use the -b/--bounce flag, the sender of the message won't get a bounce. But the recipient and the postmaster will always get a mail.

Regards
--
Helmut Koeberle Tel. : +49-(0)7541-585-1005
Service Director Fax : +49-(0)7541-585-2005

BYTEC GmbH mailto:helmut.koeberle@bytec.de
Hermann-Metzger-Str.7 http://www.bytec.de
88045 Friedrichshafen
Re: Feature Request for clamav-milter [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 27 Aug 2003 12:18 pm, Helmut Koeberle wrote:
> On Wed, 27 Aug 2003 10:57:47 +0100

> If we don't use the -b/--bounce flag, the sender of the message won't get a
> bounce.

They should receive a bounce when sendmail generates the 550 error.

- -Nigel

- --
Nigel Horne. Arranger, Composer, Conductor, Typesetter.
Owner of the brass band group of the Internet. ICQ#20252325
njh@bandsman.co.uk http://www.bandsman.co.uk/music.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/TJkwOv/MqfDWaY8RAgSqAJ93LFTK4toaQtzCYbV6nPt5i5Qm4gCfZx7X
28yuXT272NTgjCufq8jJj5g=
=fT0S
-----END PGP SIGNATURE-----
Re: Feature Request for clamav-milter [ In reply to ]
On Wed, 27 Aug 2003 12:42:40 +0100
Nigel Horne <njh@bandsman.co.uk> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 27 Aug 2003 12:18 pm, Helmut Koeberle wrote:
> > On Wed, 27 Aug 2003 10:57:47 +0100
>
> > If we don't use the -b/--bounce flag, the sender of the message won't get a
> > bounce.
>
> They should receive a bounce when sendmail generates the 550 error.
>

That's OK.
But the postmaster and all "To:" get always the mail with "Subject: Virus intercepted". And we would like to turn on/off all the "To:" to get this message.

Regards
Helmut
Re: Feature Request for clamav-milter [ In reply to ]
On Wed, Aug 27, 2003 at 01:18:39PM +0200, Helmut Koeberle wrote:
> On Wed, 27 Aug 2003 10:57:47 +0100
> Nigel Horne <njh@bandsman.co.uk> wrote:
> > On Wednesday 27 Aug 2003 10:46 am, Helmut Koeberle wrote:
> > > we would like to have a flag in clamav-milter to turn on/off the recipient
> > > getting information about the virus.
> > Don't use the -b/--bounce flag when starting, and a bounce won't be sent.
> If we don't use the -b/--bounce flag, the sender of the message won't get a
> bounce. But the recipient and the postmaster will always get a mail.

I attach a patch which:
- adds a configuration option: SendmailPath /usr/sbin/sendmail
- adds a configuration option: SmfiSetreply TEMPFAIL
- corrects the above problem:
sending an e-mail to the virus sender should depend on bflag being turned on.
It does not make sense to send such e-mail anyway - it is just acting as a
virus ourselves. Much better solution is to not accept it, i.e bounce with
4xx code - see change above.
- I have problems with strerror_r() missing on OpenBSD 3.3 - my solution uses
strerror() instead and is a quick hack, probably also not correct.

I do not use clamav-milter any more, it is completely unreliable, at least on
OpenBSD. Also clamd crashes sometimes. Now I only use clamscan controlled by
MIMEDefand with SpamAssassin.

R.
--
Avec mes souvenirs/J'ai allumé le feu
Mes chagrins, mes plaisirs/Je n'ai plus besoin d'eux!

diff -ru clamav-20030720/clamav-milter/clamav-milter.c clamav-20030720rzm/clamav-milter/clamav-milter.c
--- clamav-20030720/clamav-milter/clamav-milter.c Fri Jul 18 15:20:01 2003
+++ clamav-20030720rzm/clamav-milter/clamav-milter.c Mon Jul 21 09:54:30 2003
@@ -636,7 +636,11 @@
if(rc != 0) {
char message[64], buf[64];

+#ifdef strerror_r
strerror_r(rc, buf, sizeof(buf));
+#else
+ strncpy(buf, strerror(rc), sizeof(buf));
+#endif
snprintf(message, sizeof(message), "pthread_cond_timedwait: %s", buf);
if(use_syslog)
syslog(LOG_ERR, message);
@@ -779,7 +783,11 @@
if(use_syslog) {
char buf[64];

+#ifdef strerror_r
strerror_r(rc, buf, sizeof(buf));
+#else
+ strncpy(buf, strerror(rc), sizeof(buf));
+#endif

syslog(LOG_ERR, "Failed to connect to port %d given by clamd: %s", port, buf);
}
@@ -886,6 +894,7 @@
{
int rc = SMFIS_CONTINUE;
char *ptr;
+ struct cfgstruct *cpt;
struct privdata *privdata = (struct privdata *)smfi_getpriv(ctx);
char mess[128];

@@ -967,17 +976,24 @@
puts(err);
#endif

- sendmail = popen("/usr/lib/sendmail -t", "w");
+ if((cpt = cfgopt(copt, "SendmailPath"))) {
+ char smbuf[256];
+ strncpy(smbuf, cpt->strarg, sizeof(smbuf) - 4);
+ strcat(smbuf, " -t");
+ sendmail = popen(smbuf, "w");
+ } else
+ sendmail = popen("/usr/sbin/sendmail -t", "w");
+
if(sendmail) {
fputs("From: MAILER-DAEMON\n", sendmail);
if(bflag) {
fprintf(sendmail, "To: %s\n", privdata->from);
fputs("Cc: postmaster\n", sendmail);
+ for(to = privdata->to; *to; to++)
+ fprintf(sendmail, "Cc: %s\n", *to);
} else
fputs("To: postmaster\n", sendmail);

- for(to = privdata->to; *to; to++)
- fprintf(sendmail, "Cc: %s\n", *to);
fputs("Subject: Virus intercepted\n\n", sendmail);

if(bflag)
@@ -993,8 +1009,13 @@
pclose(sendmail);
}

- smfi_setreply(ctx, "550", "5.7.1", "Virus detected by ClamAV - http://clamav.elektrapro.com");
- rc = SMFIS_REJECT;
+ if(strncasecmp(cpt = cfgopt(copt, "SendmailPath"), "TEMPFAIL", sizeof("TEMPFAIL")) != 0) {
+ smfi_setreply(ctx, "550", "5.7.1", "Virus detected by ClamAV - http://clamav.elektrapro.com");
+ rc = SMFIS_REJECT;
+ } else {
+ smfi_setreply(ctx, "451", "4.1.8", "Virus detected by ClamAV - http://clamav.elektrapro.com");
+ rc = SMFIS_TEMPFAIL;
+ }
free(err);
}
clamfi_cleanup(ctx);
diff -ru clamav-20030720/clamd/cfgfile.c clamav-20030720rzm/clamd/cfgfile.c
--- clamav-20030720/clamd/cfgfile.c Fri Jun 20 23:21:00 2003
+++ clamav-20030720rzm/clamd/cfgfile.c Mon Jul 21 09:51:54 2003
@@ -73,6 +73,8 @@
{"ClamukoExcludePath", OPT_STR},
{"ClamukoMaxFileSize", OPT_COMPSIZE},
{"ClamukoScanArchive", OPT_NOARG},
+ {"SendmailPath", OPT_STR},
+ {"SmfiSetreply", OPT_STR},
{0, 0}
};

diff -ru clamav-20030720/etc/clamav.conf clamav-20030720rzm/etc/clamav.conf
--- clamav-20030720/etc/clamav.conf Fri Jun 20 23:21:00 2003
+++ clamav-20030720rzm/etc/clamav.conf Mon Jul 21 09:51:54 2003
@@ -173,3 +173,8 @@
# (This option doesn't depend on ScanArchive, you can have archive support
# in clamd disabled).
ClamukoScanArchive
+
+# call sendmail as...
+SendmailPath /usr/sbin/sendmail
+# REJECT (default) or TEMPFAIL the virused e-mail
+SmfiSetreply TEMPFAIL
Re: Feature Request for clamav-milter [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 27 Aug 2003 11:15 pm, Rafal Maszkowski wrote:

> as a virus ourselves. Much better solution is to not accept it, i.e bounce
> with 4xx code - see change above.

4xx is a temp_fail which just causes an ISP store the job in the queue and keep resending it,
so you should continue to use the 5xx code.

> - I have problems with strerror_r() missing on OpenBSD 3.3 - my solution
> uses strerror() instead and is a quick hack, probably also not correct.

I have already fixed this for Solaris, you can use it - expect it in the next snapshot.

- -Nigel

- --
Nigel Horne. Arranger, Composer, Typesetter.
NJH Music, Barnsley, UK. ICQ#20252325
njh@despammed.com http://www.bandsman.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/TZz3hTUd3VwpF6IRApCNAJ0dqufwnl9IuEVejQUV53iNSwEvtQCeOhLn
Pd4qN32Pc3kbPZI0N+zzlCk=
=tlGm
-----END PGP SIGNATURE-----
Re: Feature Request for clamav-milter [ In reply to ]
> - adds a configuration option: SendmailPath /usr/sbin/sendmail

This is needed, but better still would be to change the code and deliver
the messages, by SMTP, directly into port 25, instead of calling
"sendmail" itself.

This would be a better solution because :-

1) by calling "sendmail" directly, these "I found a virus" messages are
by passing any other milters that are running on the box (e.g. we run a
mail logging milter and so these messages aren't getting logged).

2) by calling "sendmail" directly, sendmail will try and deliver the
message immediately, this can cause problems is the recipient's mailbox
is on a different mail server and there is a problem getting through to
that server - i.e. the milter will jam up - we have also seen this problem.

I have sent Nigel some suitable "smtp client" code, but I'm not sure if
he intends to make this change.

> 4xx code - see change above.

Any 4xx code means "temp file, please try again later". I'm sure you
don't really want this on an e-mail that you know has a virus in it ?

Although the option to change the return code would be nice. I change it
(in the source) from "550" to "553", that way I can tell fetchmail
(using its "antispam 553" option) to drop all messages that fail with
code 553. Otherwise my POP mailboxes get filled up with e-mail that
contain viruses that fetchmail can't collect because sendmail won't
accept them.


James
Re: Feature Request for clamav-milter [ In reply to ]
On Thu, Aug 28, 2003 at 07:11:03AM +0100, Nigel Horne wrote:
> On Wednesday 27 Aug 2003 11:15 pm, Rafal Maszkowski wrote:
> > as a virus ourselves. Much better solution is to not accept it, i.e bounce
> > with 4xx code - see change above.
> 4xx is a temp_fail which just causes an ISP store the job in the queue and keep resending it,
> so you should continue to use the 5xx code.

Disadvantages:
- more resources used
advantages:
- spam/virus source will have easier job with realizing that they have a
problem
- messages will wait and can be accepted later

I am convinced that for RBL filters advantages are bigger than disadvantages.
It may be different with viruses (I only recently started to believe they
really exist) but I wanted to experiment.

R.
--
Avec mes souvenirs/J'ai allumé le feu
Mes chagrins, mes plaisirs/Je n'ai plus besoin d'eux!
Re: Feature Request for clamav-milter [ In reply to ]
> advantages:
> - spam/virus source will have easier job with realizing that they have a
> problem

Viruses should be treated differently from spam.

> - messages will wait and can be accepted later

Surely not for a virus ? Personally I never want to accept a virus. I
can't think of any reason why I would ever want to.

> I am convinced that for RBL filters advantages are bigger than disadvanta=
> ges.
> It may be different with viruses

Too right. With a big enough signature, you shouldn't really experience
any false positives with a virus filter. A false positive on a virus is
really a bug - i.e. the signature needs to be fixed. Where as with a
spam filter, the odd false positive every now and then is part of the
process.

BTW: We used to use RBL, but gave up. Some are OK, some are quite poor.
We now use SpamAssassin with the "miltrassassin" milter. With the
addition of a few of our own rules, we're now catching about 98% of spam
with about 1 false positive every two weeks.

I hate perl and would have prefered not to use SpamAssassin, but it does
a really good job, esp with the Bayes enabled. We trained the bayes with
about 1000 spam & 1000 ham and that seems to have been enough to get a
reasonably level of accuracy.

> (I only recently started to believe they really exist)

:)) - So far we've had 2,500 SoBig-F - They exist, alright :-

http://www.messagelabs.com/viruseye/threats/



James