Los sistemas *BSD suelen traer Sendmail como servidor de correo por defecto. Si se trata de servidores, normalmente solo queremos que estas máquinas saquen correo a través de un MTA autorizado (smarthost relay), no que acepten correo ni que entreguen correo localmente. Es decir, queremos que estos servidores se comporten solo como clientes SMTP.
Dado que el servidor no va a recibir correo entrante, no hay ninguna razón para ejecutar el servidor SMTP (
Configuración
Este es el contenido completo de
divert(-1)
#
# This is the FreeBSD configuration for a set-group-ID sm-msp sendmail
# that acts as a initial mail submission program.
#
divert(0)dnl
VERSIONID(`submit.mc FLOSSystems S.L., info at flossystems dot com 20130728')
define(`confCF_VERSION', `ws01')dnl
dnl dirty hack to keep proto.m4 from complaining
define(`__OSTYPE__',`')
define(`confTIME_ZONE', `USE_TZ')dnl
MASQUERADE_AS(`ws01.example.local')dnl
FEATURE(`allmasquerade')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(always_add_domain)dnl
EXPOSED_USER(`root operator')dnl
define(`SMART_HOST',`mta01.example.local')dnl
define(`confMAX_MESSAGE_SIZE',`10000000')dnl
define(`confDONT_INIT_GROUPS', `True')dnl
define(`confDEF_USER_ID',``8:12'')dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`confTO_QUEUEWARN_DSN',`')dnl
define(`confTO_QUEUERETURN_DSN',`12h')dnl
FEATURE(`msp', `mta01.example.local')dnl
Como vemos en la última línea, hemos activado el Mail Submission Program (msp), que es lo que permite que no se ejecute como demonio root.
Lo compilamos y enlazamos simbólicamente con
# cd /etc/mail
# make submit.cf
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/ /usr/share/sendmail/cf/m4/cf.m4 submit.mc > submit.cf
# ln -s submit.cf sendmail.cf
No es necesario reiniciar el demonio en modo msp, y nos avisará de ello si lo intentamos:
# make start
Starting: sendmail-submit550 Mail submission program cannot be used as daemon
sendmail-clientmqueue.
Aunque como vemos sí arranca un servicio de colas (sendmail-clientmqueue), que usa un usuario sin privilegios smmsp y que corre periódicamente la cola caso de necesitarse. Nosotros no lo necesitamos. Por si acaso, estas son las opciones para gestionarlo, sacado del Makefile de
# For acting on just the MSP queue running daemon:
# start-mspq - Start the sendmail MSP queue running daemon with the
# flags defined in /etc/defaults/rc.conf or /etc/rc.conf
# stop-mspq - Stop the sendmail MSP queue running daemon
# restart-mspq - Restart the sendmail MSP queue running daemon
En resumen, MSP nos permitirá sacar correo de la máquina a través de un MTA externo, pero evitando cualquier exploit local o remoto sobre sendmail.
Test
Para testear que funciona, enviamos un correo localmente con mailx (mailx foobar@gmail.com).
ws01# tail -f /var/log/maillog
Jul 28 12:52:18 ws01 sendmail[52744]: r6SAqIul052744: from=usuario1, size=46, class=0, nrcpts=1, msgid=, relay=usuario1@localhost
Jul 28 12:52:18 ws01 sendmail[52744]: r6SAqIul052744: to=foobar@gmail.com, ctladdr=usuario1 (1002/1002), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30046, relay=mta01.example.local. [172.16.0.254], dsn=2.0.0, stat=Sent (Ok: queued as AA60E39ACE)
El correo se ha enviado correctamente. Y comprobamos que no hay ningún daemon de sendmail ejecutándose:
ws01# ps aux | grep sendmail
ws01#
Bonus track: Activación de los aliases (workaround)
MSP es una estupenda solución, extraordinariamente segura y compacta, pero tiene un gran defecto: IGNORA la base de datos de aliases. Esto impide que los aliases que tengamos configurados en nuestro sistema, como por ejemplo los del usuario root, lleguen al buzón adecuado. Al parecer esto es una decisión intencionada de sendmail. No hay forma de hacer funcionar los aliases en sendmail junto al modo msp. En la documentación de sendmail.org lo indican así de claro: "Some things are not intended to work with the MSP. These include features that influence the delivery process (e.g., mailertable, aliases), or those that are only important for a SMTP server (e.g., virtusertable, DaemonPortOptions, multiple queues)."
A nosotros de muy poco nos serviría esta solución si no podemos usar los aliases del sistema... Pero no está todo perdido, podemos aprovechar que el correo realmente es enviado a Postfix (aunque este en principio no sabe qué hacer con los aliases, pues nada sabe de los usuarios locales de cada VM), para hacer desde Postfix el reenvío deseado. Lo que haremos es adiestrar a Postfix para que esos aliases, sean cuales sean y los mande quien los mande, lleguen a su destino. En este ejemplo usamos Postfix como servicio gestionado por pfSense, pero se hace igual en cualquier sistema con Postfix instalado de forma convencional:
- Entramos en el panel de pfSense, en Services->Postfix Forwarder
- Vamos a la pestaña General
- En Custom main.config options, añadimos esta línea:
- Accedemos por consola a pfSense (8, Shell).
- Creamos el fichero /usr/local/etc/postfix/recipient_canonical_maps con el siguiente contenido:
- Reiniciamos Postfix desde el panel web.
recipient_canonical_maps = regexp:/usr/local/etc/postfix/recipient_canonical_maps
/^usuario1\@.*\.local/ usuario1@example.com
/^usuario2\@.*\.local/ usuario2@example.com
/^(.*)\@.*\.local/ hostmaster@example.com
Cualquier usuario que envíe correo procedente de la lan 'local', será reenviado a hostmaster@example.com, con la excepción de nuestros usuarios personales, que irán a los correspondientes buzones.
Nota: para que esta solución funcione como esperamos, hay que enmascarar el correo saliente de cada VM con un dominio *.local (ver más arriba en el fichero
Publicado por flossystems el