18.9. Probando la Configuraci�n

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: [email protected]. 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 [email protected]
    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 [email protected]
    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 [email protected]
    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 [email protected]
    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.