New clamav-milter problem ...

[Alexander Dalloz]

Am Fr, den 29.07.2005 schrieb C.Lee Taylor um 15:49:

>  >>	Starting clamav-milter: /usr/sbin/clamav-milter: --timeout must
>  >> not be given if --external is not given
> 
>  >	Add --timeout=0 to /etc/sysconfig/clamav-milter and it will
>  > work. It's not really a package problem, but it can be fixed by the
>  > package.  :-)
> 
> 	I tried 1 to 20 and no options, but it would not start ... I put the 
> packages back in place ...
> 
> 	I think this is a package problem, if something has changed, as I have 
> run into this problem that we lost mail after this update.  I'm sure I 
> have read that and upgrade should not break a system ...

I don't share the opinion that this change could have or should have
been covered by any mechanism inside the clamav-milter package. The
configuration files are set properly in spec with "%config(noreplace)".
For system critical updates I feel the user has to read about possible
changes before applying the update. How should the package know, how you
individually configured your clamav-milter to act? The fault is more an
upstream problem, as the Release Notes (horribly formatted this time) do
not mention the change in the milter behaviour. But there was short
discussion about "--external" and "--timeout" on the clamav mailing
list.

No, you normally lost no mail ("lost" in the meaning the mail disappear
to electronic nirvana == discarding). If there is a milter problem -
like a milter misconfiguration so it fails to start - there are 3 ways
the case is handled, depending how _you_ configured the milter to act:

1) F= -> accept mail anyway and proceed it
2) F=T -> answer the sending MTA with a temporary failure notice (DSN
4xx)
3) F=R -> reject the connection of foreign MTA with a DSN 5xx

I recommend using "F=T" for the clamav-milter (made good experiences
with that setting), the %description text in the clamav-milter rpm
speaks about "F=". "F=R" should be avoided as it depends on the sender
side whether it tries to send the mail message again or not. In any case
(at least if the sender MTA is RFC conform) the sender gets a mail
sending failure notice, so he knows that the mail did not reach the
recipient.

> 	Anyway, the right fix quickly sorts this problem out.
> 
> Thanks
> Mailed
> Lee

Alexander


-- 
 
1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) <alex at dalloz.de>
Key fingerprint = CD40 0A91 7814 C1E4 5940  8E0E 1FD5 C316 866E D681

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20050729/dac51ad4/attachment.sig>