>Also, I run three ASSP servers for redundancy, so manually removing items
from cache is not fun.
Use a shared or better replicated database for the caches and lists
between your three assp. Use the sync feature to synchronize important
configuration values and files beween your installations.
>Enhancement Suggestion
This enhancement will be added to the code (2.0.2_2.0.16), but it will
not be functional per default nor will it be documented.
Michael - to enable it, do the following (based on 2.0.2_2.0.15)
add the following line as line 189
.....
our $AddURIS2MyHeader;
.....
add the following lines in sub URIBLok between '&ThreadYield();' and
'&sigoff(__LINE__);' (line 18451)
.....
&ThreadYield();
$this->{myheader} .= 'X-Assp-Detected-URI: '
. join(', ',
map{$_ . '('.(($domains{$_} >= 1000000)
? int($domains{$_}/1000000)
: $domains{$_}).')'}
keys %domains)
if $AddURIS2MyHeader;
&sigoff(__LINE__);
.....
In the folder 'lib' create a module 'CorrectASSPcfg.pm' (case sensitive
name!!!), with the following content (modify 'sub set', if it already
exists).
This module will set the variable 'AddURIS2MyHeader' to 1 - the module is
loaded and sub 'set' is called (if found) at every startup of assp.pl .
--------------------------------------------
#!/usr/local/bin/perl
package CorrectASSPcfg;
use strict qw(vars subs);
sub set {
$main::AddURIS2MyHeader = 1;
&main::mlog(0,"info: URI-list will be added to the mail header"); #
this line is optional
}
1;
--------------------------------------------
These changes will finaly produce the following header line(s)
X-Assp-Detected-URI: uri1(x), uri2(y) ...
uriN(z) ....
.....
where x,y, and z is the count of the URI (how many times it was found). If
needed, the header-line-breaking is done automaticaly by assp at a later
state.
Notice that assp will MIME encode any content of these headerlines in
'quoted printable - UTF-8' that contains any character '>hex(7E)' (which
should normaly not possible in an URI - but who knows).
To prevent a too long mail header - set 'URIBLmaxdomains' to a value : 31
> value > 0
Thomas
Von: "Michael Thomas" <[email protected]>
An: "'ASSP development mailing list'"
<[email protected]>
Datum: 02.01.2011 20:26
Betreff: Re: [Assp-test] Enhancement Suggestion
Fritz,
I think you miss the point of my usage. The URI in the URIBL cache is
obviously a list of URI. They are obviously tagged as good or bad at the
time they were inspected.
Which of the "good" URI should actually be "bad" and should be added to a
URIBL? How do I prove that?
Remember, I run my own DNSBL and URIBL.
So, because the URIBL cache includes "good" URI, "for my usage", I have
the
URIBL cache disabled and consider the URIBL cache to be broken. Any length
of time that makes the URIBL cache useful, causes "good" URI to be "good"
until they are aged out of the cache.
Consider this sequence of events:
1. Spam message delivery is attempted
1a. Message contains URI, but URI are not listed in any URIBL
1b. Message origin IP is not listed in any DNSBL
2. Message passes through ASSP
2a. Message URI added to cache as "good"
2b. Message IP added to cache as "good"
3. Message is inspected manually and found to be spam
3a. One or more URI added to local URIBL
3b. IP address added to DNSBL
4. Over several hours, 100 more spam like #1 arrive for delivery
4a. Maybe origin IP is same as #1. If so, it is "good" in cache. Never
checks DNSBL, where it is bad.
4b. URI is good in cache. Never checks URIBL, where it is bad.
5. I have not checked if expiration is updated by appearance in a message
or
if expiration is set on entry into cache and never updated. Worst case for
"good" message is that the cache expiration is updated by appearance in a
message.
So, if one uses only public DNSBL and URIBL, having "good" URI and IP in
cache might be "okay". But "good" items in cache still defeat new
listings.
If you run your own DNSBL and/or URIBL, having "good" in cache is a
hindrance to being responsive.
Also, I run three ASSP servers for redundancy, so manually removing items
from cache is not fun.
What might be useful, is using cache, but having a "Preferred DNSBL" and a
"Preferred URIBL", which are checked before the cache, where "bad" result
would override a "good" in the cache.
Michael Thomas
Mathbox
978-687-3300
Toll Free: 1-877-MATHBOX (1-877-628-4269)
> -----Original Message-----
> From: Fritz Borgstedt [mailto:[email protected]]
> Sent: Sunday, January 02, 2011 12:54 PM
> To: ASSP development mailing list
> Subject: Re: [Assp-test] Enhancement Suggestion
>
>
> ASSP development mailing list <[email protected]>
> schreibt:
> >By adding the code I added, my goal was too get a clean list of the
> >URI in
> >the message, so that they could be added to a URIBL. So, I would
> >certainly
> >want the "good" and "bad" URI listed.
>
>
> The URIBL Cache of ASSP is already collecting good and bad URIs.
> Set URIBLCacheInterval to 14 days to get a long list.
> Set URIBLCacheIntervalMiss even longer.
> The cache contains two different records:
>
> Status 1: Hit
> 112.213.88.2121292016835 1 multi.surbl.org<-127.0.0.36
> Status 2: Miss
> 100automobile.de1293958887 2
>
> --------------------------------------------------------------
> ----------------
> Learn how Oracle Real Application Clusters (RAC) One Node
> allows customers
> to consolidate database storage, standardize their database
> environment, and,
> should the need arise, upgrade to a full multi-node Oracle
> RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Assp-test mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/assp-test
>
>
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment,
and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
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!
*******************************************************
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Assp-test mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/assp-test
