Thanks Mark,
For clarifying my thoughts on this. Script was working but I
forgot to look the obvious way when I thought scripts was'nt
working - permissions, permissions, permissions -
Script did'nt have write permission to the cataloque where files were created.
Regards
Peter
-----Oprindelig meddelelse-----
Fra: Mark Martinec [mailto:mark.martinec+ama...@ijs.si]
Sendt: 21. januar 2011 20:25
Til: amavis-user@lists.sourceforge.net
Emne: Re: [AMaViS-user] Handling outgoing SPAM
Peter,
> I am trying to find a solution to a setup, where I want to make sure that
> infected machines on the inner side (MYNETWORKS) is'nt able to push
> out big amounts of SPAM.
>
> I have full control on SPAM coming from outside but want to have a mechanism
> that can detect this situation primarily to avoid being blacklistet.
>
> This is a University Enviroment and it is not a solution to discard outgoing
> SPAM
> primarily because just one positive could stop that application a scientist
> has sent
> to apply for funds to his research project and this they normally do in the
> last minute.
>
> Normally outgoing SPAM is'nt a problem but when a server/client gets hacked
> this
> becomes a serious problem.
>
> So I thought I could do following:
> $policy_bank{'MYNETS'} = { # mail originating from @mynetworks
> originating => 1, # is true in MYNETS by deflt, but let's make it explicit
> terminate_dsn_on_notify_success => 0,
> spam_kill_level_maps => 6.9,
> spam_subject_tag2_maps => ["***SPAM ORIGINATED FROM LOCAL*** "],
> virus_admin_maps => ["maspsr\@sdu.dk"], # alert of internal viruses
> warnbadhsender => 1, # warn local senders about their broken MUA
> final_spam_destiny => D_DISCARD,
> spam_quarantine_method =>
> 'pipe:argv=/usr/local/etc/mxgw/scripts/spambox.pl spam-%b ${sender}' ,
> spam_quarantine_cutoff_level_maps => undef,
> };
warnbadhsender => 1 is not useful against internal infected machines
turned into spam zombies. These typically emit spam under fake sender
addresses. Turning on admin notifications for MYNETS is far more useful
(assuming someone is actually monitoring that mailbox, at least
in counts):
virus_admin_maps => ["alert\@$mydomain"],
spam_admin_maps => ["alert\@$mydomain"],
> and this way handle the mail in this script: spambox.pl.
> When I look at the logs the scripts is called. I can't quite figure how.
> I would expect the mail passed on STDIN
Correct, a mail message is passed on stdin to the spawned process.
The ${sender} in args is replaced by the actual envelope sender,
although the %b has no particular meaning here and is left unchanged.
Here is a test program that can be used in place of spambox.pl:
#!/usr/bin/perl -T
use strict;
use re 'taint';
no warnings 'uninitialized';
open(OUT, ">>/tmp/0.dat") or die "Error opening: $!";
printf OUT ("args: %d - %s\n", scalar(@ARGV), join(", ",@ARGV));
while (<STDIN>) {
print OUT "GOT: $_";
}
print OUT "END\n";
close(OUT) or die "Error closing: $!";
> but somehow nothing happens. The logs below.
>
> Jan 18 13:52:13 mxgw1.sdu.dk amavis[31773]: (31773-01) DO_QUARANTINE,
> pipe:argv=/usr/local/etc/mxgw/scripts/spambox.pl spam-%b ${sender},
<r...@hansen.its.sdu.dk> -> spam-quarantine, spam-quarantine
> Jan 18 13:52:13 mxgw1.sdu.dk amavis[31773]: (31773-01) SEND via PIPE:
> <r...@hansen.its.sdu.dk> -> <spam-quarantine>,<spam-quarantine>
> Jan 18 13:52:13 mxgw1.sdu.dk amavis[31773]: (31773-01) mail_via_pipe running
> command: /usr/local/etc/mxgw/scripts/spambox.pl spam-%b r...@hansen.its.sdu.dk
> Jan 18 13:52:13 mxgw1.sdu.dk amavis[31773]: (31773-01) run_command_consumer:
> [31785] /usr/local/etc/mxgw/scripts/spambox.pl spam-%b r...@hansen.its.sdu.dk
>/dev/null 2>/dev/null
> Jan 18 13:52:13 mxgw1.sdu.dk amavis[31773]: (31773-01) write_header: 0,
> IO::File=GLOB(0x6e05b28)
> Jan 18 13:52:13 mxgw1.sdu.dk amavis[31785]: (31773-01) open_on_specific_fd:
> target fd0 closing, to become < &=14
> Jan 18 13:52:13 mxgw1.sdu.dk amavis[31785]: (31773-01) open_on_specific_fd:
> target fd0 dup2 from fd14 < &=14
> Jan 18 13:52:13 mxgw1.sdu.dk amavis[31785]: (31773-01) open_on_specific_fd:
> source fd14 closed
> Jan 18 13:52:13 mxgw1.sdu.dk amavis[31785]: (31773-01) open_on_specific_fd:
> target fd1 closing, to become > /dev/null
> Jan 18 13:52:13 mxgw1.sdu.dk amavis[31785]: (31773-01) open_on_specific_fd:
> target fd2 closing, to become > /dev/null
> Jan 18 13:52:14 mxgw1.sdu.dk amavis[31773]: (31773-01) mail_via_pipe
> /usr/local/etc/mxgw/scripts/spambox.pl, exit 0, 250 2.6.0 Ok
> Jan 18 13:52:14 mxgw1.sdu.dk amavis[31773]: (31773-01) one_response_for_all
> <r...@hansen.its.sdu.dk>: success, r=0,b=0,d=0, ndn_needed=0, '250 2.6.0 Ok,
id=31773-01'
> Jan 18 13:52:14 mxgw1.sdu.dk amavis[31773]: (31773-01) DO_QUARANTINE done
Don't know, it looks fine, the exit status returned by your spambox.pl is 0 (a
success).
There may be some unhandled error condition your program comes across.
Make sure it can access resources (like opening a file) as user vscan/amavisd.
Unfortunately its stderr is directed to /dev/null, so it may be hard to debug.
Try running it first by hand as user vscan and see if that works.
You may also change a call to run_command_consumer() from within
sub mail_via_pipe, and change its first argument ($stdout_to) to
some fixed filename, writable to vscan, and see if that gets
more informative.
> This is probably not the right way to deal with this problem.
> Can you please correct me on this or just point me
> into the direction to find the correct solution.
If the spambox.pl takes care of alering, then your approach may be fine.
Monitoring admin alerts achieves a similar goal.
One additional suggestion is to turn on Postfix rate limiting
for mail submission. Something like:
# resource limits - see anvil(8)
anvil_rate_time_unit = 600
smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 500
smtpd_client_message_rate_limit = 500
smtpd_client_recipient_rate_limit = 500
smtpd_client_event_limit_exceptions = 127.0.0.0/8 [::1]/128 ...
Mark
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
Please visit http://www.ijs.si/software/amavisd/ regularly
For administrativa requests please send email to rainer at openantivirus dot
org
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
Please visit http://www.ijs.si/software/amavisd/ regularly
For administrativa requests please send email to rainer at openantivirus dot
org
