Advertencia!
Este archivo es bastante delicado. Advertidos =)
Este archivo contiene la configuracion para los procesos maestros de Postfix. Cada linea indica como un componente debe correr.
Para hacer una explicacion mas racional, voy a incluir el dibujito de como funciona Postfix
Los elipses amarillos son programas de correo.
Las cajas amarillas son colas de correo o archivos.
Las cajas azules son tablas lookup.
Los programas que estan en la caja grande son programas que controla el demonio maestro de postfix, tambien llamado
master.
El proceso
master es el proceso residente que ejecuta los demonios de Postfix cuando se necesitan: demonios para enviar o recibir mensajes localmente, etc. Estos demonios son creados por peticion configurados para correr un numero maximo de veces.
Los demonios de Postfix voluntariamente terminan despues de estar idle por una cierta cantidad de tiempo o despues de haber hecho una cierta cantidad de peticiones. La excepcion de esta regla es el administrador de colas, el queue manager (
qmgr).
El demonio
qmgr espera la llegada de correo entrante y se preocupa de su entrega via proceso de entrega Postfix. La estrategia de envio y reenvio es delegada a
trivial-rewrite, tambien ejecutado desde el demonio
master.
Cuando se inicia una conexión por red a MAILSVR, se inicia un proceso de compatibilidad con Sendmail llamado sendmail. Por defecto, sendmail lee un mensaje de la entrada standard hasta un EOF o hasta que exista una linea con un . (punto) y lo arregla para su envio. Sendmail trata de crear una archivo de cola, pasandolo al directorio
maildrop. Si ese directorio no tiene permisos de ejecucion para el mundo, el mensaje es pipeado a traves del comando
postdrop, que se espera se ejecute con privilegios apropiados.
El demonio
pickup espera la señal que nuevo correo ha llegado al directorio
maildrop y con este directorio alimenta a
cleanup.
El demonio
cleanup procesa el correo entrante, lo inserta en la cola de correo entrante e informa a
qmgr de su llegada.
Este demonio siempre :
- inserta headers que faltan: From:, To:, Message-Id: y Date:
- Extrae las direcciones desde To:, Cc: y Bcc: cuando ningun recipiento es especificado en el mensaje
- Transforma el mensaje y las cabeceras al formato usuario@full-dominio que es la forma que otros programas de Postfix entiendan. Esta tarea se delega a trivial-rewrite.
- Elimina direcciones duplicadas
El demonio
trivial-rewrite procesa dos tipos de peticion de cliente:
reescribir : rescribe una direccion a su forma estandar. Por defecto, trivial-rewrite agrega informacion local a direcciones no calificadas, convierte de
swap bang path a la forma de dominio y corta cualquier direccion de forma usuario@otrolado@dominio.
resolver : resurlve una direccion a una tripleta de tipo transporte, netxhop y recipiente. El sentido del resultado es:
- transporte : el agente de entrega. Es el primer campo de master.cf (servicio)
- netxhop : el host a quien enviar el correo. Para entregas locales es un string en blanco
- recipiente: el recipiente del correo que es pasado a netxhop
Este demonio ademas distingue si el correo es local o no local. La forma de afinarlo es atraves de una tabla de transporte.
El demonio
bounce mantiene los logs de los mensajes que tienen estado de no entregado. Cada archivo de log tiene el nombre de archivo del archivo de la cola de correo que le corresponde y es almacenado en un subdirectorio de la cola, con nombre igual al servicio en master.cf, generalmente
bounce o defer.
Este demonio procesa dos tipos de peticiones:
- agregar un registro de estado de recipiente en un archivo de log por mensaje
- colocar un mensaje de rebote, junto con una copia del log y del correspondiente mensaje. Si el rebote es exitosamente efectuado, el archivo de log es borrado.
El software hace su mejor esfuerzo para notificar al emisor del correo que hubo un problema. Una notificacion es enviada incluso cuando el archivo de log o el mensaje original no pueden leerse.
Opcionalmente, un cliente puede pedir que un archivo de log por mensaje sea borrado cuando la operación falla. Esto es usado por los clientes que no pueden reintentar una transaccion por ellos mismos y que dependen de la logica de reintento de los mismos clientes de correo. En español, en el software que reenvie el correo de nuevo. =)
El demonio
local procesa las peticiones de entrega desde
qmgr para entregar correo a recipientes locales. Cada peticion necesita un archivo de cola, una direccion de emisor, un dominio o host a quien entregar y uno o mas recipientes.
Ademas,
local actualiza los archivos de la cola y marca los recipientes como terminados o informa a
qmgr que la entrega debe ser reintentada en otro momento. Los problemas de entrega son enviados a los demonios
bounce o defer.
El demonio
pipe procesa peticiones desde qmgr para ejecutar comandos externos. Cada peticion de entrega requiere un archivo de cola, una direccion de emisor, un dominio o host a quien entregar correo y uno o mas destinatarios. Tiene ademas las mismas funciones de actualizacion de la cola que
local.
El proceso
smtp procesa las entregas de mensaje desde
qmgr. Funciona exactamente igual que
local y
pipe. La diferencia esta que smtp busca una lista de direcciones de hosts para intercambio de correo. Ordena la lista por preferencia y se conecta a cada una, listada hasta que encuentra un servidor que responda.
Cuando el dominio o el host esta especificado separado por espacios o comas,
smtp repite el proceso anterior para todos los destinos hasta que encuentra un servidor que responda.
El demonio
showq reporta estado de la cola de correo. Emula el comando
mailq.
Volviendo entonces a
master.cf =)
Este archivo, como dije, contiene la configuracion de los demonios internos de Postfix. Indica el servicio, el tipo de servicio, privado, no-privilegiado, chrooted, wakeups, maxima cantidad de procesos, el comando y los argumentos.
El tipo de servicio puede ser un demonio, una accion, un programa interno o un par de tipo HOST:PORT. Por ejemplo,
smtp (demonio),
submission (accion),
flush (programa) o localhost:2025
Los tipos de servicio indica la forma de transporte o comunicación entre los programas o demonios. Puede ser
inet como sockets internos,
unix para sockets de tipo UNIX o
fifo para indicar pipes.
El campo privado indica si el acceso esta restringido al sistema de correo. Por defecto, son servicios privados. Sockets
inet no pueden ser privados.
El campo no-privilegiado indica si el servicio debe correr con privilegios de root o con el setuid/setgid de
$mail_owner.
El campo chrooted indica si el servicio debe correr chrooted en la cola de correos. Hasta el momento, todos los demonios pueden correr chrooted, excepto por los demonios
pipe y
local.
El campo wakeups indica cuanto tiempo de espera debe haber antes de despertar un proceso en segundos. Un ? Indica que los eventos de wakeup deben ser enviados SOLAMENTE a servicios actualmente en uso. Con un 0 se indica que no wakeup. Hasta el momento, solo
pickup,
qmgr y
flush necesitan un tiempo wakeup.
El campo
max_procs indica el numero maximo de proceso que puede ejecutar el servicio al mismo tiempo. Lo usual es usar un numero finito o
$default_process_limit
El campo comando y argumentos indican el comando y los argumentos a ejecutar. La linea de comandos es RELATIVA al directorio donde residen los programas de Postfix o con la directiva
$program_directory.
Algunos argumentos utiles:
v : verbose logging
D : symbolic debugging
El resto de los argumentos de los programas estan en las man pages de cada uno de los comandos.
