	Sign In Sign-Up

Manual C.C.C. para la instalación de sendmail

Alberto Bernardo Acckerstein
alberto@ccc.uba.ar
Marzo de 1999

Se asume que el lector ya posee conocimientos básicos de Unix, DNS, SMTP, MTA's y MUA's.

Obtención e instalación

Actualmente sendmail es muy fácil de obtener y de instalar, con sólo acceder con cualquier browser a la dirección http://www.sendmail.org/ se puede bajar la última distribución disponible.

Una vez que la hayamos bajado, hay que descompactarla, preferentemente en /usr/src. Una vez hecho esto, ir al subdirectorio src dentro del directorio principal de sendmail, y ejecutar el comando ./Build, preferentemente con la opción -c. Una vez hecho esto hay que generar el /etc/sendmail.cf, la forma mas fácil de generarlo es con m4, aunque también se lo puede escribir manualmente. En el CCC lo vamos a instalar sobre Linux y sobre Solaris. Para la instalación Linux no hay mayores recomendaciones a hacer, ya que incluso viene incluida en las últimas distribuciones que estamos instalando (en nuestro caso la slackware). En cambio en Solaris habría que tener en cuenta las recomendaciones básicas de seguridad sobre los directorios que utiliza sendmail, ya que la versión que utilizamos, la 2.5.1, deja como Group Writable directorios que podrían comprometer la seguridad del sistema al utilizarlas bajo sendmail; ante esto tenemos dos opciones, cambiar los permisos en Solaris para que sendmail no se queje al respecto, o bien modificar la configuracion de sendmail para que haga caso omiso sobre el posible compromiso de seguridad. Otro tema a considerar es la utilización de majordomo con sendmail, para lo cual siguiendo estrictamente las precauciones de seguridad al respecto, el sendmail no producirá ningún error, sin necesidad de quitar los controles de seguridad de sendmail. Tener en cuenta que las nuevas versiones de sendmail vienen con reglas anti-relay incorporadas, por lo que hay que crear el archivo (por defecto en /etc/mail/relay-domains) con la lista de hosts a quienes se les permite usar de relay el servidor.

Una vez tomadas las precauciones correspondientes, sólo queda realizar la instalación con un simple ./Build install. Acordarse siempre (si no se quiere resetear el servidor) de haber matado primero el MTA anterior, haber probado antes de sobreescribir el nuevo que éste esté funcionando correctamente, y por último de cargar como daemon el nuevo MTA.

¿Cómo funciona sendmail?

Esta explicación es sobre el funcionamiento básico de sendmail de acuerdo a la instalación que nosotros realizamos, no es nuestra intención dar una explicación técnica detallada de cómo funcionan los llamados a sistema de Unix, cómo funciona un MTA, un DNS, UDP, TCP, SMTP. Mucho menos en profundizar en aspectos técnicos concernientes a sendmail. Toda aquella persona familiarizada con aspectos técnicos avanzados de cualquiera de los temas mencionados anteriormente puede obviar esta sección debido a que está destinada a quienes por primera vez instalan sendmail y no conocen en profundidad los temas mencionados.

Sendmail funciona como MTA (Mail Transport Agent), esto signfica que es el encargado de recibir y guardar nuestros mensajes en nuestras casillas de correo, así como de distribuir los que enviamos hacia otros servidores. Los programas que utilizamos para leer nuestro correo, así como para enviarlo, se denominan MUA (Mail User Agent).

Cuando nosotros utilizamos un MUA para enviar un mensaje, este programa lo envía al MTA, en nuestro caso sendmail. Una vez que sendmail recibe nuestro mensaje lee la configuración para aplicarle las reglas correspondientes para su proceso dentro de la cola y posterior envío. La configuración leída se encuentra en el archivo /etc/sendmail.cf, el directorio donde sendmail guarda la cola de mensajes se encuentra en /var/spool/mqueue, si observamos el archivo sendmail.cf veremos que existe una línea

O QueueDirectory=/var/spool/mqueue

que le indica a sendmail donde guardar la cola de mensajes. En la cola de mensajes puede haber mensajes dirigidos a los usuarios locales (que poseen cuenta en el mismo servidor donde sendmail está funcionando) o a usuarios que se encuentran en otros servidores.

En el caso de que el mensaje esté dirigido a un usuario local, sendmail lo busca en el archivo de alias, que se encuentra en /etc/aliases; en la configuración figura en una línea

O AliasFile=/etc/aliases

De encontrar dicho usuario en el archivo de alias, lo expande para realizar la acción correspondiente que puede ser enviarlo a otro(s) usuario(s) dentro o fuera del servidor, o ejecutar un programa (por ejemplo un sistema de listas de distribución. Para ver el funcionamiento de las listas de distribución, en especial majordomo, se aconseja leer las notas CCC sobre majordomo, y también el manual CCC de majordomo, ambas a editarse próximamente). Si no se encuentra ese usuario listado en el archivo de alias, sendmail lee el /etc/passwd para verificar si el usuario posee cuenta en el servidor, de no tener cuenta en el mismo, rebota el mensaje al remitente avisando que dicho usuario no existe. Si el usuario es encontrado, se fija por la existencia de un .forward en el home del usuario (si el sendmail no es configurado adecuadamente, en los servidores que el home apunta a /dev/null por ejemplo, sendmail dará mensajes de error diciendo que no puede encontrar /dev/null/.forward), cuya configuración está dada por la línea

O ForwardPath=$z/.forward.$w:$z/.forward

El .forward es expandido y ejecutado de la misma forma que /etc/aliases En caso de no existir un .forward, sendmail agregará el mensaje en la casilla de correo que se encuentre en el directorio de casillas de correo (en Linux y SunOS /var/spool/mail, en Solaris /var/mail) que tenga el mismo nombre del usuario.

Si el mensaje está destinado a una cuenta fuera de nuestro servidor, sendmail primero intenta resolver el MX del dominio de la dirección del mensaje consultando al DNS. De no poder resolver un MX válido para ese dominio, el mensaje quedará en la cola un tiempo predeterminado. Un ejemplo de configuración para tratamiento de colas a través de SMTP sería:


Msmtp,          P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990,
                T=DNS/RFC822/SMTP,
                A=IPC $h

En nuestra instalación se utilizan varios más simultáneamente. Una vez que sendmail pudo resolver un MX válido, transporta el mensaje por SMTP al relay correspondiente para ese dominio.

Para realizar la mayor parte de las operaciones, sendmail las hace como root, en estas operaciones no sólo hace llamadas a sistema, sino que también llama a otros programas (como por ejemplo los que el usuario indique en su .forward) teniendo que hacer forks o execs al shell para que estos puedan ser ejecutados; de ahí la importancia de siempre seguir correctamente las indicaciones sobre seguridad de sendmail. Por ejemplo, por estar apurados por solucionar un aparente problema con majordomo, no bajar los chequeos de las reglas de seguridad en sendmail debido a los modos promiscuos que maneja majordomo ya que esto podría llegar a tener consecuencias nefastas sobre la seguridad de nuestro servidor. Es preferible tomarse un tiempo y ajustar todos los permisos correctamente antes que "poner parches" que a la larga terminan trayendo problemas mayores.

La gran mayoría de los servidores SMTP que instalamos en el CCC son para que funcionen como relays o smart hosts de toda una subred, por lo que también hay que tener en cuenta en que red se va a instalar sendmail ya que como se dijo anteriormente, las nuevas versiones de sendmail no permiten hacer relay por defecto. Una vez que sabemos a quienes se autoriza a que utilizen el servidor como relay de mail, sólo hay que agregarlos al archivo /etc/mail/relay-domains, cuya configuración figura en la línea


FR-o /etc/mail/relay-domains

Para filtrar dominios, servidores, o cuentas de correo es conveniente agregar en el momento de crear el sendmail.cf con el m4 el


FEATURE(access_db)

así podremos utilizar el archivo /etc/mail/access para filtrar posibles emisores de spam. Así como se debe crear el índice para aliases con el comando newaliases, acordarse de utilizar el programa makemap para crear el índice correspondiente.

Creando un `sendmail.cf` con `m4`

Utilizaremos como referencia la documentación provista con sendmail, que se encuentra en ${SENDMAIL}/cf/README. En este manual solamente hablaremos de m4 con respecto a generar archivos de configuración para sendmail, si se quiere profundizar sobre el procesador de macros m4, este manual no será de mayor utilidad. Los archivos conteniendo la configuración a procesar por m4, se guardan por convención con la extensión .mc (macro configuration), y los archivos generados (por ejemplo sendmail.cf) se guardan con la extension .cf (configuration file).

Se utiliza m4 pasando el nombre del archivo o de los archivos que contienen las macros como parámetro, si no se ingresan parámetros m4 toma el stdin; la salida la realiza a stdout, salvo en el caso de error, en la que es redireccionada a stderr.

Por cada comando o macro leída, m4 agrega una línea en blanco a la salida; si se quiere evitar esto, se deberá usar el comando dnl (delete through new line) al final de cada macro o comando.

Para definir una macro en m4 se utiliza la sentencia define, de esta forma:


define(macro,valor)

También se puede dividir la entrada en varias partes para luego rearmarlas de una forma más lógica, para esto m4 utiliza los comandos divert y undivert, por ejemplo:


divert(1)dnl
Ejemplo de configuracion 1
divert(2)dnl
Ejemplo de configuracion 3
divert(1)dnl
Ejemplo de configuracion 2
undivert(1)dnl
undivert(2)dnl

Nos daría la siguiente salida:

 
Ejemplo de configuracion 1 
Ejemplo de configuracion 2
Ejemplo de configuracion 3

No es necesario profundizar en este tema para la configuración de sendmail, aunque es bueno conocerlo.

Sendmail utiliza la siguiente tabla interna para divert (puede llegar a cambiar en futuras versiones):

(-1)	Ignorar las líneas que siguen, interna de m4.
(0)	Terminar con divert y generar la salida de forma inmediata, 
	interna de m4.
(1)	Detección y resolución del host local con LOCAL_NET_CONFIG.
(2)	Agregados a la regla 3 (vía la 96) con LOCAL_RULE_3.
(3)	Agregados a la regla 0 (vía la 96) con LOCAL_RULE_0.
(4)	Agregados a la regla 0 para UUCP.
(5)	Nombres interpretados localmente con LOCAL_USER.
(6)	Configuración local con LOCAL_CONFIG.
(7)	Definiciones para el delivery agent con MAILER y MAILER_DEFINITIONS.
(8)	No se utiliza.
(9)	Reglas 1 y 2 con LOCAL_RULE_1 y LOCAL_RULE_2, regla 5 y LOCAL_RULESETS.

Existen 4 ítems básicos que podemos utilizar en nuestro archivo .mc, 2 de los cuales es obligatorio utilizarlos para generar nuestro .cf. Esos ítems son:

OSTYPE()	Obligatorio	Soporte para nuestro OS.
MAILER()	Obligatorio	Delivery agents que vamos a utilizar.
DOMAIN()	Recomendado	Información sobre el dominio.
FEATURE()	Recomendado	Soluciones a necesidades especiales.

En nuestro caso deberemos utilizar


OSTYPE(`linux')

en caso de estar haciendo la instalación sobre Linux, u


OSTYPE(`solaris2')

en caso de estar haciendo la instalación sobre Solaris.

El item MAILER() soporta la declaración de varios tipos de delivery agents:

Opción		Delivery agent
cyrus		cyrus, cyrusbb
fax		fax
local		local, prog
mail11		mail11
phquery		ph
pop		pop
procmail	procmail
smtp		smtp, esmtp, smtp8, relay
usenet		usenet
uucp		uucp, uucp-old, uucp-new, uucp-dom, uucp-uudom

Nosotros utilizaremos sólo


MAILER(`local')
MAILER(`smtp')

El ítem DOMAIN() nos sirve para incluir otro archivo .mc, que deberá estar contenido en el directorio ${SENDMAIL}/cf/domain. Esto nos puede llegar a ser de utilidad si tenemos que crear algún tipo de configuración especial para un sitio grande, por ejemplo si decidiésemos cambiar zmailer por sendmail, nos convendría escribir toda la configuración relativa al relay de la UBA de una forma similar a esta:


DOMAIN(`uba.ar')

y en ${SENDMAIL}/cf/domain/uba.ar.mc tener la configuración particular para nuestro dominio.

Para ver en mayor detalle las posibilidades del item FEATURE(), ver ${SENDMAIL}/cf/README. Nosotros vamos a utilizar principalmente:


FEATURE(`access_db')
FEATURE(`use_ct_file')
FEATURE(`use_cw_file')

La opción access_db nos permite utilizar /etc/mailer/access para filtros o configuraciones especiales respecto del sendmail utilizado como relay, use_ct_file nos permitirá utilizar /etc/sendmail.ct para la lista de trusted users, use_cw_file nos permitirá utilizar /etc/sendmail.cw para la lista de hosts locales.

Para mayor seguridad en nuestro servidor, nos sería conveniente utilizar la siguiente configuración, a traves de la definición:


define(`confPRIVACY_FLAGS',`goaway')

para que sendmail pueda agregar a los encabezados el X-Authentication-Warning, además de impedir el uso de los comandos SMTP VRFY y EXPN, como también el exigir un HELO en la transacción SMTP. Para la opción PrivacyOptions, podemos utilizar una o más (separadas por una coma y un espacio) de las siguientes posibilidades:

Opción		Significado
authwarnings	Habilita encabezados con X-Authentication-Warning (es la opción por defecto).
needexpnhelo	Pide un HELO o EHLO para poder usar EXPN.
needmailhelo	Pide un HELO antes de MAIL.
needvrfyhelo	Pide un HELO antes de VRFY.
noexpn		Desabilita EXPN.
noreceipts	Desabilita los return receipts.
novrfy		Desabilita VRFY.
public		Desabilita los chequeos por seguridad o privacidad.
restrictmailq	Restringe el uso de mailq.
restrictqrun	Restringe el acceso a procesar la cola.
goaway		Alias para usar authwarnings, noexpn, novrfy, needmailhelo, needexpnhelo, needvrfyhelo al mismo tiempo.

En las instalaciones que hagamos en las que no queremos que salgan los nombres de los servidores de dicho dominio, sino sólo el nombre del dominio (por ejemplo, que en lugar de salir el mail como user@muitu.cea.uba.ar salga como user@cea.uba.ar), deberemos utilizar


MASQUERADE_AS(`cea.uba.ar')
FEATURE(masquerade_entire_domain)

Los tipos de enmascarado soportados son:

Qué					Enmascara
EXPOSED_USER				A todos menos a ese.
FEATURE(allmasquerade)			También al destinatario.
FEATURE(limited_masquerade)		Sólo los hosts $=M.
FEATURE(masquerade_entire_domain)	Todo el dominio.
FEATURE(masquerade_envelope)		El envelope también.
MASQUERADE_AS				Como otro host.
MASQUERADE_DOMAIN			Como otro dominio.
MASQUERADE_DOMAIN_FILE			Como otro dominio.

Si no vamos a utilizar /etc/sendmail.cw, acordarse de agregar la línea


Cwnombre.dominio.servidor

en nuestra configuración. En cambio si utilizamos sendmail.cw, no tendremos que agregar dicha línea en el mismo.

Es recomendable agregar también la identificación de versión que generemos, a continuación mostramos un ejemplo:


VERSIONID(`@(#)archivo.mc	8.11 (C.C.C.) 15/03/1999')

Una vez creadas las definiciones para m4, construiremos la configuración de la siguiente manera:


m4 ../m4/cf.m4 archivo.mc > sendmail.cf

Lo más aconsejable es crear un Makefile, suponiendo que el m4 está en /usr/local/bin/m4, que instalamos el source de sendmail en /usr/src/sendmail, y que el .mc se llama ccc-config; nuestro Makefile quedaría así:


M4=/usr/local/bin/m4 	
CFDIR=/usr/src/sendmail/cf
ccc-config: ccc-config.mc
	$(M4) -D_CF_DIR=$(CFDIR) $(CFDIR)/m4/cf.m4 ccc-config.mc > sendmail.cf

Una vez hecho el Makefile (en el directorio cf/cf) con sólo poner make quedará hecha nuestra configuración. Tip: se puede utilizar la claúsula include dentro de nuestro .mc, para abreviar (en caso de que no hagamos el Makefile) nos serviría poner como primera línea de nuestro .mc:


include(`../m4/cf.m4')

ahora imaginen en qué nos beneficiaría ;-).

Aunque no las vayamos a utilizar también sería interesante agregar las configuraciones aceptadas para relays:

Relay		Descripción
BITNET_RELAY	Relay para BITNET.
DECNET_RELAY	Relay para DECnet.
FAX_RELAY	Relay para fax.
LOCAL_RELAY	Relay para usuarios incondicionales.
LUSER_RELAY	Relay para usuarios locales desconocidos.
MAIL_HUB	Todo el despacho local hacia un server.
SMART_HOST	El relay principal.
UUCP_RELAY	Relay para UUCP.

También es interesante pegar un vistazo al soporte UUCP, como vimos ya tenemos UUCP_RELAY, a esta configuración sólo tendríamos que agregarle:

UUCPSMTP	Conversiones individuales de UUCP a network.

Sendmail soporta varios tipos de agentes de transporte para UUCP:

uucp-old (alias uucp)
transforma las direcciones a la forma ! utilizada por los viejos transportes UUCP, de la forma:

user			--->		servidor!user
user@host.dominio	--->		servidor!host.dominio!user

No es aconsejable utilizar este tipo de transporte, ya que sólo puede transportar de a un destinatario por vez, consumiendo muchos recursos al tener que duplicar el mensaje para cada retransmisión.

uucp-new (alias suucp)
Los nuevos agentes UUCP soportan múltiples destinatarios de una sola vez, funciona igual que el uucp-old, a excepción de que puede manejar múltiples destinatarios.

uucp-uudom
Las implementaciones más nuevas de UUCP pueden manejar correctamente las direcciones Internet en los encabezados (aunque sigan requiriendo de la forma ! en los envelope). Si el transporte UUCP utilizado lo soporta, ésta es la que se deberá usar. Este estilo es el que agrega el From de 5 caracteres y la dirección en la forma !.

uucp-dom
Esta es la más correcta de las implementaciones UUCP, ya que los encabezados y el envelope, si están o no en la forma !, son enviadas en la forma correcta. Esencialmente, utiliza UUCP como mecanismo de transporte, pero en todos los demás aspectos adhiere con los estandares de Internet.

Cuáles son y cómo utilizar los archivos externos definidos

Si configuramos use_ct_file, el archivo que deberemos crear será /etc/sendmail.ct. En este archivo colocaremos la lista de trusted users, o sea los que pueden ejecutar cierto tipo de acciones especiales sin que sendmail se queje al respecto (con X-Authentication-Warning por ejemplo). Antes del nombre de cada usuario, deberá ir una T, quedando el archivo de la siguiente forma (ejemplo):


Troot
Tuucp
Tdaemon

Tener en cuenta que si configuramos las opciones de trusted user para m4, no va a ser necesario volverlas a agregar en /etc/sendmail.ct, ya que este archivo lo estaríamos creando para darle al administrador del server la posibilidad de agregar de forma sencilla sus trusted users en caso de necesitarlo. Como recomendacion de seguridad, NO agregar usuarios a sendmail como trusted users, imagínense por qué. Si tienen poca imaginación y la suerte de trabajar en algun ISP grande (por ejemplo impsat) denme una cuenta ahí y pónganme como trusted ;-). Si se va a agregar un trusted user, la decisión deberá ser tomada por alguien con experiencia en entornos Unix.

Si configuramos use_cw_file, el archivo que debermos crear será /etc/sendmail.cw. En este archivo colocaremos principalmente la lista de nombres de hosts locales (si es que nuestro server tuviese más de un nombre asignado), la indicación de Mail Hub, y los enmascaramientos, por ejemplo:


Cwccc.uba.ar
Cwdcfcen.uba.ar
DMccc.uba.ar
DHrelay2.uba.ar

Lo anterior es sólo un ejemplo, va la misma recomendación que para .ct, si ya se definió en m4, no es necesario volver a definirlas acá. Sobre esta opción no es necesario hacer ninguna recomendación de seguridad.

Para la opción access_db, deberemos crear un archivo /etc/mail/access; dicho archivo deberá contener la lista de cuentas de correo, servidores y/o dominios que querramos rechazar/aceptar de alguna forma especial, seguida del parámetro que le indicará a sendmail la acción a tomar:

Acción			Descripción
OK			Acepta su mail, incluso aunque las reglas de 
			sendmail indiquen lo contrario, e incluso aunque
			no se puedan resolver los dominios involucrados
			en el mensaje.
RELAY			Similar a la anterior, pero sólo ignora las reglas
			anti-relay.
REJECT			Rechaza el mail, enviando un aviso de rechazo.
DISCARD			Rechaza el mail, sin enviar un aviso de rechazo 
			y sin siquiera terminar de chequear el resto del 
			envelope.
### cualquier texto	### deberá ser un número de error válido de 
			acuerdo al RFC821, y cualquier texto, el aviso 
			a enviar para dicho código de error.

A continuación mostraremos un ejemplo del access:


spammer@spam.net	DISCARD
server.spam.net		DISCARD
spam.net		DISCARD
192.168.1.3		DISCARD
157.92			RELAY

Tener en cuenta que el conjunto de instrucciones que especifiquemos aquí modificará el comportamiento de sendmail respecto de las reglas anti-relay, especialmente al utilizar las opciones OK y RELAY (no se recomienda utilizarlas, para eso está el archivo /etc/mail/relay-domains).

Una vez que hayamos terminado de crear nuestro archivo access, deberemos crear el índice para el mismo (al igual que con aliases), de la siguiente forma:


makemap hash /etc/mail/access < /etc/mail/access

Otros archivos a tener en cuenta son el /etc/sendmail.st y los archivos log. El archivo sendmail.st es el status file del sendmail, utilizado para efectuar estadísticas de uso del SMTP server. Es incremental, por lo que si se quiere una estadística periódica, se deberá agregar en el cron el movimiento y puesta a cero del mismo. El comando para ver las estadísticas es mailstats. Respecto del log, por defecto en Solaris lo guardará en /var/log/syslog y en Linux en /var/log/messages; si queremos cambiar esto (se recomienda hacerlo para facilitar el control del servidor de correo), se deberá modificar el archivo /etc/syslog.conf; para esto último se deberá tener conocimiento de cómo funciona syslog. Si no se sabe cómo funciona syslog y se quiere separar el log se sendmail del log por defecto, se recomienda agregar la siguiente línea en /etc/syslog.conf (si ya existiese alguna variable mail apuntando hacia algún otro lugar, eliminarla si no se quiere engrosar ese archivo con información redundante sobre sendmail)


mail.*	/var/log/sendmail.log

tener en cuenta que la separación está dada por una tabulación, no por espacios. Para mayor información sobre syslog.conf ver el man.

Chequeo de permisos en el OS

Por defecto, al instalar sendmail, se instala con los permisos correctos para cada sistema. La única recomendación a tener en cuenta, es respecto a la actualización de sendmail en Solaris, ya que el que viene con Solaris utiliza el modo inseguro de acceso a directorios. Es recomendable en Solaris primero arreglar los permisos de los directorios /etc /etc/mail /var /var/mail ya que son 775, y pasarlos a 755, con cuidado de ver que ningún programa necesite el modo 775 para funcionar, en el caso de /etc/mail no habría problema, ya que es utilizado por el sendmail de Solaris para guardar las configuraciones que ya no se utilizarían (sería conveniente hacer un backup para luego borrarlo, para que los archivos anteriores no se mezclen con los nuevos, así se evitan confusiones). Otra cosa a tener en consideración es el estado de los permisos de los home de los usuarios, estos deberán estar por lo menos en 755 (pueden llegar a estar en 700), ya que en modo 775 por ejemplo, son un potencial problema, tengan en cuenta lo del .forward. Un error de seguridad que podría llegar a ser común, es el de asignar /tmp de forma tal que pueda usarse un .forward ahí.... (sin comentarios). Acordarse de que los permisos de los archivos sendmail.cf, aliases, access y demás deben ser sólo escribibles por el UID 0.

Interacción con `majordomo`

Ya que estuvimos comentado algo sobre los permisos y los trusted users, podemos ver qué pasa con majordomo, la confianza, y la seguridad respecto de sendmail. La instalación de majordomo sugiere que los directorios que utiliza majordomo sean 775 así como también los archivos que contienen y configuran las listas sean 664 o 660. Esto es un problema de seguridad en potencia, que es fácilmente solucionado si se crea un UID aparte para el usuario majordom (acordarse que en Unix estamos limitados a 8 caracteres para el login) y configurar todo en modo 750 y 640 para la instalación de majordomo (ver el manual de instalación y configuración de majordomo). Como majordomo a través de su programa wrapper cambia arbitrariamente la línea From, sendmail advierte esto como un posible problema de seguridad, por lo que (en su instalación por defecto) nos advertirá con un X-Authentication-Warning. Si queremos evitar esto, NO debemos eliminar los chequeos de seguridad, ni tampoco relajarlos, simplemente deberemos agregar a majordom a la lista de trusted users (si no lo hacemos indicándolo en m4, lo podemos hacer en /etc/sendmail.ct si es que definimos esta opción). Tener en cuenta que la utilización de programas como majordomo, de estar mal configurados, comprometerían seriamente la seguridad del sistema, por lo que es aconsejable testear bien su configuración y funcionamiento correcto antes de agregarlo como trusted al sendmail. Acordarse de agregar en el alias la línea


majordomo: majordom

Testeo de la instalación y puesta en marcha

Una vez que hayamos terminado de configurarlo, tendremos nuestro binario en un directorio ${SENDMAIL}/src/obj.${OSTYPE.VERSION}/ y nuestra configuración en ${SENDMAIL}/cf/cf/sendmail.cf; existen varias formas de probar que funcione correctamente. Antes de proceder con cualquier testeo, es aconsejable que primero desactivemos el viejo servidor SMTP. Una forma de testearlo es poniéndolo en modo test, para esto se debe ejecutar desde el directorio donde se encuentra el binario:


./sendmail -bt -C../../cf/sendmail.cf

Si se quiere una prueba más real, ejecutarlo en modo daemon:


./sendmail -bd -C../../cf/sendmail.cf

Una vez que nos hayamos asegurado que está funcionando correctamente y como esperamos, desde el directorio ${SENDMAIL}/src simplemente ejecutar:


./Build install

Una vez hecho esto, acordarse de copiar el sendmail.cf a /etc.

Hecho esto, deberemos asegurarnos que en los archivos de inicialización esté la opción que llama en modo daemon al sendmail. En los Linux con inits estilo BSD (Linux slackware), deberemos ver /etc/rc.d/rc.M, de no estar aquí o en ningún otro de los rc.*, deberíamos agregarlo en /etc/rc.d/rc.local (asegurarse que quede con el modo 700 o 755). En los sistemas tipo System V (Solaris), la inicialización se encuentra en /etc/init.d, los archivos ahí contenidos tienen hard-links a otros directorios (por ejemplo a /etc/rcS.d /etc/rc0.d /etc/rc2.d), con la nomenclatura K o S de acuerdo a si es para el stop o el start. Para sendmail existe un script /etc/init.d/sendmail, asegurarse que esté el link correspondiente al directorio de inicialización correcto para el modo multiusuario (por defecto, en nuestro caso es /etc/rc2.d/S88sendmail). Para cargar sendmail en los Unix estilo System V sólo deberemos utilizar /etc/init.d/sendmail start, y para bajarlo /etc/init.d/sendmail stop (la inicialización de este estilo de Unix es ventajosa debido a esto, la BSD es mucho más sencilla, pero sin esta ventaja). Si estamos en BSD (Linux slackware), deberemos matar y cargar manualmente, tener en cuenta al matar el sendmail, que pueden quedar otros procesos sendmail ejecutándose aún después de matar al parent, por lo que es recomendable matar todo lo relacionado a sendmail.

Lecturas recomendadas

Simple Mail Transport Protocol (RFC821).
Standard for the Format of ARPA Internet Text Messages (RFC822).
Domain Naming Convention for Internet User Applications (RFC819).
UUCP Mail Interchange Format Standard (RFC976).
Extensions to RFC821 and RFC822 (RFC1123).
Multipurpose Internet Mail Extensions (RFC1521, RFC1522).
Extensions to SMTP (RFC1651, RFC1652, RFC1653).
SMTP Service Extension for Delivery Status Notifications (RFC1891, RFC1892, RFC1893, RFC1894).
The Waite Group's Unix Communications (Bart Anderson, Bryan Costales and Harry Henderson; Sams).
sendmail (Bryan Costales with Eric Allman & Neil Rickert; O'Reilly).
NEW SENDMAIL CONFIGURATION FILES (Eric Allman)