Re: [Sqlgrey-users] Spammer alex@hotmail.com benefits from from_awl

[Michel B. <mi...@bo...>]

Le Jeudi 28 Avril 2005 17:08, Lionel Bouton a =E9crit :
>
> I was afraid we'll have to come to this. This will increase the load on
> the database slightly but I guess this won't be much of a problem. Now
> is the right time to add this table as I'm pushing database changes in
> 1.5.6 anyway.

I think we should be very careful when considering adding complexity. Addin=
g=20
complexity is always much of a problem, especially if not absolutely=20
needed ;-)

=46rom a performance standpoint, I feel that adding supplementary tables=20
(connect_awl ? forward_awl ? src_awl ?) would probably be bad. We would hav=
e=20
to perform queries against many more tables before deciding on the fate of =
=20
any email, and I'm rather sure that querying 6 tables, even if they are=20
smaller, will always be much slower than querying 3 tables, even if bigger.=
=20
After all, they are indexed...

> Seems good to me. People will be able to set the aggregation level at
> "1" to bypass the connect_awl (I just realised that I can make DB checks
> depend on the aggregation level, in this case we'll have the same DB load=
).

I think that if new tables appear in SQLgrey, their very usage must be=20
_optional_ (with a config parameter), so the admin has control not only on=
=20
"when to move entries from one table to another", but also on "wheter or no=
t=20
to use a given table at all".

I feel that such new tables, if implemented, should be off by default, and=
=20
could be activated only by users who think their use may be better in their=
=20
precise situation.

> A quick question though. I'm wondering if a "src_awl" would be of any
> use, could people with large sites check how many entries they have in
> domain_awl for the same src ?

I don't think this one would be very useful. domain_awl is very useful with=
 no=20
doubt, and it helps in much reducing the size of from_awl. I'm not sure tha=
t=20
adding a supplementary level would give a comparable gain that would be wor=
th=20
doing it.

The case in which this table could be useful would be the case of forwarder=
s=20
that can produce quite many entries from different originating domains in=20
from_awl. Maybe in this case having a src_awl would be of interest for them=
=2E=20
Then this table could be turned on ony at sites that see a significant amou=
nt=20
of such entries in their from_awl -- many ISPs will probably have some, but=
=20
many company servers won't need it as most enterprise servers don't receive=
=20
much mail from forwarding services.

It's worth noting that if such forwarders were using SRS, this need would=20
disappear as email coming from them would always show a MAIL FROM=20
@theirdomain.tld

> In other news, I'm planning to add blacklisting support. Probably after
> 1.6.0. The idea is to have a set of conditions where an IP will enter a
> blacklist

Again, be careful with complexity. I'm not sure that BLACKlisting is the=20
business of a GREYlisting tool...

=2D-=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E
Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel
Europ=E9en: http://www.200informaticiens.ras.eu.org