Tag mta - Userlinux.net

Desde hace algún tiempo -y después de haber lidiado con Cyrus y Courier- he optado por Dovecot como servidor POP3 e IMAP para máquinas en producción. Por varios motivos: la sencillez de configuración, sigue los estándares, soporta mbox y Maildir y algo muy importante, tiene un backend de autentificación SMTP compatible con Postfix (entre otros).

Sin duda el servicio de correo electrónico es el menos agradecido y probablemente el más doloroso para el sysadmin pero el haber dado con esta combinación de elementos me ha ahorrado un montón de problemas.

De todos modos en la última instalación que me ha tocado he encontrado un par de peculiaridades que me gustaría documentar por si alguien se encuentra en la misma situación.

Cuando falla la entrega en un servidor de correo lo lógico es que la cola se vaya llenando hasta reparar el problema. En ese momento las peticiones irán saliendo con cierto orden de prioridad. Hay varios comandos con los que podemos jugar para ayudar al servidor en el proceso de peticiones.

Con un poco de paciencia, conocimientos mínimos de bash y usando tanto mailq como postsuper (Postfix) podremos facilitar el flujo de correos encolados. Vamos a ello.

Debido al percance acaecido y posterior reinicio de la máquina he tenido algún que otro pequeño problema al levantar algún servicio que creía funcionando de forma correcta.

El motivo ha sido un .pid que no se borró con lo que al intentar reiniciar el servicio no se levantaba. El error (Amavis): ...connect to 127.0.0.1[127.0.0.1]: Connection refused. Y la solución pasó por borrar manualmente el .pid y arrancar el servicio. Entrada patrocinada por pajas mentales varias versión 2.0, sniff!.

Hay circunstancias en las que un problema no se resuelve de la forma más eficiente. Suele ser bajo presión, cuando las cosas no se ven del todo claras y -sin motivo lógico- acaba funcionando con la condición no escrita de no tocarle más.

Algo así pasó hace tiempo en una FreeBSD, intentando reiniciar el servicio de correo (Postfix) no atendía a razones:

# /usr/local/etc/rc.d/postfix start
#

Rabia e impotencia se unían a la presión de tener colgado un servicio de varios cientos de clientes, indagando -deprisa y corriendo- por la sintaxis de postfix al final se solucionó con un inadecuado:

En la guerra de CMS's el que más me ha convencido últimamente ha sido Drupal (marginemos rCMS de momento, está un poco congelado). Aunque hay opiniones para todos los gustos y estoy de acuerdo que se tarda más en montar y configurar este gestor de contenidos de lo que se tarda en usarlo finalmente.

Las actualizaciones normalmente son un quebradero de cabeza para el administrador, no siendo Drupal la excepción que cumple la regla. Hace relativamente poco he tenido que actualizar una web con este gestor y se me había olvidado cómo había hecho para usar un MTA externo en los registros de usuarios nuevos...