https://github.com/smtpd/qpsmtpd/pull/25
clamdscan: refactored, tests
moved 'use ClamAV::Client' into register and eval it (graceful failure)
refactored
added tests
when virus detected, decrement karma and s
NED;
> }
>
> + my @clamd_version = split(/\//, $clamd->version);
> +$self->{"_clamd"}->{'version'} = $clamd_version[0] || 'ClamAV';
> +
> my ( $path, $found ) = eval { $clamd->scan_path( $filename ) };
> if ($@) {
>
ts
@@ -198,6 +198,9 @@ sub hook_data_post {
return DECLINED;
}
+my @clamd_version = split(/\//, $clamd->version);
+$self->{"_clamd"}->{'version'} = $clamd_version[0] || 'ClamAV';
+
my ( $path, $found ) = eval { $clamd->scan_path(
at I'm referring to. And I think I was confused on the plugin as
well. Now that I think about it I think it was clamav plugin. If it didn't
receive the From_ header first then it didn't process it as a mail message
and pull the attachments apart correctly. If it didn't pull it
the
plugin as well. Now that I think about it I think it was clamav
plugin. If it didn't receive the From_ header first then it didn't
process it as a mail message and pull the attachments apart
correctly. If it didn't pull it apart correctly then it would
detect the virus th
s.
Are you sure you're not confusing this with SpamAssassin expecting
'From_' lines in /var/spool/mail-format mailboxes (see RFC-976)?
That is what I'm referring to. And I think I was confused on the plugin
as well. Now that I think about it I think it was clamav plugin
On 5. nov. 2009, at 19.55, Shad L. Lords wrote:
Ask Bjørn Hansen wrote:
On Nov 5, 2009, at 10:31, Shad L. Lords wrote:
This might not be the best place to fix this. The correct way
would be to fix header->add to always stick the headers at the top.
Sounds good to me. Would that mess up an
Shad L. Lords wrote:
Filippo Carletti wrote:
Without the details and without an inline patch, I can't apply this.
Sorry for having been terse.
I don't have the details, I've been told that message signing fails if
headers are added at bottom. This patch move them on top:
Headers should always
Shad L. Lords wrote:
>
> Ask Bjørn Hansen wrote:
> > On Nov 5, 2009, at 10:31, Shad L. Lords wrote:
> >
> >> This might not be the best place to fix this. The correct way
> >> would be to fix header->add to always stick the headers at the top.
> > Sounds good to me. Would that mess up anything
Robert Spier wrote:
Ask Bjørn Hansen wrote:
On Nov 5, 2009, at 10:31, Shad L. Lords wrote:
This might not be the best place to fix this. The correct way would
be to fix header->add to always stick the headers at the top.
Sounds good to me. Would that mess up anything else?
The conventio
Ask Bjørn Hansen wrote:
>
>
> On Nov 5, 2009, at 10:31, Shad L. Lords wrote:
>
> > This might not be the best place to fix this. The correct way would
> > be to fix header->add to always stick the headers at the top.
>
> Sounds good to me. Would that mess up anything else?
The convention,
Ask Bjørn Hansen wrote:
On Nov 5, 2009, at 10:31, Shad L. Lords wrote:
This might not be the best place to fix this. The correct way would
be to fix header->add to always stick the headers at the top.
Sounds good to me. Would that mess up anything else?
The only thing to be aware of is s
On Nov 5, 2009, at 10:31, Shad L. Lords wrote:
This might not be the best place to fix this. The correct way would
be to fix header->add to always stick the headers at the top.
Sounds good to me. Would that mess up anything else?
http://github.com/filippocarletti/qpsmtpd/blob/0c8c3fbd4a79d4ef3536ff90e3bb1595bbad0fe9/packaging/rpm/files/qpsmtpd-0.83-clamav-headers.patch
I don't know the details, but headers have to be at top or problems
with digitally signed mail arise.
--
Ciao,
Filippo
(http://github.com/filippocarletti/qpsmtpd/blob/0c8c3fbd4a79d4ef3536ff90e3bb1595bbad0fe9/packaging/rpm/files/qpsmtpd-0.83-clamd_conf.patch)
- $self->{_clamd_conf} ||= '/etc/clamd/conf'; # make sure something is set
+ $self->{_clamd_conf} ||= '/etc/clamd.conf'; # make sure something is set
--
C
On Wed, 17 Jun 2009, Filippo Carletti wrote:
http://bugs.contribs.org/show_bug.cgi?id=3098
Shad L. Lords
--- qpsmtpd-0.40/plugins/virus/clamav 2007-06-14 11:57:23.0 -0600
+++ mezzanine_patched_qpsmtpd-0.40/plugins/virus/clamav 2007-06-14
17:46:23.0 -0600
@@ -139,6
http://bugs.contribs.org/show_bug.cgi?id=3098
--- qpsmtpd-0.40/plugins/virus/clamav 2007-06-14 11:57:23.0 -0600
+++ mezzanine_patched_qpsmtpd-0.40/plugins/virus/clamav 2007-06-14
17:46:23.0 -0600
@@ -139,6 +139,9 @@
elsif (/back_compat/) {
$self->{_back_com
Applied to my tree as
commit 82198b83973f2371e4af18a05bf10403fafbce31
thank you for updating Changes too
Devin Carraway wrote:
>
> ---
> Changes |5 ++
> plugins/virus/clamdscan | 130
> +++
> 2 files changed, 91 insertions(+),
On Sun, Apr 19, 2009 at 09:24:54AM +0300, Imre Gergely wrote:
> Happy to report that the new clamdscan plugin works fine, and got in in
> Jaunty. If you wish I could try a NMU to Debian, too if you don't have
> the time.
No worries, I pushed 0.81 to Debian.
--
Devin \ aqua(at)devin.com, IRC:R
Devin Carraway wrote:
On Fri, Apr 17, 2009 at 12:10:06AM +0300, Imre Gergely wrote:
Uh, nice. Mind if I take that and test it a bit in Ubuntu? and if it's
working maybe we can squeeze it in in the new release next week. Though
it would be better if it came from the git, so if anybody could uplo
clamdscan virus-scanning plugin now requires the ClamAV::Client
+ perl module instead of the older, deprecated Clamd module (Devin Carraway)
+
0.81 - April 2, 2009
Close spamd socket after reading the result back (Jared Johnson)
diff --git a/plugins/virus/clamdscan b/plugins/virus/clamdscan
On Fri, Apr 17, 2009 at 12:10:06AM +0300, Imre Gergely wrote:
> Uh, nice. Mind if I take that and test it a bit in Ubuntu? and if it's
> working maybe we can squeeze it in in the new release next week. Though
> it would be better if it came from the git, so if anybody could upload
> it there bef
Devin Carraway wrote:
I updated clamdscan to use ClamAV::Client a while back, since the package was
about to be uninstallable with the old module dependency. Never actually got
it checked in, but it works fine. Here's a copy; I'll try to get it into git,
but anyone else with mo
On Thu, Apr 16, 2009 at 10:29:41PM +0300, Imre Gergely wrote:
> Do you have any plans on updating this Clamd.pm or maybe using
> clamd-client (http://search.cpan.org/dist/ClamAV-Client/) which is more
> up-to-date ?
I updated clamdscan to use ClamAV::Client a while back, since the pa
On Thu Apr 16, 2009 at 22:29:41 +0300, Imre Gergely wrote:
> I was just wondering who (if anybody) maintains the clamav/clamdscan
> plugin part of qpsmtpd ? I checked the last release (0.81) and it seems
> clamdscan is still using a very old Clamd perl module from CPAN.
To be h
Hi
I was just wondering who (if anybody) maintains the clamav/clamdscan
plugin part of qpsmtpd ? I checked the last release (0.81) and it seems
clamdscan is still using a very old Clamd perl module from CPAN.
When I try installing Clamd.pm with cpan on Ubuntu there are just too
many test
On Tue, 30 Sep 2008 17:03:36 -0700 (PDT), [EMAIL PROTECTED] wrote:
> When using the ClamAV plugin i realize that this is not the entire
> ClamAV application but how do I then keep the virus definitions for
> the plugin up to date? do I need to actually install the ClamAV
> applic
When using the ClamAV plugin i realize that this is not the entire
ClamAV application but how do I then keep the virus definitions for
the plugin up to date? do I need to actually install the ClamAV
application to use freshclam to update the virus definations and then
do i need to have the ClamAV
On 11/1/06 4:44 AM, "Ask Bjørn Hansen" <[EMAIL PROTECTED]> wrote:
>
> On Oct 24, 2006, at 8:43 AM, Peter Eisch wrote:
>
>> When the plugin was changed to use the qpsmtp transaction temp
>> file, this
>> broke the tmp_dir option. The patch below fixes this bug []
> [ ... http://beta.nntp.per
On Oct 24, 2006, at 8:43 AM, Peter Eisch wrote:
When the plugin was changed to use the qpsmtp transaction temp
file, this
broke the tmp_dir option. The patch below fixes this bug []
[ ... http://beta.nntp.perl.org/group/perl.qpsmtpd/5681 ...]
Hi Peter,
I don't understand how the patch
spool_dir() if path is not given? That way, the
clamav plugin could use the existing temp_file() code in another path
(tmp_dir) if needed.
John
When the plugin was changed to use the qpsmtp transaction temp file, this
broke the tmp_dir option. The patch below fixes this bug and allows the
files to be scanned to be written outside ~smtpd/tmp.
http://peter.boku.net/qpsmtpd/clamav.diff
When the plugin was changed to use the qpsmtp transaction temp file, this
broke the tmp_dir option. The patch below fixes this bug and allows the
files to be scanned to be written outside ~smtpd/tmp.
--- qpsmtpd-0.32/plugins/virus/clamav 2006-02-26 06:22:16.0 -0600
+++ qpsmtpd
>
>> Ok, attached is a patch that adds an additional parameter (clamd_conf)
>> to the clamav plugin.
>>
>> It is used as follows:
>>
>> virus/clamav clamscan_path=/usr/bin/clamdscan
>> clamd_conf=/etc/clamd.d/qpsmtpd.conf action=reject max_size=1048576
Ask Bjørn Hansen wrote:
>
> On Mar 15, 2006, at 5:21 PM, Robin Bowes wrote:
>
>> Ok, attached is a patch that adds an additional parameter (clamd_conf)
>> to the clamav plugin.
>>
>> It is used as follows:
>>
>> virus/clamav clamscan_path=
On Mar 15, 2006, at 5:21 PM, Robin Bowes wrote:
Ok, attached is a patch that adds an additional parameter (clamd_conf)
to the clamav plugin.
It is used as follows:
virus/clamav clamscan_path=/usr/bin/clamdscan
clamd_conf=/etc/clamd.d/qpsmtpd.conf action=reject max_size=1048576
I may even
it a pathc to fix that too.
R.
Robin Bowes said the following on 16/11/2005 20:45:
> Hi,
>
> I'm trying to get qpsmtpd + clamav setup on a new FC4 install.
>
> The clamav install has changed recently and I'm try to get to grips with
> how to get it working with qpsmtpd
> For aforementioned reasons, I'd like this to be configurable. I agree
> that DENYSOFT may be a better default.
Ask Ask said, make a patch.
It would be trivial to write a wrapper around the clamd plugin that
changed DENYSOFT to DECLINED. It shouldn't take more than 6 lines
using plugin inherita
Ask Bjørn Hansen wrote:
On Dec 16, 2005, at 6:33 AM, Matt Sergeant wrote:
On 16 Dec 2005, at 06:31, Filippo Carletti wrote:
If clamdscan cannot connect to clamd, clamdscan plugin returns
DECLINED and the virus is delivered to the user.
A safer option would be to return DENYSOFT when clamd
On Dec 16, 2005, at 7:58 AM, Juerd wrote:
For aforementioned reasons, I'd like this to be configurable. I agree
that DENYSOFT may be a better default.
Make a patch! :-)
--
http://www.askbjoernhansen.com/
On Dec 16, 2005, at 6:33 AM, Matt Sergeant wrote:
On 16 Dec 2005, at 06:31, Filippo Carletti wrote:
If clamdscan cannot connect to clamd, clamdscan plugin returns
DECLINED and the virus is delivered to the user.
A safer option would be to return DENYSOFT when clamd is not
reachable.
I
Matt Sergeant skribis 2005-12-16 9:33 (-0500):
> On 16 Dec 2005, at 06:31, Filippo Carletti wrote:
> >If clamdscan cannot connect to clamd, clamdscan plugin returns
> >DECLINED and the virus is delivered to the user.
> >A safer option would be to return DENYSOFT when clamd is not reachable.
> I a
Hello,
Matt Sergeant wrote:
On 16 Dec 2005, at 06:31, Filippo Carletti wrote:
If clamdscan cannot connect to clamd, clamdscan plugin returns
DECLINED and the virus is delivered to the user.
A safer option would be to return DENYSOFT when clamd is not reachable.
I agree with the patch. I'
On 16 Dec 2005, at 06:31, Filippo Carletti wrote:
If clamdscan cannot connect to clamd, clamdscan plugin returns
DECLINED and the virus is delivered to the user.
A safer option would be to return DENYSOFT when clamd is not reachable.
I agree with the patch. I'm sure some idiots will turn on
virus/worm which could
>> have been filtered.
>
> Have you actually asked them? We have.
Fabulous. Your users are much more adept than mine (for comparison). Most
my corporate customers do indeed have Symantec or something that's not
ClamAV for their scanning. Something that might be
Michael Holzt skribis 2005-12-16 13:20 (+0100):
> > I strongly believe that users should never solely *depend on* virus
> > filtering provided by the ISP, and must run a local virus scanner. This
> > is a security issue, not one of convenience.
> While you are right, this does not free the ISP from
> I strongly believe that users should never solely *depend on* virus
> filtering provided by the ISP, and must run a local virus scanner. This
> is a security issue, not one of convenience.
While you are right, this does not free the ISP from having to keep its
virus scanner running when offered
the key, and to
save the user bandwith. This is a convenience issue, not one of
security.
I strongly believe that users should never solely *depend on* virus
filtering provided by the ISP, and must run a local virus scanner. This
is a security issue, not one of convenience.
You should take into acc
If clamdscan cannot connect to clamd, clamdscan plugin returns DECLINED
and the virus is delivered to the user.
A safer option would be to return DENYSOFT when clamd is not reachable.
Proposed patch:
--- clamdscan.orig 2005-11-04 01:50:21.0 +0100
+++ clamdscan 2005-12-16 11:50:1
Robert Spier said the following on 23/11/2005 08:04:
>
>>"bikeshed" - not heard that expression before.
>
>
> http://producingoss.com/html-chunk/bikeshed-full.html
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING
Gotcha.
>>Anyway, like I said, I don't really m
> "bikeshed" - not heard that expression before.
http://producingoss.com/html-chunk/bikeshed-full.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING
> Anyway, like I said, I don't really mind one way or another. Call the
> new parameter "bananas" for all I car
On 11/22/05, Robin Bowes <[EMAIL PROTECTED]> wrote:
> Robert Spier said the following on 22/11/2005 15:47:
> >>>I don't like the 'clamd_conf' parameter name.
I would like clarity myself... So long as there aren't any variable
name collisions.
clamd_conf is straight-forward.
...
> If a man speak
Robert Spier said the following on 22/11/2005 15:47:
>>>I don't like the 'clamd_conf' parameter name. We already know it's
>>>for clamav. Just call it 'conf' ?
>>
>>If you follow the same reasoning, you might argue that 'clamsca
> > I don't like the 'clamd_conf' parameter name. We already know it's
> > for clamav. Just call it 'conf' ?
>
> If you follow the same reasoning, you might argue that 'clamscan_path'
> should be just 'path'.
Actually, I
Robert Spier said the following on 22/11/2005 01:05:
>>Anybody had chance to check this yet?
>
>
> I thought I sent a note.
>
> I don't like the 'clamd_conf' parameter name. We already know it's
> for clamav. Just call it 'conf' ?
> Anybody had chance to check this yet?
I thought I sent a note.
I don't like the 'clamd_conf' parameter name. We already know it's
for clamav. Just call it 'conf' ?
-R
Anybody had chance to check this yet?
R.
--
http://robinbowes.com
If a man speaks in a forest,
and his wife's not there,
is he still wrong?
Robin Bowes said the following on 16/11/2005 20:45:
> Hi,
>
> I'm trying to get qpsmtpd + clamav setup on a new FC4 install.
>
> The clamav install has changed recently and I'm try to get to grips with
> how to get it working with qpsmtpd.
>
> For example, it i
Hi,
I'm trying to get qpsmtpd + clamav setup on a new FC4 install.
The clamav install has changed recently and I'm try to get to grips with
how to get it working with qpsmtpd.
For example, it is recommended to set up individual clamd instances for
each application. This is good in
Ask Bjørn Hansen wrote:
Couldn't we set it up so if a plugin asks for a filename it's
automatically generated? (A filehandle could be made up from the
memory buffer).
Better still, if a plugin requests a filename, and the contents are all
in memory, write it out to disk at that point (and return
> Couldn't we set it up so if a plugin asks for a filename it's
> automatically generated? (A filehandle could be made up from the
> memory buffer).
I think thats what I said :)
> And/or the clamav plugin could support the stream option someone
> mentioned for the
generated? (A filehandle could be made up from the
memory buffer).
And/or the clamav plugin could support the stream option someone
mentioned for the small mails.
- ask
--
http://www.askbjoernhansen.com/
On Tue, 22 Mar 2005, Robert Spier wrote:
> So... pending reactivating "late writing" (i.e. always write the file
> for clamav) - we should probably set the minimum memory size low by
> default. 2k or something. Someone who needs the performance can
> increase it.
I th
maximum size). Either you configure your system
: to write all files to disk (by setting the config/memory_threshold to 0),
: or you decide what is the smallest size message that you want scanned and
: config/memory_threshold to that value instead.
:
: The "correct" fix is to make cl
/memory_threshold to 0), or you decide what is the smallest size
> message that you want scanned and config/memory_threshold to that
> value instead.
This is good and bad.
Looking at yesterday's virii,
the smallest thing that clamav caught was about 5.3k, but technically
its not a vi
Hello,
Tuesday, March 22, 2005, 1:00:45 PM, John Peacock wrote:
> The "correct" fix is to make clamav (and the other AV scanners which assumed
> the
> file would always be present) bleat a little less annoyingly (progably LOGWARN
> instead of LOGERROR).
IIRC, there was som
ry_threshold to that
value instead.
The "correct" fix is to make clamav (and the other AV scanners which assumed the
file would always be present) bleat a little less annoyingly (progably LOGWARN
instead of LOGERROR).
John
> The clamav plugin (and indeed all of the virus/* plugins in the core)
> all expect the full message to be written to the spool_dir. Matt's
> change above means that the very small messages are never spooled at
> all. I suspect that the clamav plugin should be altere
Matthew Harrell wrote:
but now I mostly see
7505 running plugin (data_post): virus::clamav
7505 virus::clamav plugin: didn't get a filename
The successes still happen but not nearly as often as the problems. I've
attached the plugins file below if I just happened to do something bad
Hi. I'm currently running the latest subversion checkout on a machine and
I've noticed that I seem to be getting a non-deterministic problem with
the clamav plugin. It used to work all the time with results like
7666 running plugin (data_post): virus::clamav
7666 virus::cla
John Peacock wrote:
+ $self->{_body_start} = $size;
Doh! Try
+ $self->transaction->{_body_start} = $size;
instead and the double headers go away. I'm going to go and recompile ClamAV
without my hack and see if it catches viruses again.
John
Hanno Hecker wrote:
--- Transaction.pm.bak Mon Feb 28 09:41:12 2005
+++ Transaction.pm Mon Feb 28 09:50:57 2005
@@ -70,6 +70,9 @@
$self->{_filename} = $self->temp_file();
$self->{_body_file} = IO::File->new($self->{_filename}, O_RDWR|O_CREAT,
0600)
or die "Could not open
Matt Sergeant wrote:
Actually I'm fine with this change. I was thinking of doing something
similar myself.
I'll test and if it looks good, I'll commit it. It will mean I can remove my
hack to libclamav and actually put that into production today.
John
On 28 Feb 2005, at 07:52, John Peacock wrote:
Hanno Hecker wrote:
On Sun, 27 Feb 2005 23:17:59 -0800
Hmm... no, just use everything else as before, feed the headers to the
queue and to other plugins from memory. Just change the position where
the body starts in the temp file.
Hmmm, that's an intere
Nick Leverton wrote:
On Sun, Feb 27, 2005 at 10:47:51AM -0800, Robert Spier wrote:
There's still a little work to do. Some plugins don't use the $self->log
method yet for instance, but still call warn() instead. Also some
still use Mail::Address instead of Qpsmtpd::Address. I am working on
the f
Hanno Hecker wrote:
On Sun, 27 Feb 2005 23:17:59 -0800
Hmm... no, just use everything else as before, feed the headers to the
queue and to other plugins from memory. Just change the position where
the body starts in the temp file.
Hmmm, that's an interesting idea, but it only works because of the c
On Sun, Feb 27, 2005 at 10:47:51AM -0800, Robert Spier wrote:
> > Ask, can we get a release now? Pretty please?
>
> +1, just do it.
There's still a little work to do. Some plugins don't use the $self->log
method yet for instance, but still call warn() instead. Also some
still use Mail::Address
k to
> > the beginning of the body (i.e.
> > length($transaction->header->as_string)+1). Then there's a full mail
> > in the temp file like clamav (and maybe other scanners) want it.
>
> Because you ought to rewrite it when the headers change (or it'd just
>
in the temp file like clamav (and maybe other
scanners) want it.
Because you ought to rewrite it when the headers change (or it'd just
be weird). Right? Or?
- ask
--
http://www.askbjoernhansen.com/
On Sun, 27 Feb 2005 08:29:42 -0500
John Peacock <[EMAIL PROTECTED]> wrote:
> Since I can't leave well enough alone, I have started to write a new
> clamav plugin along the following lines:
[...]
> 2) directly call clamd on the temporary files that qpsmtpd already
> has
&g
On 27 Feb 2005, at 13:15, Peter Eisch wrote:
One of the biggest problems will be what the AV scanners actually want
to see - do they want to scan filenames or do they want to scan a
bytestream, or what? I guess we can get around that using temporary
files either way though, but for high performance
> Ask, can we get a release now? Pretty please?
+1, just do it.
On 2/27/05 11:09 AM, "Matt Sergeant" <[EMAIL PROTECTED]> wrote:
> One of the biggest problems will be what the AV scanners actually want
> to see - do they want to scan filenames or do they want to scan a
> bytestream, or what? I guess we can get around that using temporary
> files either way thou
On 27 Feb 2005, at 10:29, John Peacock wrote:
What I've always wanted was a fast parser library (probably an XS
interface to a C library) which implemented the full BNF for both
RFC-2822 and RFC-1341 (and any subsidiary extensions in wide usage).
It seems like everyone writes their own parser;
Matt Sergeant wrote:
You know I have a perl module to do this on CPAN, right?
Doh! _Always_ check CPAN first... ;-)
The ultimate plan after the next release is for me to integrate my perl
mail parser, which will give us access to the body parts.
What I've always wanted was a fast parser library
On 27 Feb 2005, at 08:29, John Peacock wrote:
Since I can't leave well enough alone, I have started to write a new
clamav plugin along the following lines:
1) communicate directly with the clamd daemon (via TCP/IP or unix
domain socket), much like the spamassassin plugin does with spam
Since I can't leave well enough alone, I have started to write a new clamav
plugin along the following lines:
1) communicate directly with the clamd daemon (via TCP/IP or unix domain
socket), much like the spamassassin plugin does with spamd;
2) directly call clamd on the temporary files
Robin Bowes wrote:
Oh, and another thing. Did you stop and restart clamd after changing
the group??? For testing, I build clamav with --enable-debug, so I
get lots of useful information in the log file, including the UID/GID
it is executing as...
With help from Robin off list, I think we have
Robin Bowes wrote:
2005-02-24 20:51:27.080135500 4580 virus::clamav plugin: clamscan
results: /home/smtpd/tmp/qpsmtpd.clamav.4580.UDH0Nh: Access denied. ERROR
Did you try to manually copy a file into the spool directory and scan it from
the disk? You can also give the clamav user a shell
John Peacock wrote:
John Peacock wrote:
Robin Bowes wrote:
usermod -G smtpd clamav
Oh, and another thing. Did you stop and restart clamd after changing
the group??? For testing, I build clamav with --enable-debug, so I get
lots of useful information in the log file, including the UID/GID it
John Peacock wrote:
Robin Bowes wrote:
usermod -G smtpd clamav
chmod g+x /home/smtpd /home/smtpd/tmp
That should be:
chmod g+r /home/smtpd/tmp
OK, changed to that.
you should't /need/ to change the parent directory. clamd only needs
group _read_ access to the folder. For testing purposes,
John Peacock wrote:
Robin Bowes wrote:
usermod -G smtpd clamav
Oh, and another thing. Did you stop and restart clamd after changing
the group??? For testing, I build clamav with --enable-debug, so I get
lots of useful information in the log file, including the UID/GID it is
executing as
Robin Bowes wrote:
usermod -G smtpd clamav
chmod g+x /home/smtpd /home/smtpd/tmp
That should be:
chmod g+r /home/smtpd/tmp
you should't /need/ to change the parent directory. clamd only needs
group _read_ access to the folder. For testing purposes, copy a file
into that folder (prefer
John Peacock wrote:
Robin Bowes wrote:
OK, I've changed to "User smtpd" in /etc/clamd/conf.
It seems to work OK now.
Great! I improved the documentation and added a little code tweak which
should fix it so you can run with user clamav, as long as that user is a
member of the same
Robin Bowes wrote:
OK, I've changed to "User smtpd" in /etc/clamd/conf.
It seems to work OK now.
Great! I improved the documentation and added a little code tweak which
should fix it so you can run with user clamav, as long as that user is a
member of the same group as smtpd (and
John Peacock wrote:
> Robin Bowes wrote:
>
>> (whoops - to the list this time, witg debug level=9)
>>
>> Two things:
>>
>> 1. where is back_compat set?
>
>
> Like every other option, on the config/plugins line:
>
>> virus/clamav clamscan_path
Robin Bowes wrote:
(whoops - to the list this time, witg debug level=9)
Two things:
1. where is back_compat set?
Like every other option, on the config/plugins line:
virus/clamav clamscan_path=/usr/local/bin/clamdscan action=reject back_compat
Though if you are running clamd 0.83, you would just
John Peacock wrote:
Peter Eisch wrote:
The newer clamav (0.80 I think) changed the way some things are done.
Here's my line for how it's called which works quite nicely:
my $cmd = $self->{_clamscan_loc}." --stdout --disable-summary $filename
2>&1";
The -i has
Peter Eisch wrote:
The newer clamav (0.80 I think) changed the way some things are done.
Here's my line for how it's called which works quite nicely:
my $cmd = $self->{_clamscan_loc}." --stdout --disable-summary $filename
2>&1";
The -i has been deprecated.
FWIW, I
Michael Holzt wrote:
It seems that the invocation of clamav in the current plugin is using
deprecated parameters:
Feb 14 23:00:53 zeus qpsmtpd: WARNING: Ignoring option -i: please edit
clamd.conf instead.
Feb 14 23:00:53 zeus qpsmtpd: WARNING: Ignoring option --max-recursion: please
edit
1 - 100 of 143 matches
Mail list logo
