Probablemente se deba a que la máquina de correo se encuentra en un dominio diferente; si por ejemplo la máquina de correo se encuentra en foo.bar.edu y se desea alcanzar una máquina llamada mumble en el dominio bar.edu se tiene que referir a ella mediante un nombre de dominio completo (“fully-quailified domain name” o FQDN), en éste caso mumble.bar.edu en lugar de referirse a ella simplemente como mumble.

Tradicionalmente, la referencia incompleta era posible utilizando “resolvers” de BSD BIND. No obstante la versión de BIND que en la actualidad se ofrece con FreeBSD ya no permite por defecto el uso de dichas abreviaturas salvo para aquellas máquinas que pertenecen al dominio al que su sistema pertenezca. Una máquina como mumble será buscada como mumble.foo.bar.edu o la búsqueda será redireccionada al servidor de dominio raíz del DNS.

Esto es distinto a lo que ocurría en versiones anteriores de BIND, donde la búsqueda se producía a través de mumble.bar.edu y de mumble.edu. Se recomienda consultar a la RFC 1535 para conocer el motivo que se considerara una práctica errónea o incluso un agujero de seguridad.

Una buena solución a este problema puede ser incluír la siguiente línea

search foo.bar.edu bar.edu

en lugar de

domain foo.bar.edu

dentro del fichero /etc/resolv.conf. No obstante se debe asegurar de que el orden de búsqueda no se expande más allá del “límite entre la administración local y la administración pública”, tal y como se le denomina en la RFC 1535.

Esta pregunta se responde en las FAQ de sendmail de la siguiente forma:

Estoy obteniendo los siguientes mensajes de error:

553 MX list for domain.net points back to relay.domain.net
554 <user@domain.net>... Local configuration error

¿Cómo puedo solucionar esto?

Usted ha especificado que el correo para el dominio (por ejemplo,
para el dominio dominio.net) sea reenviado a una máquina determinada
(en este caso relay.dominio.net), para lo que se utiliza un registro
de DNS de tipo MX,
pero la máquina que actúa de relay no se
reconoce a sí misma como perteneciente al dominio dominio.net.
Se debe añadir dominio.net al fichero /etc/mail/local-host-names,
que recibe el nombre de /etc/sendmail.cw en versiones de sendmail previas
a la 8.10.  Se puede utilizar la macro FEATURE(use_cw_file) para indicar
dónde se encuentra el fichero local-host-names; también se
puede añadir “Cw dominio.net” directamente
al fichero /etc/mail/sendmail.cf
         

Las FAQ de sendmail se pueden encontrar en http://www.sendmail.org/faq/ y son de lectura obligada si se quiere depurar el comportamiento y la configuración de sendmail.

Se quiere conectar una máquina FreeBSD dentro de una LAN a Internet. La máquina FreeBSD será una pasarela de correo para dicha LAN. La conexión mediante PPP no es dedicada.

Existen al menos dos formas distintas de hacerlo. Una de ellas consiste en utilizar UUCP.

Otra forma consiste en hacerse con un servidor de internet a tiempo completo para proporcionar servicios de agente de transporte secundario para nuestro dominio. Si por ejemplo el dominio de nuestra compañía es ejemplo.com, nuestro proveedor de acceso a internet puede instalar lo siguiente en el DNS:

ejemplo.com.          MX        10      ejemplo.com.
                      MX        20      ejemplo.net.

Nótese que el agente de correo primario es nuestro dominio, ejemplo.com, y además se encuentra configurado un agente de transporte secundario en la máquina ejemplo.net. En este caso sólamente se debe especificar una máquina como receptor final de correo (añadiendo Cw ejemplo.com) al fichero /etc/mail/sendmail.cf de la máquina example.com)

Cuando el sendmail que está enviando el correo trata de entregar dicho correo primero intentará conectarse con nosotros (ejemplo.com) utilizando el enlace de modem. Lo más probable es que la operación termine después de un tiempo de espera debido a que el enlace modem esté caído. La aplicación sendmail automáticamente entregará el correo al servidor especificado como agente de transporte de correo secundario (segundo registro MX), es decir, entregará el correo a nuestro proveedor de servicios de internet (ejemplo.net). El sitio MX secundario tratará de conectarse con nuestra máquina de una forma periódica con el objeto de entregar el correo a la máquina que actúa como agente servidor de correo primario (ejemplo.com).

Puede ser de mucha utilidad un script de “login” como el que se muestra a continuación:

#!/bin/sh
# Ponme en /usr/local/bin/pppmiconexion
( sleep 60 ; /usr/sbin/sendmail -q ) &
/usr/sbin/ppp -direct pppmiconexion

Si vamos a crear un script de “login” separado para un usuario determinado se puede utilizar sendmail -qRejemplo.com en lugar del script anterior. Esto obliga a que se procesen de forma inmediata todos los correos que se encuentren en la cola de ejemplo.com.

Vamos a dar una vuelta más de tuerca a la situación:

Mensaje robado a la lista de correo de Proveedores de Servicios de Internet en FreeBSD.

> Nosotros proporcionamos servicio de MX secundario a un cliente nuestro.
> El cliente se conecta a nuestro servidor varias veces al día
> de  forma automática para recoger sus correos para almacenarlos en
> su servidor MX primario (nosotros no llamamos a su organización
> justo cuando nos llega un correo suyo).
> Nuestro sendmail envía la cola de correos cada 30 minutos. En
> estos momentos nuestro cliente tiene que estar al menos 30 minutos
> conectado para asegurarnos de que todo su correo ha sido enviado al
> servidor MX primario.
>
> ?Existe algún comando que permita indicar a sendmail que
> envíe todos los correos de la cola cuando quiera el cliente?
> El cliente no tiene permisos de superusuario en la máquina que
> alberga nuestro agente de transporte, por supuesto.

En la sección de “privacy flags” del fichero sendmail.cf
existe una definición como ésta:
Opgoaway,restrictqrun

Basta con eliminar restrictqrun para permitir que usuarios sin permisos de
superusuario arranquen el procesamiento de la cola.
Sería conveniente además que reordenaran los registros MX.
Nosotros somos el primer MX para nuestros clientes.
Además de esto hay que especificar:

# Si somos el mejor MX para una determinada máquina, intenta
# utilizarnos directamente en vez de generar un error de
# configuración local.
OwTrue

en el archivo de configuración de sendmail.
Mediante la configuración anterior,
una organización remota entregará sus correos directamente a
usted, sin necesidad de intentar conectarse primero a través de
la conexión del cliente.  La etiqueta "OwTrue" se necesita para evitar
que sendmail genere un mensaje de error.
A continuación ustedes se encargan de entregar el
correo a su(s) respectivo(s) cliente(s) tal como vienen haciendo.

Esta configuración sólo funciona para
“máquinas individuales”,
de tal forma que se necesita que el cliente especifique su servidor de correo
mediante entradas de tipo A en el DNS.  En concreto se necesita una entrada de
tipo A en el DNS para el dominio del cliente (“cliente.com”).

En las instalaciones del sistema FreeBSD por defecto sendmail se configura para enviar correo sólamente desde la máquina en la cual se está ejecutando. Por ejemplo si un servidor POP está disponible los usuarios serán capaces de consultar su correo desde la universidad, el trabajo u otras localizaciones remotas, pero dichos usuarios podrán enviar correo desde dichas ubicaciones. Es habitual que unos instantes después del envío del correo dichos usuarios reciban un mensaje proveniente del MAILER-DAEMON con un error como 5.7 Relaying Denied.

Existen varias formas de solventar este problema. La más sencilla consiste en escribir la dirección IP de su proveedor de servicios dentro del fichero /etc/mail/relay-domains. Una forma rápida de hacerlo sería:

# echo "un.isp.ficticio.com" > /etc/mail/relay-domains

Después de crear o editar dicho fichero se debe reiniciar sendmail. Esto funciona perfectamente si usted es el administrador del servidor y no desea enviar correo localmente o si prefiere utilizar un cliente de correo o cualquier otro sistema en otra máquina distinta a la que alberga el servidor de correo. Es muy útil sobre todo cuando sólamente se tienen una o dos direcciones de correo eletrónico. Si hay en liza un gran número de direcciones de correo, edite el fichero anterior con su editor de texto favorito y añada uno a uno los correspondientes dominios.

un.isp.ficticio.com
otro.isp.ficticio.net
y.otro.isp.ficticio.org
www.ejemplo.org

Ahora, cualquier correo enviado a través de su sistema por cualquier máquina que se encuentre en este fichero (siempre y cuando el usuario tenga una cuenta en nuestro sistema) podrá ser enviado con éxito. Es una manera elegante de permitir a los usuarios enviar correo eletrónico desde nuestro servidor de correo sin permitir al resto del mundo que haga lo mismo (lo que se conoce como SPAM).