There is no public key available for the following key IDs: 9AA38DCD55BE302B

there are two ways to solve the issue:

1. gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 9AA38DCD55BE302B; 

   apt-key add .gnupg/pubring.gpg

2. sudo aptitude install debian-keyring debian-archive-keyring

If you have network problems because of your firewall try the second one. The error, in this case, is something like:

gpg: keyserver timed out

Debian power…

and execute:

purge binary logs before ''''2008-12-31'''';
exit

That”’’s all!!!

You save a lot of disk space.

In a normal situation the process here should be, reboot the server, and using gparted or similar create a small amount of free space and allocate that as a swap partition. Fortunately this not needed nowadays, since Kernel 2.6 swap file performance has increased dramatically so the possible benefits from having a dedicated swap partition against a swap file are so small that in some situations it is preferable to have a swap file in case you wan’t to increase / decrease it’s size.

The process for building this kind of swap files is very simple:

# dd if=/dev/zero of=/home/swap bs=1M count=1024

Replacing 1024 with the number of megabytes you want will change the swap file size.

Now that we have the size we want on disk we can prepare it for usage as a swap partition:

# mkswap /home/swap

Now the swap file has being built you must introduce the following line in /etc/fstab file so this partition get’s mounted once the system is rebooted:

/home/swap swap swap defaults 0 0

And finally to test the swap file you should type, which would activate all the partitions marked as “swap” in /etc/fstab

# swapon –a

Now finally we can check that the swap partition has being activated:

# free -m
total used free shared buffers cached
Mem: 2028 1719 308 0 132 1119
-/+ buffers/cache: 468 1559
Swap: 1023 0 1023

Finally there are two useful commands you should be aware if you are playing around with swap files:

# swapon | swapoff

This commands activate and deactivate the usage of swap file.

• How to queue messages ?

The easiest way to queue messages is use qmail-queue, but if you don’t have qmail, use your actual mail server in localhost and plugin smtp-forward:

queue/smtp-forward 127.0.0.1 25

Don’t forget to accept all mail from localhost and remove spam and antivirii from your mail server. Now your mail server is acting as MDA. Let qpsmtpd do all filters (antispam, antivirii, …).

• Auth plugins

Try to use standard method like smtpd or imap. It will allow you to change any piece of software whenever without affect your qpsmtpd setup.

auth/auth_imap 127.0.0.1 993

auth/auth_smtpd 127.0.0.1 25

• Check valid rcptto

Maybe the most important plugin to avoid dictionary attacks. There are scripts to extract valid users from qmail installation: John M. Simpson has some scripts to dump all users to a cdb file. Link

But if you don’t have qmail you have to do two things in order to have qpsmtpd workproperly:

1. Dump all domains into config/rcpthosts file. Use shell or perl scripts.
2. Dump all valid users into validrcptto.cdb file. Don’t forget this file is a cdb. There are tools (like cdbmake) to help you to build a cdb file. Send the valid list to a pipe like this :

E.g.: perl getValidUsers.pl |/usr/local/bin/cdbmake-12 /opt/qpsmtpd/config/validrcptto.cdb /opt/qpsmtpd/validrcptto.tmp

And you will have a validrcptto.cdb file. Be careful and don’t forget mailing lists!!!.

When you have the file generated add this line:

check_validrcptto_cdb /opt/qpsmtpd/config/validrcptto.cdb -

before rcpt_ok plugin

• How to stop mails from an address to a valid users.

Use this plugin: check_badmailfromto

Create a file (config/badmailfromto) with two columns: from to (separated with ab)

That’s all. Easy as qpsmtpd.

• How to accept mails from a relay client.

First of all be sure the relay client is a trust client. To accept all mail from the ip, include the ip in config/relayclients file. But the best way to do it is authenticate the client via standard method.

• How to accepts mails from servers that don’t use rfc.
  

Strange?, not at all. We are in Spain where an official mail server (Seguridad Social) doesn’t respect rfc. So we had to remove rhsbl plugin from our config.

• How to avoid spamassassin for relay clients.

Just add this lines in hook_data_post method, after this line:

return (DECLINED) if $transaction->data_size > 500_000;

The code:

…

if ( $self->qp->connection->relay_client ) {
# failsafe
$self->log(LOGALERT, “Allowing relay client past spamassassin”);
return (DECLINED);
}

…

So, if it is a relayed client it doesn’t send the message to spamassassin daemon.

As you can see, qpsmtpd is powerful and easy to configure. Give it a chance. Since we use it we are very confident of our mail service and proud of performance. In another post we will comment some tips about performance.

The plugin page must be your reference when implementing qpsmtpd. There is a lot of information about all you need. Thank Ask Bjørn Hansen and the active community very much for your work.

This is the simpliest way to do it:

1. Use your favorite app manager for your linux distro. Install stunnel.
2. cd /etc/ssl (in debian) and generate pem file.
3. $openssl req -new -x509 -days 3650 -nodes -config openssl.cnf -out stunnel.pem -keyout stunnel.pem
4. You have to fill in the next questions: Country Name, State or Province Name, Locality Name, Organization Name, Organizational Unit Name, Common Name and Email Address.
5. After this step you will have a stunnel.pem file.
6. $openssl gendh 512 >> stunnel.pem
7. This generates Diffie-Hellman parameters, and appends them to the pem file.
8. To check the process and verify the certificate is ok, type: “openssl x509 -subject -dates -fingerprint -in stunnel.pem” and check the information.

After having generate the pem file, follow the instructions and you will have qpsmtpd runing in 465 port properly.

Remember the stunnel version is 3 or the wrapper for version 3 built in version 4.

En los casos en el que el origen es confiable, podemos específicamente indicarle a Exchange 2007 que queremos que acepte email de un determinado origen de forma incondicional. Para poder llevar a cabo esto prácticamente todos los MTA soportan una funcionalidad que se conoce como whitelists.

En Exchange 2007, una de las formas de acceder a la configuración de las Whitelists es a traves del PowerShell que se instala automáticamente cuando instalamos Exchange 2007. Una vez abierta la shell la gestión de las whitelist se realiza con los comando set-ContentFilterConfig y get-ContentFilterConfig

Para añadir un determinado email origen a la whitelist:

set-ContentFilterConfig -BypassedSenders usuario@dominio.com

En el caso de que queramos crear una whitelist para un dominio origen completo:

set-ContentFilterConfig -BypassedSenderDomains dominio.com

Además de crear whitelists para dominios origen, podemos hacerlo de la forma contraria, si queremos que todo lo que vaya a un determinado usuario de un dominio que alojamos nosotros podemos hacer whitelists en destino de la siguiente forma:

set-ContentFilterConfig -BypassedRecipients abc@tudominio.com,info@tudominio.com

Como podemos observar aquí la diferencia es que utilizamos el comando BypassedRecipients en vez de BypassedSenders.

La consulta del estado de las whitelists es muy sencilla y se realiza con el comando get-ContentFilterConfig esto nos devolverá el estado actual de la configuración de los filtros de una forma bastante detallada.

Para hacer más cómoda la introducción de múltiples dominios, el comando set-ContentFilterConfig acepta atributos con múltiples valores, esto nos permite solucionar el hecho de que este comando sobrescribe siempre el valor que hayamos metido en la whitelist. Por lo tanto la forma de introducir un número de emails y/o dominios es separarlos con comas.

Set-ContentFilterConfig -BypassedSenderDomains "dominio1.com","dominio2.com","dominio3.com"

Para una gestión más eficiente de las listas, existe la posibilidad de introducir y eliminar elementos de forma individual de las listas sin que se vean afectados el resto de los elementos de la lista, para ello podemos utilizar un poco de scripting de PowerShell

Si quisiéramos añadir un dominio sin tocar el resto de lo que tengamos en la whitelist:

$foo=Get-ContentFilterConfig
$foo.BypassedSenderDomains +="undominio.com"
$foo | Set-ContentFilterConfig

Análogamente, para eliminar un dominio de dicha lista, podemos utilizar los siguientes comandos:

$foo=Get-ContentFilterConfig
$foo.BypassedSenderDomains -="undominio.com"
$foo | Set-ContentFilterConfig

Hasta aquí, es todo lo que necesitamos saber para hacer una gestión de Whitelists en Exchange 2007.

Posibles soluciones para esto hay varias:

• Estatificar el contenido: Pongamos por caso una aplicación típica cuyo contenido es dinámico: Fotolog, LiveJournal, etc. Este tipo de sitios Web podrían aumentar el hitrate notablemente estatificando el contenido de sus páginas. Si lo pensamos, realmente estas páginas solo se modifican en el momento en el que se añaden comentarios, fotos o similar, no sería excesivamente difícil estatificar todo el contenido y regenerarlo cuando haya modificaciones. Las ventajas son muchas. Aumentamos el hitrate de las maquinas ya que únicamente sirven contenido estático y disminuimos drásticamente los posibles fallos de seguridad que puedan surgir, al no haber aplicación, no hay fallo que buscar. En un post anterior ya comentamos posibles usos de proxy http para segregar contenido. Como en toda solución, tenía que tener algo negativo. Hay que modificar la aplicación para que genere contenido de naturaleza estática, esto normalmente a no ser que estemos desarrollando nosotros mismos la aplicación es realmente complicado ya que estatificar todo el contenido implicaría reescribir y convertir una aplicación que fue pensada como dinámica en un backend de generación de contenido estático.

• Cacheo dinámico de contenido: Esta es la solución de moda a día de hoy. Surgió como solución intermedia entre estatificar el contenido y sacarlo directamente de base de datos, la solución pasa por tener un numero de maquinas dedicadas que almacenan en RAM a modo de hash los resultados de las consultas a base de datos. Con esto conseguimos que, si esa consulta que íbamos a lanzar a la BD ha sido pedida recientemente, la recogemos directamente desde la memoria RAM del cache, y la devolvemos directamente. En caso de que no estuviera, la pedimos a la BD y la almacenamos en el cache, usando como “key” del hash la consulta a la base de datos serializada. De esta forma el rendimiento aumenta muchísimo al disminuir notablemente la interacción con la base de datos, con todo lo que eso implica (interfaz con la BD, consultas SQL, acceso a disco, recuperar la información, etc.). Como en toda solución, siempre hay aspectos a tener en cuenta, lo primero es la inversión en hardware, se necesitan maquinas con una CPU moderada pero con una cantidad de RAM muy elevada y además hay que hacer pequeños cambios en las aplicaciones que vayan a utilizar cacheo de contenido dinámico.

Si nos decidimos a implementar un cacheo de contenido dinámico, una de las principales aplicaciones en este mundo es memcached, esta aplicación fue desarrollada por Danga, que es la empresa creadora de LiveJournal. Desde su creación ha ido evolucionando y ganando adeptos hasta el punto en el que lo están utilizando sitios de tanta repercusión como: YouTube, LiveJournal, Slashdot, Wikipedia, SourceForge, Wordpress.com, GameFAQs, Facebook, Digg, Twitter, Fotolog, BoardGameGeek, NYTimes.com, deviantART, Jamendo, Kayak, VxV y Netlog

Modificación de una aplicación para que funcione con memcached

Si finalmente nos decidimos a montar memcached como solución de cacheo dinámico, tenemos que afrontar el tema de las modificaciones a realizar en la aplicación. El aspecto positivo de todo esto es que si la aplicación que queremos montar bajo memcached es OpenSource hay muchas posibilidades de que alguien ya se haya ocupado de hacer las modificaciones, como es el caso de aplicaciones tan conocidas como WordPress,WikiMedia y phpBB. ¿Pero, y en el caso de que no sea una aplicación conocida, o incluso que estemos desarrollando nuestra propia aplicación? En este caso, la solución pasa por meter unas pocas llamadas en el flujo de la aplicación para que en vez de realizar la consulta directamente a la BD, primero consultemos al cache.

Un escenario típico podría ser el siguiente. Tenemos una función que realiza una consulta a la BD:

function get_foo (int userid) {
result = db_select("SELECT * FROM users WHERE userid = ?", userid);
return result;
}

Tras realizar las modificaciones, para que primero se consulte a memcached la función quedaría de la siguiente forma:
function get_foo (int userid) {
result = memcached_fetch("userrow:" + userid);
if (!result) {
result = db_select("SELECT * FROM users WHERE userid = ?", userid);
memcached_add("userrow:" + userid, result);
}
return result;
}
En este caso, primero consultamos al cache, si el cache tiene almacenada esa clave la devuelve directamente. En caso contrario, preguntamos a la base de datos y lo almacenamos en el cache para que las siguientes consultas sean desde RAM.

Así mismo, las actualizaciones en BD hay que modificarlas porque si no el cache empezaría a devolver información incorrecta, la forma más fácil de hacer esto es directamente desde la aplicación, en el momento en el que se produzca una actualización, directamente eliminamos esa “key” y la substituimos por la nueva de la siguiente forma:
function update_foo(int userid, string dbUpdateString) {
result = db_execute(dbUpdateString);
if (result) {
data = createUserDataFromDBString(dbUpdateString);
memcached_set("userrow:" + userid, data);
}
}

Con modificaciones similares las explicadas, y una buena configuración de la plataforma de cacheo, se consigue un hitrate de un 70%, esto quiere decir que un 70% de las peticiones le llegan directamente a memcached sin que llegue un solo byte a la BD.

En posteriores artículos haremos un ejemplo completo de cómo se monta un memcached con un par de ejemplillos de acceso y alguna estadística.

En este caso se hace un proxy inverso, es decir, se envían las peticiones desde el frontend al backend. El “problema” es que las peticiones tienen origen (frontend) 127.0.0.1 (si en el backend está en la misma máquina) o la ip interna 192.x.x.x (si el backend está en la red interna). Si el frontend es suficientemente flexible soporta balanceo entre servidores. Esta es una lista de frontends que funcionan muy bien:

• pound: básicamente es un balanceador, pero muy eficiente
• perlbal: balanceador hecho en perl y servidor web para archivos estáticos. El código perl es sencillo y muy pontente, por lo que se pueden añadir funcionalidades rápidamente. Muy eficiente.
• squid: el de siempre. Se ha utilizado mucho para hacer proxy directo en vez de inverso, pero también se puede utilizar. Funciona muy bien y tiene un montón de funcionalidades, pero es menos eficiente que los anteriores.
• HAPrroxy: si buscas información detellada no te pierdas la documentación. Al final existe una explicación de la arquitectura separada en contenido estático y dinámico. Es uno de los mejores balanceadores/proxy, aunque incluye más funcionalidades.
• lighttpd: es un servidor web que nos puede servir páginas estáticas y hacer de proxy para el resto de peticiones. Una de las funcionalidades más interesantes es que puedes aplicar regular expressions para decidir el backend. Lo utilizamos en alguna ocasión con éxito.
• nginx: es un servidor web que cada día tiene mejor pinta. Es muy eficiente, rápido y sencillo de configurar. Cada día peligra más la hegemonía del apache. Permite servir un tipo de contenido y reenviar el resto al backend. Permite también regular expressions. Lo tenemos como frontend en algunos servidores y es una maravilla.

Pues bien, todas estas soluciones hay que configurarlas para que envíen la ip real al backend. Por ejemplo, en el caso del nginx hay que poner estas líneas:

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Sin embargo, el apache siempre pinta la ip del que viene la petición: 127.0.0.1 o la ip interna. Para lograr que pinte la ip real hay que utilizar un pequeño módulo: mod_rpaf.

El montaje es sencillo:

$ wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.5.tar.gz
$ tar xzf mod_rpaf-0.5.tar.gz
$ cd mod_rpaf-0.5
$ vi Makefile (editar la variable APXS)
$ make rpaf; make install (para el apache 1.x)
$ make rpaf-2.0; make install-2.0 (para el apache 2.0.x)

Luego hay que editar la configuración del apache y añadir estas líneas:

LoadModule rpaf_module        libexec/mod_rpaf.so
AddModule mod_rpaf.c
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 192.168.1.1
RPAFheader X-Forwarded-For

Ojo, en la línea RPAFproxy_ips hay que poner todas las ips desde donde vengan las peticiones al apache. Reiniciamos el apache y ya están las ips reales en los ficheros de logs.

$exim -bp |more

Borrar los que llevan 18 días en la cola:

$exim -bp | grep 18d | awk ‘{ print $3 }’ | xargs exim -Mrm

Hacer flush a la cola, o lo que es lo mismo reprocesar la cola:

$exim -qf

o

$exim -qff

y para hacer debug del flush de la cola hay que poner -d (debug) al final.

Para procesar también los correos “frozen”

Otras opciones para todos los mensajes y para mensajes concretos:

-bp : Queue email in Server
-bpc : Count Queue email in Server
-M : Force delivery
-Mar : Add recipient
-Meb : Edit message body
-Mes : Edit sender
-Mf : Freeze message
-Mg : Give up (and bounce message)
-Mmad : Mark all recipients as delivered
-Mmd : Mark recipient as delivered
-Mrm : Remove message (no bounce)
-Mt : Thaw message
-Mvb : View message body
-Mvh : View message header
-Mvl : View message log

OJO!!!!, todo esto es válido si se utiliza el configure por defecto. Si se utiliza otro hay que añadir -C /opt/exim/configure.queseutiliza

El primero dice a qmail los dominios que aceptamos y el segundo los que son locales.

Luego hay que recrear las bases de datos , más bien los cdbs mediante el comando:

/var/qmail/bin/qmail-newmrh

en el caso que lo añadamos al control/morercpthosts porque el rctphost está muy lleno.

Por cierto, esto lo aprendimos allá por la primavera del 2000, cuando Mario puso un mensajito en la lista de qmail: msg20929.html

Y además, si buscas qmail+MX+secondary aparece como primer link la pregunta al foro de Mario

Generalmente, un qmail-smtp tiene una pinta así:

exec /usr/local/bin/softlimit -m 20000000
/usr/local/bin/tcpserver -v -H -R -P -l 0
-x /home/vpopmail/etc/tcp.smtp.cdb
-c “$MAXSMTPD”
-u “$QMAILDUID” -g “$NOFILESGID” $IP 25
/var/qmail/bin/qmail-smtpd
/home/vpopmail/bin/vchkpw /bin/true 2>&1

Este, por ejemplo, funciona para vpopmail. Pues el fichero /home/vpopmail/etc/tcp.smtp.cdb es donde están las ips abiertas, es decir para las que se hace relay. Para actualizar ese fichero basta con añadir esta línea al fichero /home/vpopmail/etc/tcp.smtp

x.x.x.x:allow,RELAYCLIENT=”",RBLSMTPD=”"

Ojo, poner mejor delante de la última línea que será algo así como:

:allow,QMAILQUEUE=”/var/qmail/bin/simscan”

Luego hay que compilar las reglas con:

/usr/local/bin/tcprules /home/vpopmail/etc/tcp.smtp.cdb /home/vpopmail/etc/tcp.smtp.tmp < /home/vpopmail/etc/tcp.smtp

Ojo, dejar los permisos correctamente de los ficheros. Puede ser que haya algún proceso que los cambie o lee y podemos fastidiarlo. También hay que tener en cuenta que todos los ficheros .cdb, .tmp y el de las reglas tienen que estar en el mismo filesystem. Si no es así da un error un poco feo y poco explicado.

Más adelante, se empezó a hablar de lenguajes de programación que convertían el contenido estático en páginas dinámicas. Se utilizaban cgis en C o en perl. Si el servidor estaba en unix incluso se podía utilizar shell scripts. Esos cgis en C permitían conectar con gran cantidad de sistemas en backend, desde bases de datos al uso a entornos hosts o middleware creados al efecto. Todas las empresas decidieron que era el momento de sacar sus aplicaciones a internet. Fue el primer boom, proyectos faraónicos y muchas, muchas horas de programación. Era la anarquía. Pero esto era coto cerrado para grandes empresas que invertían grandes cantidades de dinero. El resto se conformaban con una página web estática y un link que enviaba un mail.

Pero en 1995, Rasmus Lerdorf creó un lenguaje de programación que llamó PHP (Personal Home Page). Empezó como un cgi en C que interpretaba páginas con contenido estático y un lenguaje muy sencillo para poder generar el contenido dinámico. Tras varias versiones se incluyó el cgi como módulo del apache y su popularidad empezó a crecer. En ese momento existía un servidor web, llamado apache con un módulo de php que permitía crear páginas web dinámicas de forma sencilla y económica. A partir de ahí se produjo una segunda explosión de la web.

Sin embargo no eran muchas las empresas que se fiaban de “eso del open source”, confundiendo una vez más los terminos y descalificando las tecnologías sin conocerlas. De ahí que muchas empresas comenzaran a crear nuevas tecnologías y dar soporte para que las grandes empresas tuvieran la tranquilidad de entrar en un mundo nuevo. Compañías como Sun Microsystems, Netscape, Bea, IBM o Microsoft entraron en un nuevo nicho de mercado: los servidores de aplicaciones. Sun fue una de las primeras en entrar con su lenguaje java. Fue uno de los lenguajes que más rápido se popularizó. Una de las ventajas era su caracter abierto a la comunidad de desarrolladores. Sun mientras tanto se dedicó a vender su servidor de aplicaciones. Bea fue otro de los competidores que entró de la mano de su producto Weblogic. IBM suele llegar tarde al mercado, pero con el tiempo se impone al resto. Es un corredor de fondo. Su producto Websphere Application Server tardó más que el resto en llegar, sin embargo a día de hoy es el líder frente a sus competidores en el apartado de servidor de aplicación en java. IBM utiliza como frontal web apache. Microsoft emplea sus propios lenguajes que ejecutan sus motores. La web más reconocida para este benchmark es Netcraft que publica semanalmente un informe (por ejemplo Junio 2008), donde muestra este gráfico actualizado:

Lo que nos indica claramente el gráfico es la supremacía de los servidores de código abierto sobre los propietarios, y no sólo por apache. Hay que incluir lighttpd, nginx o google, que aunque no está liberado está basado en apache (al menos eso se dice en la red y es uno de los conocimientos que piden para entrar a trabajar en Google).

Esta es la teoría, en un siguiente post, mostraremos la evolución tecnológica y cómo se mejora el rendimiento con los nuevos productos. LandM empezó con servidores apache sin ningún tipo de lenguaje de programación. Hoy tenemos un frontal para servir contenido estático, un servidor apache que ejecuta cierta lógica y el contenido dinámico que es interpretado por otro motor. Además incorporamos caches intermedias para acelerar la respuesta. ¡Cómo hemos cambiado!

$echo “dominiodestino:ipdelsmarthost”> /var/qmail/control/smtproutes

Para enviar todo el correo de todos los dominios a través de otro servidor:

$echo “:ipdelsmarthost”> /var/qmail/control/smtproutes

Esto viene muy bien cuando por alguna razón nos han metido en alguna blacklist y hay que enrutar todo el correo a través de otra máquina.

Lo lógico es no olvidar quitarlo cuando se ha corregido el error de la blacklist.