Re: [Sqlgrey-users] warn_if_reject to populate the db

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

Le Dimanche 26 Juin 2005 15:01, /dev/rob0 a =E9crit :
>
> I've got it going now, was rather easy. I started in test mode, with
> "warn_if_reject check_policy_service inet:127.0.0.1:2501" in main.cf.
> Will this really populate my database? Since nothing is being rejected,
> it looks like non-returning triplets. Nothing is autowhitelisted until
> the first appearance after the greylist period, correct?

You're right, it won't populate much. Only senders that will come several=
=20
times (because they send several messages to the same recipient) in a 24h=
=20
period will end in the AWL tables.

But I'm not sure that this "warn_if_reject" temporary strategy is of any=20
interest, unless you operate a _very_ high volume server. You can as well=
=20
start from scratch with an empty DB and let it populate by itself. Rememe=
ber=20
that only the 1st mail from any given sender will be delayed...

> 1. localhost:2501 vs. Unix socket
> Wouldn't a socket be slightly faster than TCP?

Probably, but works only if on the same machine. TCP is more general, so =
to=20
use sockets, Lionel would need to implement both methods. Given the littl=
e=20
amount of data transferred between Postfix and sqlgrey for a given=20
connection, using sockets would probably make a difference only on very h=
igh=20
volume system.

> 2. Running under control of master(8)
> That would be convenient, start and stop with Postfix; are there other
> benefits? Why the standalone choice?

Running under the control of master would be interesting to me as well.

> 3. Database population commands
> I'm totally lost with SQL (hence the poor choice of mysql), can someone
> help with the manual commands I'd use to add to the database?

Reading the fine MySQL doc would probably help with the basic SQL command=
s,=20
but you'd better let the DB populate by itself.

BTW, why state that MySQL is a poor choice ?

> 4. Database population scripts
> Is there something I could run against user's maildirs which would add
> entries to the AWL? If not should I commission such a project from my
> private farm of Perl coders[2]; I mean, would there be interest?

I don't think there's any interest in trying to artificially populate the=
 DB.=20
Just let it run ;-)

> 6. dyn_fqdn.regexp
> That's quite an expression.

;-)

> I didn't figure the whole thing out, but I=20
> did look for a string "\.res\." which is commonly used for dynamic
> space, e.g., *.res.rr.com. (residential customers.) Perhaps the second
> dot should be any non-alpha character (-, _, ., digit), and to be safe
> there should be at least 2 domain segments following and at least one
> segment preceding (implied by the leading dot.)

I don't pretend that the regexp is perfect, it's only heuristic, but it w=
ould=20
be interesting adding your modification only if you find samples of exist=
ing=20
hostnames that don't get properly classified. (i.e. your example may alre=
ady=20
get classified corresctly if the last byte of the IP address is part of t=
he=20
name) The more things you add in the regexp, the longer it will take to=20
process, and the higher chances it could collide with other non-dynamic n=
ames=20
in an undesired manner.

But feel free to experiment with your own copy and suggest improvements t=
hat=20
show useful...

> 7. Coordination with infidels
> Greylisters, regardless of their MTA and choice of implementation, are
> all in this together. We're all going to run into the same issues with
> stupid and/or big providers which have problems getting real mail
> through greylisting.

So far, I don't have any problem running SQLgrey, and the problematic ser=
vers=20
IPs/names can be reported to this list for inclusion in the provided (and=
=20
auto-updating) whitelists...

> 8. Beyond grey
> This is a biggie which probably warrants its own thread. This is all
> about spam abatement. What about integrating other antispam strategies
> under the roof of the same policy service? Yes, this belongs in its own
> thread. I'll write more of my thoughts about that later.

I think about it the Unix way. I prefer to use several distinct tools of =
my=20
choice, each one doing _one_ thing and doing it well. I wouldn't like any=
=20
bigger system that would integrate different methods, I personally prefer=
=20
doing my own cooking.

Postfix can call several "policy services" without any problem...

> Thanks, Lionel, this looks good so far. I went live with a small but
> heavily-spammed domain yesterday evening, and no spam has been seen
> there since. (The sqlgrey is last in a long list of restrictions with
> numerous RBL checks.)

My 2 cents: Put SQLgrey _before_ RBLs. You'll save external network calls=
 so=20
your system will run faster, and you'll save unnecessary load onto the RB=
L=20
servers as well...

> [2] a/k/a /dev/wife. I might need some help with #3 above to get her
>     started, but OTOH she has some PostgreSQL knowledge.

About /dev/wife, please see below...

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

[amant@blonde etc]$ su
Password: zyva
[root@blonde etc]# modprobe mariage
WARNING: Module "mariage.o" not under GPL license. Inserting "mariage.o"
         will taint the kernel.
Module "mariage.o" inserted with 18712 warnings. Please check system log.
blonde kernel: Discovering new devices...
blonde kernel: Found device: belle_mere
blonde kernel: Activated device: belle_mere. Have a nice day.
blonde kernel: Found device tree for /dev/mari
devfsd: Creating symlink /dev/coiffeur =3D> /dev/mari/portefeuille
devfsd: Creating symlink /dev/estheticienne =3D> /dev/mari/portefeuille
devfsd: Creating symlink /dev/robes =3D> /dev/mari/portefeuille
blonde kernel: Activated device: uterus. Please wait until completion.
blonde kernel: Found child device: lardon_#1
blonde kernel: Found child device: lardon_#2
devfsd: Device nibards owner changed to lardon_#2, group lardons,
        mode 660
blonde kernel: Removing inactive device: foufoune
devfsd: Creating symlink /dev/foufoune =3D> /dev/migraine
devfsd: Modifying symlink /dev/brain =3D> /dev/random
WARNING: Superuser privileges removed from user: mari
WARNING: You will be logged out. Have a nice day, anyway try to.
[mari@blonde etc]$ ls /sex
Permission denied
[mari@blonde etc]$ rmmod mariage
bash: rmmod: command not found
[mari@blonde etc]$ /sbin/rmmod mariage
rmmod: Operation not permitted
[mari@blonde etc]$ su
Password: zyva
su: Incorrect password.
[mari@blonde etc]$ damned je suis refait !
bash: damned: command not found
[mari@blonde etc]$ /sbin/insmod maitresse
maitresse: Operation not permitted

-+- GSM in topless - Bien configurer son mariage -+-