La orden m4 procesa los ficheros de definición de la macro de acuerdo a sus propias reglas de sintaxis sin entender nada sobre la corrección de la sintaxis de sendmail; así que no debería haber ningún mensaje de error si tiene algo equivocado en el fichero de definición de macros. Por esta razón, es muy importante que pruebe su configuración. Afortunadamente, sendmail proporciona una manera relativamente fácil de hacer esto.
sendmail soporta un modo de “prueba de direcciones” que nos permite probar nuestra configuración e identificar cualquier error. En este modo de operación, invocamos sendmail desde la línea de órdenes, y él mismo nos pide una especificación del conjunto de reglas y una dirección de destino. sendmail entonces procesa esa dirección de destino usando las reglas especificadas, mostrando la salida de cada regla de reescritura mientras se realiza. Para poner sendmail en este modo, lo invocamos con el argumento –bt:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> |
El fichero de configuración usado por omisión es el fichero /etc/mail/sendmail.cf; puede especificar uno alternativo usando el argumento –C. Para probar nuestra configuración, necesitamos seleccionar varias direcciones para procesar que nos dirán que cada uno de los requerimientos de manipulación del correo se encuentran. Para ilustrar esto, trabajaremos a través de nuestra configuración UUCP más complicada mostrada en Ejemplo 18-2.
Primero, probaremos que sendmail es capaz de entregar correo a los usuarios locales del sistema. En estas pruebas, todas las direcciones serán reescritas al transporte de correo local en esta máquina:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac
rewrite: ruleset 3 input: isaac
rewrite: ruleset 96 input: isaac
rewrite: ruleset 96 returns: isaac
rewrite: ruleset 3 returns: isaac
rewrite: ruleset 0 input: isaac
rewrite: ruleset 199 input: isaac
rewrite: ruleset 199 returns: isaac
rewrite: ruleset 98 input: isaac
rewrite: ruleset 98 returns: isaac
rewrite: ruleset 198 input: isaac
rewrite: ruleset 198 returns: $# local $: isaac
rewrite: ruleset 0 returns: $# local $: isaac |
Esta salida nos muestra cómo sendmail procesa el correo dirigido a isaac en este sistema. cada línea nos muestra qué información ha sido suministrada a un conjunto de reglas o el resultado obtenido del procesamiento por un conjunto de reglas. Le dijimos a sendmail que deseábamos emplear el conjunto de reglas 3 y 0 para procesar la dirección. El conjunto 0 es lo que se invoca normalmente y nosotros forzamos el conjunto 3 porque no se comprueba por omisión. La última línea nos muestra que el resultado del conjunto 0 en efecto reenvía el correo a isaac al transporte de correo local.
Lo siguiente que comprobaremos es el correo dirigido a nuestra dirección SMTP: isaac@vstout.vbrew.com. Deberíamos ser capaces de producir el mismo resultado final como en nuestro ejemplo último:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac@vstout.vbrew.com
rewrite: ruleset 3 input: isaac @ vstout . vbrew . com
rewrite: ruleset 96 input: isaac < @ vstout . vbrew . com >
rewrite: ruleset 96 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 3 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 0 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 98 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 98 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 returns: $# local $: isaac
rewrite: ruleset 0 returns: $# local $: isaac |
Otra vez la prueba se pasó. Lo siguiente es probar el correo a nuestra dirección estilo UUCP: vstout!isaac.
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 vstout!isaac
rewrite: ruleset 3 input: vstout ! isaac
rewrite: ruleset 96 input: isaac < @ vstout . UUCP >
rewrite: ruleset 96 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 3 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 0 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 98 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 98 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 returns: $# local $: isaac
rewrite: ruleset 0 returns: $# local $: isaac |
Esta prueba también se pasó. Estas pruebas confirman que cualquier correo recibido para los usuarios locales en nuestra máquina será entregado apropiadamente sin importar cómo está formateada la dirección. Si ha definido cualquier alias en su máquina, como hospedajes virtuales, debería repetir estas pruebas para cada uno de los nombres alternativos por los que este anfitrión se conoce para asegurarse que también funcionan correctamente.
Después, probaremos que el correo dirigido a otros anfitriones en el dominio vbrew.com se entregan directamente a ese anfitrión usando el transporte de correo SMTP:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac@vale.vbrew.com
rewrite: ruleset 3 input: isaac @ vale . vbrew . com
rewrite: ruleset 96 input: isaac < @ vale . vbrew . com >
rewrite: ruleset 96 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset 3 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset 0 input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 199 input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 199 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset 98 input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 98 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset 198 input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 198 returns: $# smtp $@ vale . vbrew . com . /
$: isaac < @ vale . vbrew . com . >
rewrite: ruleset 0 returns: $# smtp $@ vale . vbrew . com . /
$: isaac < @ vale . vbrew . com . > |
Podemos ver que esta prueba ha dirigido el mensaje al transporte SMTP para ser reenviado directamente al anfitrión vale.vbrew.com y especifica el usuario isaac. Esta prueba confirma que la definición LOCAL_NET_CONFIG funciona correctamente. Para que esta prueba sea satisfactoria, el nombre del anfitrión de destino debe ser resuelto correctamente, así que debe tener una entrada en nuestro fichero /etc/hosts, o en nuestro DNS local. Podemos ver qué ocurre si el nombre del anfitrión de destino no es capaz de resolverse especificando intencionadamente un anfitrión desconocido:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac@vXXXX.vbrew.com
rewrite: ruleset 3 input: isaac @ vXXXX . vbrew . com
rewrite: ruleset 96 input: isaac < @ vXXXX . vbrew . com >
vXXXX.vbrew.com: Name server timeout
rewrite: ruleset 96 returns: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 3 returns: isaac < @ vXXXX . vbrew . com >
== Ruleset 3,0 (3) status 75
rewrite: ruleset 0 input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 199 input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 199 returns: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 98 input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 98 returns: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 198 input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 95 input: < uucp-new : moria > isaac </
@ vXXXX . vbrew . com >
rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac </
@ vXXXX . vbrew . com >
rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac </
@ vXXXX . vbrew . com >
rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac </
@ vXXXX . vbrew . com > |
Este resultado es muy diferente. Primero el conjunto de reglas 3 devuelve un mensaje de error indicando que el nombre del anfitrión no se pudo resolver. segundo, tratamos esta situación delegando en la otra característica clave de nuestra configuración: el anfitrión inteligente. El anfitrión inteligente estará para manipular cualquier correo que no se pueda entregar de otra manera. El nombre del anfitrión que especificamos en esta prueba era incapaz de ser resuelto y los conjuntos de reglas determinaron que el correo debería ser reenviado a nuestro anfitrión inteligente moria usando el transporte de correo uucp-new. Nuestro anfitrión inteligente quizá esté mejor conectado y sepa qué hacer con la dirección.
Nuesta prueba final asegura que cualquier correo dirigido a un anfitrión que no esté dentro de nuestro dominio se entrega a nuestro anfitrión inteligente. Esto debería producir un resultado similar a nuestro ejemplo previo:
# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac@linux.org.au
rewrite: ruleset 3 input: isaac @ linux . org . au
rewrite: ruleset 96 input: isaac < @ linux . org . au >
rewrite: ruleset 96 returns: isaac < @ linux . org . au . >
rewrite: ruleset 3 returns: isaac < @ linux . org . au . >
rewrite: ruleset 0 input: isaac < @ linux . org . au . >
rewrite: ruleset 199 input: isaac < @ linux . org . au . >
rewrite: ruleset 199 returns: isaac < @ linux . org . au . >
rewrite: ruleset 98 input: isaac < @ linux . org . au . >
rewrite: ruleset 98 returns: isaac < @ linux . org . au . >
rewrite: ruleset 198 input: isaac < @ linux . org . au . >
rewrite: ruleset 95 input: < uucp-new : moria > isaac </
@ linux . org . au . >
rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac </
@ linux . org . au . >
rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac </
@ linux . org . au . >
rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac </
@ linux . org . au . > |
Los resultados de esta prueba indican que el nombre del anfitrión se resolvió, y que el mensaje podría ser encaminado a nuestro anfitrión inteligente. Esto prueba que nuestra definición LOCAL_NET_CONFIG funciona correctamente y que manejó ambos casos correctamente. Esta prueba es también exitosa, así que podemos felizmente asumir que nuestra configuración es correcta y usarla.