Mimedefang/logwatch interaction

I was wondering...  In the case of programs that run locally
and
then generate mail like "cron" and
"logwatch", what test can one
do within filter_begin() to decide to skip any processing on
the
rest of the message?

Should $ be part of Milter.macros.connect?

I was thinking that this would also be useful to avoid
recursion
from resend_message*().

-Philip

_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

On Mon, 2007-02-19 at 21:55 -0700, Philip Prindeville
wrote:
> I was wondering...  In the case of programs that run
locally and
> then generate mail like "cron" and
"logwatch", what test can one
> do within filter_begin() to decide to skip any
processing on the
> rest of the message?
> 
> Should $ be part of
Milter.macros.connect?
> 
> I was thinking that this would also be useful to avoid
recursion
> from resend_message*().
> 
> -Philip

One solution is to test the source ip address near the end
of
filter_multipart():

 if ($RelayAddr eq "127.0.0.1") {
 return action_accept();   # Or other stuff
 }    


-- 
PF <kernelpkts.ca>

_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

Hi all,

Just got this posting on the clamav devel list:

>Author: Renato Botelho
>Date: 2007-02-20 13:54 +100
>To: ClamAV Development
>Subject: [Clamav-devel] Multivolume rar files not
supported
>
>I saw multivolume rar isn't supported at this moment:
>
>xm.part01.rar: Not supported data format ERROR
>xm.part02.rar: Not supported data format ERROR
>xm.part03.rar: Not supported data format ERROR
>xm.part04.rar: Not supported data format ERROR

So I guess we need this fix this in all needed places
too ...

- run_virus_scanner($Features{'Virus:CLAMAV'} . "
--unzip --stdout --disable-summary --infected $path
2>&1");
+ run_virus_scanner($Features{'Virus:CLAMAV'} . "
--unzip --unrar --stdout --disable-summary --infected $path
2>&1");

Martin

Martin Blapp, <mbimp.ch> <mbrFreeBSD.org>
------------------------------------------------------------
------
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133
Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: <finger -l mbrfreebsd.org>
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22
D300 551E
------------------------------------------------------------
------

_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

Hi,
 
> Just got this posting on the clamav devel list:
> 
> >Author: Renato Botelho
> >Date: 2007-02-20 13:54 +100
> >To: ClamAV Development
> >Subject: [Clamav-devel] Multivolume rar files not
supported
> >
> >I saw multivolume rar isn't supported at this
moment:
> >
> >xm.part01.rar: Not supported data format ERROR
> >xm.part02.rar: Not supported data format ERROR
> >xm.part03.rar: Not supported data format ERROR
> >xm.part04.rar: Not supported data format ERROR
> 
> So I guess we need this fix this in all needed places
> too ...
> 
> - run_virus_scanner($Features{'Virus:CLAMAV'} . "
--unzip --stdout
> --disable-summary --infected $path 2>&1");
> + run_virus_scanner($Features{'Virus:CLAMAV'} . "
--unzip --unrar --stdout
> --disable-summary --infected $path 2>&1");

The option "--disable-summary" seems obsolete and
accepted at least by 
clamscan and clamdscan (0.90) only for backward
compatibility, so it would 
probably be better to use the option
"--no-summary" as the man page and 
the help page ("--help") propose.

Greetings

Jens

-- 
Dr. Jens Schleusener            T-Systems Solutions for
Research GmbH
Tel: +49 551 709-2493           Bunsenstr.10
Fax: +49 551 709-2169           D-37073 Goettingen
Jens.Schleusenert-systems.com  http://www.t-systems.com/
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

PF wrote:

>On Mon, 2007-02-19 at 21:55 -0700, Philip Prindeville
wrote:
>  
>
>>I was wondering...  In the case of programs that run
locally and
>>then generate mail like "cron" and
"logwatch", what test can one
>>do within filter_begin() to decide to skip any
processing on the
>>rest of the message?
>>
>>Should $ be part of
Milter.macros.connect?
>>
>>I was thinking that this would also be useful to
avoid recursion
>>from resend_message*().
>>
>>-Philip
>>    
>>
>
>One solution is to test the source ip address near the
end of
>filter_multipart():
>
> if ($RelayAddr eq "127.0.0.1") {
> return action_accept();   # Or other stuff
> }    
>
>  
>

Quoting the man page:

DISPOSITION
       mimedefang.pl examines each part of the MIME message 
is  examined  and
       chooses  a  disposition.   Unless otherwise
indicated, the dispositions
       should be called only from filter and not
filter_begin or filter_end.


so why call it from filter_multipart() and not
filter_begin() or
filter()?  Don't you want to accept the message atomically
and
stop further filtering of it?  I.e. short-circuit the
testing...

Can anyone think of any other methods to detect messages
queued
locally rather than accepted over a socket?  I.e. messages
read
from stdin?

Also, I tried to look at $SendmailMacros{'daemon_name'} but
that
never seems to be set.  Ditto for daemon_flags.

-Philip




_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang

On Tue, 2007-02-20 at 12:43 -0700, Philip Prindeville
wrote:
> Quoting the man page:
> 
> DISPOSITION
>        mimedefang.pl examines each part of the MIME
message  is  examined  and
>        chooses  a  disposition.   Unless otherwise
indicated, the dispositions
>        should be called only from filter and not
filter_begin or filter_end.
> 
> 
> so why call it from filter_multipart() and not
filter_begin() or
> filter()?  Don't you want to accept the message
atomically and
> stop further filtering of it?  I.e. short-circuit the
testing...

I think I'll move this code to filter()... it was randomly
added to the
rest of our customizations in filter_multipart(), and Just
Worked(tm).

> Can anyone think of any other methods to detect
messages queued
> locally rather than accepted over a socket?  I.e.
messages read
> from stdin?
> 
> Also, I tried to look at $SendmailMacros{'daemon_name'}
but that
> never seems to be set.  Ditto for daemon_flags.
> 
> -Philip

-- 
Charles Howes <chpkts.ca>
-- 
PF <kernelpkts.ca>

_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in
the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpengu
in.com
MIMEDefang mailing list MIMEDefanglists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mime
defang