[eside-ghost] Postfix y sus cuotas...

[Iker Sagasti Markina]

Aupi Egoitz,

Ehhhh no te ahogas al releer lo que escribes ??? :-))) joder que 
capacidad... me da que tu le das mucho al (a)msn :-DDDD

Ten cuidado que se te va a caducar la sesión del squirrel ;-)))

egoitz en ramattack.net escribió:

> jejeje muchisimas gracias tio, si para benchmarkear pop uso rabid y creo
> que  para smtp para inyectar correo como un jarto usaba el postal (creo
> que era, he estado mirando y solo tengo la estructura de los ficheros de
> texto plano a los que mandaba correo, y del pop estrutura para usuario y
> clave sin mas xDDD como lo hice hace tiempo y me curre hace tiempo mi
> sistema qmail y me asegure que rulaba bien pues... se me han olvidado los
> detalles del bechmarker)... y mi sistema era... levantaba un courier-pop y
> un qmail sin escaneos pero con todas las funcionalidades del servidor smtp
> que recibe... (de esta forma probaba el sistema sin escaneos)... utilice
> me acuerdo un PIV para el correo y otro PIV para lanzar los smtp y
> recoger... corría en la misma máquina (casi fijo que postal) y rabid para
> pop3... y nada uno inyectaba y el otro recogía y borraba... es muy facil
> usarlos creo que para el postal era postal conexiones
> archivodedireccioneslocales mailamandar(en texto plano) y en rabid rabid
> conexiones archivodedireccionesyclave y nada te metes en ese bucle hasta
> que rebiente lo que sea... pones maquinas potentes en el servidor a
> benchmarkear y el cliente loco jejej y nada le dejas ahi mirando claro de
> vez en cuando si sube la cola... si sube el load average... si sube bien
> de ram y se va a swap (y la llena bien) y si llega el procesador al 100%
> (darle vidilla al load average... vaya ke si le di xDDD)  y tal... jejeje
> en este benchmark pude ver tambien que compilar el kernel y ponerle que
> use PIV en vez de Pentium MMX creo que usa por defecto cualquier kernel
> 686 no ayuda a penas... (en los benchmark suelo optimizar el kernel por
> las super cargas k le meto... jeje y solo he notado diferencia
> significativa cuando tienes servidores tomcat un 10% aprox mas de
> rendimiento, lo de mas correo o ftp contra mysql cuotas y de todo... no se
> nota mucho la verdad...)

Joder vaya review así en un correo!!! Como mola ese knowhow!! ya.. lo 
del kernel siempre he pensado que gentoo style era tan friki como 
innecesario para mi cuerpo serrano :-PP


> Y nada en cuanto al correo pues el tema de qmail es que todo tiene que ser
> currado por ti... por ejemplo ahora tengo hecho un servidor de analisis de
> correo que lo que hace es acepta correo en el 25 y si es dominio local o
> de relay nuestro lo manda al puerto 900 de localhost (solo escucha ahi)
> donde escucha un qmail que pasa antivirus y antispam, sin embargo si es
> saliente lo manda al 800 y ahi solo pasa antivirus (paso de mandar sin
> analizar para fuera, que las rbl andan calientes... y tanto que andan xDDD
> y así pues aunque sea nadie manda virus)... por supuesto lo que no se
> entrega se borra y fuera nada de rejects que luego los bounces son los
> bounces...

Ummm... 3 smtpd??? umm... has mirado mailscanner?? te permite hacer lo 
que dices sin 3 smtpd!!

Puedes definir un comportamiento para los entrantes (spam + virus) y 
otro totalmente distinto para los salientes (virus).

De todas maneras *CREO* que tu punto de partida es erróneo:

Partimos de dos premisas: virus y gusanos.
* El objetivo de los virus es infectar la máquina residente, y el de los 
gusanos es propagarse e infectar distintas máquinas.
* Los gusanos a menudo infectan máquinas para crear zombies para enviar 
spam. Esos gusanos rara vez van a utilizar tu qmail, sino que van a 
llevar su propio motor smtp embebido.

Partiendo de esas premisas:
* Si analizas virus en el 25 saliente solo vas a detener ficheros 
infectados (hoy en día muy pocos). En este caso NO entras en una RBL.

* Si analizas spam en el 25 saliente puedes detectar gusanos en tu red 
que pueden meter tu IP en una RBL.

Para evitar esto es mucho más útil  configurar bien el puerto 25 
saliente en el firewall (ay esos puertos salientes siempre permitidos!!) 
y dejar solo a tu máquina de outbounding ;-))


> claro hablas con los de qmail y dicen no... el simscan cojo(piii) si pero
> metele una carga wapa de analisisis que la memoria va hasta atapuerca
> ejejeje por eso prepare esto... (no lo he puesto todavia en produccion, ya
> os contaré jejeje), nada el before queue no vale si tienes carga...

Tengo serias dudas sobre Amavisd-new-tragamemoria, si es o no tan tragón 
como simscan :-))

> y aquí es donde empieza mi curiosidad por postfix digo... joe si pongo
> todo con apt (me kito los lios de los flags de compilación y tal) menos

apt-rulz, mola minimizar el error humano. Me fió más de LaMont Jones 
(empaquetador debian de postfix) y de la comunidad que de mi mismo :-)))

> maildrop que por defecto debian no soporta courier-authlib extensions en
> etch pero bueno hago cojo su source y añado el soporte al rules... (con lo

¿?¿?¿?¿?

miri:/etc/MailScanner# maildrop -v
maildrop 2.0.2 Copyright 1998-2005 Double Precision, Inc.
GDBM extensions enabled.
Courier Authentication Library extension enabled.
Maildir quota extension enabled.
This program is distributed under the terms of the GNU General Public
License. See COPYING for additional information.


> cual conservo todo el makefile...) y encima con amavis hace after queue
> scan... mmmm interesting interesting jejejej es mas que nada por cuestión

siii.. eso mola muchooo :-)) sobre todo didacticamente y para montarlo 
distribuido y replicado.

> ya os contaré como sigo desarrollando el tema...
> 
> muchisimas gracias gente!!! os voy contando como va el tema :) :)

eso eso!!

Ale, ánimo y gracias por seguir el hilo!! Info moito interesante!!!

saludos,
-- 
Iker Sagasti Markina
Irontec, Internet y Sistemas sobre GNU/LinuX - http://www.irontec.com
+34 94.404.81.82