We've talked about this before, but I'm bringing this up again as we've got
some crazy users and my hands are tied.
Summary:
I get a block report daily containing all blocked mails with some exceptions
filtered out using blockreportfilter (a username, BombSubjectRe and some
others). Works great
The user who has her email address posted all over the place and gets tons
of spam wants to see her blocked messages, but I've got her address in
blockreportfilter, since I don't want to see here 100's of blocks. ASSP was
changed to show the mails if the requesting address is contained in the
blockreportfilter. I believe this works fine.
New issue, she wants to see the BombSubjectRe rejections too!
So, I reask my original question:
Would it be possible to modify the syntax of the block report request line
to add a 4th parameter which is the filter? If nothing is specified then
the blcokreportfilter would be used, if something is specifies then use that
instead. (or get advanced and if the 4th parameter starts with a +, add
that to the existing blockreportfilter).
I think I've identified the places in the code that would need to be
changed, but I'm not an expert (see below).
I know this change would make a big difference to me, and I'd think others
once the functionality is discovered.
THANK YOU.
On Wed, Jan 19, 2011 at 5:25 PM, K Post <nntp.p...@gmail.com> wrote:
> 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 <
> thomas.ecka...@thockar.com> 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:
>>
>> theu...@ourdomain.org=>theu...@aourdomain.org=>1
>>
>> and a BlockReportRequest via EmailInterface from theu...@ourdomain.org
>>
>> will be processed, even if theuser\@ourdomain\.org is part of the
>> BlockReportFilter (and no other filter matches)
>>
>> theu...@ourdomain.org will get his report - no other user will get report
>> lines for this address.
>>
>> Thomas
>>
>>
>>
>>
>>
>> Von: K Post <nntp.p...@gmail.com>
>> An: ASSP development mailing list <assp-test@lists.sourceforge.net>
>> 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
>> *@*=>ken.p...@ourdomain.org=>1 <*@*=%3eken.p...@ourdomain.org=%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:
>> theu...@ourdomain.org=>theu...@aourdomain.org=>1<theu...@ourdomain.org=%
>> 3etheu...@aourdomain.org=%3E1>
>>
>> But, nothing would because theuser is in BlockReportFilter.
>>
>> It would be outstanding if we could have something like:
>>
>> *@*=>ken.p...@ourdomain.org=>1=>theuser|theotheruser<*@*=%
>> 3eken.p...@ourdomain.org=%3E1=%3Etheuser%7Ctheotheruser>
>>
>> theu...@ourdomain.org=>theu...@aourdomain.org=>1<theu...@ourdomain.org=%
>> 3etheu...@aourdomain.org=%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
>> Assp-test@lists.sourceforge.net
>> 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
>> Assp-test@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/assp-test
>>
>>
>
------------------------------------------------------------------------------
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
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
