Thanks for thinking about that one Thomas. Your suggestion should fit my
unique case. Look forward to seeing the changes in the code when you get
around to it. Still, before you make the change, as long as you're
changing code, wouldn't it be better to have custom filters? I don't think
the code change would be that bad.
Might this work?? This assumes that the possibility of the config file
being more complicated with the 4th parameter option is ok. I've never
really looked at this code section before, but wouldn't you just need to
change the code that says
$dd (the 4th optional parameter) would be set in the BlockReportBody sub,
changing
my ( $ad, $bd, $cd ) = split( /\=\>/o, $line );
$ad =~ s/\s//go;
$bd =~ s/\s//go;
$cd =~ s/\s*(\d+).*/$1/o;
to
my ( $ad, $bd, $cd, $dd ) = split( /\=\>/o, $line );
$ad =~ s/\s//go;
$bd =~ s/\s//go;
$cd =~ s/\s*(\d+).*/$1/o;
$dd =~ s/\s//go; (check that syntax, this assumes
that you can't have => in the filter)
And then in the getBlockReasons sub change
if ($address) {
next if ( $fl =~ m/(?:local\sor\swhitelisted|message\sok)/io
);
next if ( $fl =~ m/no\sbad\sattachments/io );
next if ( $fl =~ m/\[testmode\]/io );
next if ( $fl =~ m/\[local\]/io );
next if ( $fl =~ m/\[whitelisted\]/io );
next if ( $fl =~ m/\[noprocessing\]/io );
next if ( $fl =~ m/\[lowconfidence\]/io );
next if ( $fl =~ m/\[tagmode\]/io );
next if ( $fl =~ m/\[trap\]/io );
next if ( $fl =~ m/\[collect\]/io );
next if ( $fl =~ m/\[sl\]/io );
next if ( $fl =~ m/\[spamlover\]/io );
next if ( $fl =~ m/\[lowlimit\]/io );
next if ( $fl =~ m/\[warning\]/io );
next if ( $fl =~ /$BlockReportFilterRE/); (change this
line)
$fl =~ s/\sto:\s$to//i;
to include code something like
if ($dd) { (if $dd is set, use that as the filter, instead
next if ( $fl =~ /$dd/);
} else {
next if ( $fl =~ /$BlockReportFilterRE/);
}
You could go one step further too. If the custom filter starts with a +
then have it add to the blockreportfilter (by combining the dd string with
the blockreportfilterre).
I hope I've helped here, and that I'm not seeming demanding. I just had
this idea and thought it would be good to bounce it off the experts. If I'm
off base, I'd be interested in that feedback too. In that case, let's just
do it your initially proposed way, it'll do.
THANK YOU
On Wed, Jan 19, 2011 at 1:09 AM, Thomas Eckardt
<[email protected]>wrote:
> A 4th parameter will make the syntax more complicated like it is and it is
> not realy 'easy' implemented.
> But I think, this would be a possible solution for that problem:
>
> If there are no wildcards used in the definition line for the first
> address (this applys also to an email request sent by user) and this full
> address (for example: user\@mydomain\.com) is defined in the
> BlockReportFilter and this address is the only match for the filter - the
> filter will be ignored.
>
> so:
>
> [email protected]=>[email protected]=>1
>
> and a BlockReportRequest via EmailInterface from [email protected]
>
> will be processed, even if theuser\@ourdomain\.org is part of the
> BlockReportFilter (and no other filter matches)
>
> [email protected] will get his report - no other user will get report
> lines for this address.
>
> Thomas
>
>
>
>
>
> Von: K Post <[email protected]>
> An: ASSP development mailing list <[email protected]>
> Datum: 17.01.2011 16:48
> Betreff: [Assp-test] BlockReportFilter
>
>
>
>
> Is there any chance that we could get a 4th parameter added to the block
> report syntax that would add to the BlockReportFilter for each request
>
> Currently, I've got
> *@*=>[email protected]=>1 <*@*=%[email protected]=%3E1>
>
> This works great, and ignores that which I have in the BlockReportFilter.
>
> In this filter, I have a couple usernames that get thousands of bayesian
> spam messages rejected a day because these people published their
> addresses
> online (one of which I think on a porn site). The BlockReportFilter works
> wonderfully here, I don't get notices of any of their mail. Perfect.
>
> The problem is now one of these users wants their own daily report:
> [email protected]=>[email protected]=>1<[email protected]=%
> [email protected]=%3E1>
>
> But, nothing would because theuser is in BlockReportFilter.
>
> It would be outstanding if we could have something like:
>
> *@*=>[email protected]=>1=>theuser|theotheruser<*@*=%
> [email protected]=%3E1=%3Etheuser%7Ctheotheruser>
>
> [email protected]=>[email protected]=>1<[email protected]=%
> [email protected]=%3E1>
>
> That 4th parameter in line one would filter out theuser and theotheruser
> in
> addition to whatever's in the BlockReportFilter.
>
> Is this a reasonable addition?
>
> Thanks
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Assp-test mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/assp-test
>
>
>
>
> DISCLAIMER:
> *******************************************************
> This email and any files transmitted with it may be confidential, legally
> privileged and protected in law and are intended solely for the use of the
>
> individual to whom it is addressed.
> This email was multiple times scanned for viruses. There should be no
> known virus in this email!
> *******************************************************
>
>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Assp-test mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/assp-test
>
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Assp-test mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/assp-test
