Es argumentable que la caracter�stica m�s poderosa de sendmail es la regla de reescritura. Las reglas de reescritura son usadas por sendmail para determinar c�mo procesar un manseje de correo recibido. sendmail pasa las direcciones desde las cabeceras de un mensaje de correo a trav�s de colecciones de reglas de reescritura llamadas conjuntos de reglas. Las reglas de reescritura transforman una direcci�n de correo de una forma a otra y puede pensar en ellas como algo similar a una orden en su editor que reemplaza todo el texto que encaje en un patr�n especificado con otro.
Cada regla tiene un lado izquierdo y un lado derecho, separados por al menos un car�cter de tabulaci�n. Cuando sendmail est� procesando correo, busca a trav�s de las reglas de reescritura intentando encontrar una coincidencia con el lado izquierdo. Si una direcci�n coincide con una de las reglas del lado izquierdo, la direcci�n es reemplazada por la del lado derecho y es procesada de nuevo.
En el fichero sendmail.cf, los conjuntos de reglas son definidos usando �rdenes codificadas como Sn, donde n especifica el conjunto de reglas que se considera el actual.
Las reglas por s� mismas aparecen en �rdenes codificadas como R. Cuando cada orden R es le�da , se a�ade al conjunto de reglas actual.
Si est� tratando s�lo con el fichero sendmail.mc, no necesita preocuparse acerca de las �rdenes S para nada, ya que las macros construir�n �stas por usted. Necesitar� codificar manualmente las reglas R.
Un conjunto de reglas de sendmail entonces tiene la siguiente apariencia:
Sn
Rlhs rhs
Rlhs2 rhs2 |
sendmail utiliza internamente unas cuantas definiciones de macro estandarizadas. Las m�s �tiles de �stas en la escritura de conjuntos de reglas son:
El nombre completamente cualificado de este anfitri�n (FQDN).
El componente del anfitri�n del FQDN.
El componente del dominio del FQDN.
Podemos incorporar estas definiciones de macros en nuestras propias reglas de reescritura. Nuestra configuraci�n de la Cervecera Virtual utiliza la macro $m.
A la izquierda de una regla de reescritura, hay que especificar un patr�n que coincida con una direcci�n que desee transformar. La mayor�a de los caracteres se les hace coincidir literalmente, pero hay un n�mero de caracteres que tienen significado especial; estos se describen en la lista siguiente. Las reglas de reescritura para el lado izquierdo son:
Coinciden exactamente cero s�mbolos
Coinciden cero o m�s s�mbolos
Coincide uno o m�s s�mbolos
Coincide exactamente un s�mbolo
Coindice cualquier frase en la clase x
Coincide con cualquier palabra que no est� en la clase x
Un s�mbolo es una tira de caracteres delimitados por espacios. No hay manera de incluir espacios en un s�mbolo, o no es necesario como los patrones de expresiones son suficientemente flexibles para atajar esta necesidad. Cuando una regla coincide con una direcci�n, el texto que coincide con cada uno de los patrones en la expresi�n ser� asignado a variables especiales que se usar�n en la parte derecha. La �nica excepci�n a esto es con el literal $@, que no coincide con ning�n s�mbolo y entonces nunca generar� texto para ser usado en el lado derecho.
Cuando el lado izquierdo de una regla de reescritura coincide con una direci�n, el texto original se borra y se reemplaza por lo que haya en el lado derecho de la regla. Todos los s�mbolos en el lado derecho son copiados literalmente , a no ser que comiencen por el signo del d�lar. De la misma manera que en el lado izquierdo, unos cuantos metas�mbolos pueden usarse en el lado derecho. Estos son descritos en la siguiente lista. Las reglas de reescritura para el lado derecho son:
Este metas�mbolo es reemplazado por la expresi�n n�sima del lado izquierdo.
Este metas�mbolo resuelve el nombre del anfitri�n a nombre can�nico. Es reemplazado por la forma can�nica del nombre del anfitri�n suministrado.
Esta es la forma m�s general de b�squeda. La salida es un resultado de mirar la clave en el mapa nombrado map pas�ndole argum como argumentos. El mapa puede ser cualquiera de los mapas que sendmail soporta como el virtusertable que describimos un poco m�s tarde. Si la b�squeda es infructuosa, por omisi�n ser� la salida. Si no se suministra nada por omisi�n y la b�squeda falla, la entrada no se altera y la clave es la salida.
Esto har� que el resto de esta l�na sea analizada y entonces dada al conjunto de reglas n para ser evaluada. La salida del conjunto de reglas llamado se escribir� como salida a esta regla. �ste es el mecanismo que permite a las reglas invocar otras reglas.
Este metas�mbolo hace que la evaluaci�n del conjunto de reglas se detenga y especifica el transporte que deber� usarse para transportar este mensaje en el siguiente paso de su entrega. Este metas�mbolo deber�a ser llamado s�lo desde el conjunto de reglas 0 o una de sus subrutinas. Esta es la parte final del an�lisis de direcciones y deber�a ser acompa�ado de los dos siguientes metas�mbolos.
Este metas�mbolo especifica el anfitri�n al que este mensaje ser� reenviado. Si el anfitri�n destinatario es el anfitri�n local, puede omitirse. El host puede ser una lista de anfitriones de destino separada por dos puntos (:) que a los que se intentar� entregar el mensaje en secuencia.
Este metas�mbolo especifica el usuario destinatario para el mensaje de correo.
Una regla de reescritura que coincide se intenta repetidamente hasta que falla una coincidencia, entonces el an�lisis contin�a en la sigiente regla. Este comportamiento puede cambiarse precediendo el lado derecho con uno de dos metas�mbolos especiales descritos en la siguiente lista. Las reglas de reescritura para el control del bucle del lado derecho son:
Este metas�mbolo causa que el conjunto de regles retorne con el resto del lado derecho como el valor. Ninguna otra regla del conjunto se eval�a.
Este metas�mbolo causa que esta regla finalice inmediatamente, pero el resto del conjunto de reglas actual es evaluado.
Para ver mejor c�mo funcionan las macros de sustituci�n de patrones, considere la siguiente regla de lado izquierdo:
$* < $+ > |
Esta regla coincide con “Cero o m�s s�mbolos, seguidos por el car�cter <, seguidas a su vez por una o m�s s�mbolos, seguidos por el car�cter >. ”
Si esta regla fuese aplicada a [email protected] o Head Brewer < >, la regla no coincidir�a. La primera cadena no coincidir�a porque no incluye el car�cter <, y la segunda fallar�a porque $+ coincide con uno o m�s s�mbolos y no hay s�mbolos entre los caracteres <>. En cualquier caso en que una regla co coincida, el lado derecho de la regla no se usa.
Si la regla fuera aplicada a Head Brewer < [email protected] >, la regla coincidir�a, y en el lado derecho $1 ser�a sustituido por Head Brewer y $2 ser�a sustituido por [email protected].
Si la regla fuese aplicada a < [email protected] > la regla coincidir�a porque $* coincide con cero o m�s s�mbolos, y en el lado derecho $1 podr�a ser sustituido por la cadena vac�a.
Cada uno de los conjuntos de reglas de sendmail se les llama para realizar una tarea distinta en el procesado del correo. Cuando se est�n escribiendo reglas, es importante entender qu� se espera que cada uno de los conjuntos de reglas haga. Vamos a echar un vistazo a cada uno de los conjuntos de reglas que los guiones de configuraci�n m4 nos permiten modificar:
El conjunto 3 es responsable de convertir una direcci�n en un formato arbitrario en un formato com�n quesendmail procesar�. El formato de salida esperado es el aspecto familiar parte-local@especificaci�n-anfitri�n-dominio.
El conjunto 3 deber�a poner la parte del nombre del anfitri�n de la direcci�n convertida entre los caracteres < y > para hacer el an�lisis de las siguientes reglas m�s f�cil. El conjunto de reglas 3 se aplica antes que sendmail haga cualquier otro procesamiento de una direcci�n de correo, as� que si quiere que sendmail haga de pasarela de correo desde alg�n sistema que utilice alg�n formato de direcci�n poco usual, se deber�a a�adir una regla usando la macro LOCAL_RULE_3 para convertir direcciones en el formato com�n.
El conjunto 0 se aplica por sendmail a las direcciones del destinatario tras el conjunto de reglas 3. La macro LOCAL_NET_CONFIG provoca que las reglas sean introducidas en la mitad inferior del conjunto 0.
El conjunto 0 se espera que realice la entrega del mensaje al destinatario, as� que debe resolver un triplete que especifica el correo, el anfitri�n y el usuario. Las reglas ser�n colocadas antes de cualquier definici�n de anfitri�n inteligente que quiera incluir, as� que si a�ade reglas que resuelvan direcciones apropiadamente cualquier direcci�n que coincida con una regla no ser� tratada por el anfitri�n inteligente. As� es como tratamos los smtp directos para los usuarios de nuestra red local en nuestro ejemplo.
El conjunto 1 se aplica a todas las direcciones de remite y el conjunto 2 de aplica a todas las direcciones de destino. Ambos est�n normalmente vac�os.
Nuestro ejemplo en Ejemplo 18-3 usa la macro LOCAL_NET_CONFIG para declarar una regla local que asegure que cualquier correo dentro de nuestro dominio se entregue directamente usando el transporte de correo smtp. Ahora que sabe c�mo se construyen las reglas de reescritura, es capaz de entender c�mo funciona esta regla. Ech�mosle un vistazo.
Ejemplo 18-3. Regla de reescritura desde vstout.uucpsmtp.m4
LOCAL_NET_CONFIG
# Esta regla se asegura de que todo correo local sea entregado usando el
# transporte smtp, todo lo dem�s ir� por el anfitri�n inteligente.
R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3 |
Sabemos que la macro LOCAL_NET_CONFIG har� que la regla se introduzca en alg�n lugar cerca del final del conjunto de reglas 0, pero antes de cualquier definici�n del anfitri�n inteligente. Sabemos tambi�n que el conjunto 0 es el �ltimo conjunto en ser ejecutado y que deber�a resolver un triplete especificando transporte de correo, usuario y anfitri�n.
Podemos ignorar las dos l�neas de comentariso; no hacen nada �til. La regla en s� misma es la l�nea que comienza con R. Sabemos que la R es una instrucci�n de sendmail y que a�ade esta regla al conjunto de reglas actual, en este caso el conjunto 0. Miremos al lado izquierdo y al lado derecho que devuelve.
El lado izquierdo es como �ste: $* < @ $* .$m. > $*.
El conjunto 0 espera los caracteres < y > porque es alimentado por el conjunto 3. El conjunto 3 convierte direcciones en una forma com�n y para hacer el an�lisis m�s f�cil, coloca la parte del anfitri�n de la direcci�n de correo entre < y >.
Esta regla coincide con cualquier direcci�n que parecezca como: 'UsuarioDestino < @ cualquieranfitri�n.nuestrodominio. > Alg�n Texto'. Esto es, coincide con el correo de cualquier usuario y de cualquier anfitri�n dentro de nuestro dominio.
Recordar� que el texto que coincide con los metas�mbolos en el lado izquierdo de una regla de reescritura se asigna a definiciones de macro para su uso en el lado derecho. En nuestro ejemplo, el primer $* coincide con todo el texto desde el inicio de la direcci�n hasta el car�cter <. Todo este texto se asigna al $1 para su uso en el lado derecho. Similarmente, el segundo $* en nuestra regla de reescritura se asigna a $2, y el �ltimo se asigna a $3.
Ahora tenemos suficiente para entender el lado izquierdo. Esta regla coincide con el correo de cualquier usuario en cualquier anfitri�n dentro de nuestro dominio. Asigna el nombre de usuario a $1, el nombre del anfitri�n a $2, y cualquier texto subsiguiente a $3. El lado derecho se invoca entonces para procesar �stos.
Echemos un vistazo a aquello que estamos esperando ver a la salida. El lado derecho de nuestra regla de reescritura de ejemplo es semejante a: $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3.
Cuando la regla del lado derecho de nuestro conjunto de reglas se procesa, se interpreta cada uno de los metas�mbolos y se realizan las sustituciones correspondientes.
El metas�mbolo $# hace que esta regla resuelva un transporte espec�fico, smtp en nuestro caso.
El $@ resuelve el anfitri�n objetivo. En nuestro ejemplo, el anfitri�n objetivo se especifica como $2.$m., el cual es el nombre completamente cualificado del anfitri�n en nuestro dominio. El NDCC se construye con el componente del nombre del anfitri�n asignado a $2 desde nuestro lado izquierdo con nuestro nombre de dominio (.$m.) concatenado.
El metas�mbolo $: especifica el usuario objetivo, el cual se captura otra vez del lado izquierdo y se almacena en $1.
Preservamos los contenidos de la secci�n <> y cualquier texto acompa�ante, usando los datos que recogimos desde el lado izquierdo de la regla.
Debido a que esta regla resuelve a un transporte de correo, el mensaje es reenviado al transporte para su entrega. En nuestro exemplo, el mensaje ser�a reenviado al anfitri�n de destino usando el protocolo SMTP.