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.

• 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 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.