Direcciones IPv6 que causan que las lists blancas de Exchange Relay fallen

Varios de nuestros nuevos serveres de Exchange están fallando en retransmitir posts porque se está comunicando a través de IPv6 y no coincide con ningún conector de recepción que configuré previamente. No estoy seguro de cómo estamos utilizando IP6 ya que sólo tenemos una networking IPv4 y estamos routing a través de subnetworkinges.

Descubrí esto escribiendo helo de la fuente al server que está confundido por mi dirección IP6. Vi el post IPv6 y el post personalizado que le di a este conector de recepción. (conectores con más permiso tienen un helo diferente)

 220 HUB01 client helo asdf 250 HUB01.nfp.com Hello [fe80::cd8:6087:7b1e:99d4%11] 

Más información sobre mi entorno:

Tengo dos bosques dedicados del intercambio cada uno con un propósito distinto. No tienen confianza y sólo se comunican por SMTP. Ambos comparten la misma infraestructura de DNS a través de zonas de stub.

¿Cuáles son mis opciones? Esta es mi suposition, pero no soy experto IPv6, así que no sé cuál es la mejor opción

  • Deshabilitar IPv6
  • Agregue la dirección IPv6 a la list blanca (¿no es esa dinámica IP?)
  • Dígale a Exchange que use IPv4 en su lugar
  • Descubra por qué estamos usando IPv6 en lugar de IP4

2 Solutions collect form web for “Direcciones IPv6 que causan que las lists blancas de Exchange Relay fallen”

Sus serveres deben estar en la misma subnetworking, ya que están utilizando direcciones IPv6 de enlace local para comunicarse, y probablemente DNS de multidifusión para hacer la resolución de nombres. IPv6 siempre se prefiere a IPv4 cuando se encuentra trabajando en serveres Windows 2008 o posteriores, y está habilitado de forma pnetworkingeterminada.

Puede deshabilitar IPv6 para deshacerse de esto, pero sería mejor implementar realmente IPv6 si puede. El mundo está fuera de las direcciones IPv4, en caso de que no haya escuchado.

En IPv6, las direcciones en la subnetworking fe80::/10 son direcciones de enlace local , ( RFC 4291 ) y se asignan automáticamente en cualquier interfaz en la que IPv6 está habilitado (que es por defecto en cualquier sistema operativo moderno). Estos son más o less comparable a IPv4 169.254.0.0/16 direcciones de enlace local ( RFC 3927 ), excepto que en IPv6, cada interfaz siempre tiene una dirección de enlace local.

Estas direcciones sólo se pueden utilizar en la misma subnetworking; que no están destinados a ser enrutados, y cualquier medio decente router ni siquiera hacer el bash. Tampoco pueden ser inhabilitados; se utilizan para el descubrimiento de vecinos, DHCPv6 y varios otros internos de IPv6.

Por eso es relativamente seguro añadir fe80::/10 a tu list blanca, para aceptar conexiones desde cualquier host de tu subnetworking.

  • Sendmail agrega X-Authentication-Warning para usuarios de confianza?
  • Exchange 2010 - no se puede enviar a un dominio específico - Se ha producido una caída de la connection 421 debido al error de socket
  • Enviar correo electrónico desde el dominio principal usando exim4
  • Me pregunto qué mecanismos aparte de senderID están disponibles para ayudar a detener la suplantación de una dirección desde: de su dominio
  • Recepción de correos electrónicos en CentOS 5, Postfix
  • Simple Mail Server en Arch Linux
  • La secuencia de commands PHPMailer dejó de funcionar con posts de error SMTP crípticos
  • Postfix sólo entrega el correo localmente (en lugar del destino correcto)
  • Configurar un enrutador para recibir packages SMTP y reenviarlo a un relé SMTP de terceros
  • utilizando gmail como su proveedor de alojamiento de correo electrónico?
  • postfix descartar o cambiar el encabezado de ID de post basado en otra línea de encabezado
  • postfix no va a direccionar en el mismo dominio con gmail
  • Comando HELO rechazado: necesita un nombre de host completamente calificado
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.