SecurityGateway para Email Servers Notas de la Versión v4.5

Desarrollado a lo largo de 20 años de experiencia, SecurityGateway proporciona seguridad accesible para su correo electrónico. Le protege contra spam, virus, phishing, spoofing y otras formas de malware que son una amenaza permanente para las comunicaciones legítimas de correo electrónico en su empresa.

Dé click aquí para saber más sobre SecurityGateway para Email Servers.

SecurityGateway 4.5.0 - Abril 4, 2017

CONSIDERACIONES ESPECIALES

[18161] La opción "Respeta método de autentificación CRAM-MD5" localizada en Ajustes / Usuarios | Configuración de Correo | Protocolo de Correo, se ha modificado a deshabilitada por omisión por razones de seguridad y técnicas. Es preferible utilizar TLS para evitar la transmisión de contraseñas visibles.

CAMBIOS Y NUEVAS FUNCIONALIDADES

CORRECCIONES

SecurityGateway 4.0.1 - Julio 26, 2016

CAMBIOS Y NUEVAS FUNCIONALIDADES

CORRECCIONES

SecurityGateway 4.0.0 - Junio 14, 2016

PRINCIPALES FUNCIONALIDADES NUEVAS

[15999] Se actualizó la interface web para utilizar un Diseño Responsivo Móvil

El soporte a navegadores se limita a IE10+, la versión mas reciente de Chrome, la versión más reciente de Firefox, y las versiones mas recientes de Safari en Mac y en iOS. Se sabe que algunos navegadores Android tienen problemas con el desplazamiento, sin embargo Chrome en dispositivos Android funciona bien.

Este diseño se basa completamente en el tamaño de la ventana en uso. Ya sea que el usuario utilice un teléfono, tableta o PC, la apariencia es la misma para el mismo tamaño de ventana. El cambio más importante aquí es el menú. Desde un ancho de 956 pixeles hacia abajo el menú se oculta a la izquierda del navegador. Se tienen dos métodos para desplegar el menú. Si se utiliza un dispositivo táctil, al deslizar con el dedo hacia la derecha se mostrará el menú secundario. Aún cuando no se utilice dispositivo táctil, también existe el botón "menú" en la esquina superior izquierda, que desplegará el menú secundario. Si se da un toque o clic en el título del menú con la flecha izquierda en la parte superior del menú se desplegará el menú principal. El menú Ayuda, Acerca de y Salir en la esquina superior derecha se modifica también con base en el ancho de la pantalla. De 768 pixeles hacia arriba se muestran las palabras Ayuda, Acerca de y Salir, de 481 pixeles a 767 pixeles solo se despliegan los íconos y de 480 pixeles o menos se despliega un ícono de "engrane" que desplegará un menú desplegable cuando se le toque o dé clic, con las opciones Ayuda, Acerca de y Salir. Las vistas de Listas con más de una columna cuentan con botone para habilitar/deshabilitar.

[11232] DMARC

Se agregó soporte para DMARC (Domain-based Message Authentication, Reporting, and Conformance). DMARC define un mecanismo escalable con el que una organización emisora de correo puede expresar, utilizando su DNS, políticas a nivel de dominio y preferencias para validación de mensajes disposición y reporteo; la organización receptora puede utilizar esas políticas y preferencias para mejorar el manejo del correo. La especificación DMARC y los detalles completos sobre lo que hace y como funciona se encuentran aquí: http://www.dmarc.org/.

DMARC permite a los usuarios de dominio expresar sus deseos concernientes al manejo de mensajes que pretenden provenir de su(s) dominio(s) pero que no fueron enviados por ellos. Las posibles opciones de política para el manejo de esos mensajes son "none" en cuyo caso SecurityGateway no ejecuta ninguna acción, "reject" en cuyo caso SecurityGateway rechaza la aceptación del mensaje durante la sesión SMTP misma y "quarantine" en cuyo caso SecurityGateway coloca el siguiente encabezado en cada mensaje para facilitar el filtrado en el mensaje de correo basura del usuario: "X-SGDMARC-Fail-policy: quarantine". Este encabezado solo se agrega cuando el resultado de la verificación DMARC es "fail" y la política DMARC resultante es distinta a "none." Es posible configurar SecurityGateway para aceptar mensajes aún cuando DMAC solicite que sean rechazados. De hecho, este es el modo operacional por omisión. En estos casos SecurityGateway colocará un encabezado "X-SGDMARC-Fail-policy: reject" en el mensaje en caso de que desee un filtrado mucho más serio.

DMARC sobrepasa ADSP y las funcionalidades SPF de disposición de mensajes. Sin embargo, puede utilizarlas todas junto con DMARC. Los rechazos de mensajes ADSP y SPF ahora se realizar después del procesamiento DMARC si la verificación DMARC se encuentra habilitada.

DMARC depende en parte del uso de una "Lista Pública de Sufijos" (Public Suffix List)." Un "Sufijo Público" es aquel en que los usuarios de Internet pueden registrar nombres directamente. Algunos ejemplos de sufijos públicos son .com, .co.uk y pvt.k12.ma.us. Una "Lista Pública de Sufijos" es una lista de todos los sufijos públicos conocidos. SecurityGateway utiliza la que mantiene la comunidad de Mozilla Foundation que se encuentra aquí: https://publicsuffix.org/. Se puede instalar una copia de esta lista en su carpeta \App\ con el nombre effective_tld_names.dat. Actualmente no existe una fuente comprehensiva o fuente única autoritativa para tal lista que pueda consultar la comunidad de Internet. En el tiempo este archivo se hará obsoleto y debe ser reemplazado descargando una copia más reciente desde https://publicsuffix.org/list/effective_tld_names.dat y colocándola en su carpeta \App\. SecurityGateway periódica y automáticamente descargará e instalará este archivo como parte del evento diario de mantenimiento aproximadamente cada dos semanas Varios controles que administran esto se pueden encontrar en las nuevas pantallas de configuración DMARC. El archivo de registro DMARC y una nueva ventana DMARC dentro de la pestaña Seguridad en la interface principal contienen los resultados de la actualización y todas las otras operaciones de procesamiento DMARC. Puede configurar una URL de descarga distinta si lo requiere pero los datos descargados deben conformarse al formato especificado por Mozilla en su archivo. Puede leer sobre esto en la URL mencionada arriba. SecurityGateway sigue estrictamente el algoritmo de segmentación especificado por Mozilla. Cree un archivo (posiblemente vacío) denominado "PUBLICSUFFIX.SEM" y colóquelo en la carpeta \App\ de SecurityGateway si reemplaza o edita el archivo effective_tld_names.dat y necesita que SecurityGateway lo cargue sin reiniciar la aplicación.

Para utilizar DMARC como emisor de correo debe publicar un registro DMARC TXT en el DNS de su dominio. Puede encontrar información sobre como definir y estructurar este registro en http://www.dmarc.org. Cuando publique un registro DMARC en su DNS puede empezar a recibir reportes DMARC de muchas fuente diferentes vía correo. Estos reportes se proporcionan en un archivo XML comprimido cuyo formato se define en la especificación DMARC. Consumir estos reportes está fuera del alcance de la implementación DMARC en SecurityGateway. Sin embargo, los datos dentro de estos reportes pueden proporcionar una visualización importante del flujo de correo del dominio, uso inapropiado del dominio, integridad de las firmas DKIM y exactitud/precisión de los valores SPF. Las direcciones a las que se envían estos reportes se configuran cuando crea su registro DMARC.

Al configurar un registro DMARC para uno o más de sus dominios tenga cuidado del uso del parámetro p=reject. Tenga particular cuidado si su dominio proporciona cuentas de correo en general para uso de usuarios humanos. Si tales usuarios se han inscrito en listas de correo, utilice un servicio de reenvío de correo o el hacer acciones comunes como "compartir este artículo con un amigo" será completamente imposible si su política DMARC es p=reject y seguramente se enterará de ello. DMARC p=reject es perfectamente apropiado y útil pero solo cuando se aplica en dominios que controlan la manera como se utilizan sus cuentas de correo (por ejemplo, cuentas de correo transaccional, o automatizado (no-humano), o para aplicar políticas corporativas contra el uso de las cuentas fuera de los límites organizacionales).

A fin de soportar el reporteo agregado DMARC, SecurityGateway almacenará datos que necesitará posteriormente a fin de generar reportes agregados de conformidad con la especificación DMARC. SecurityGateway ignora la etiqueta DMARC "ri="; y solo produce reportes agregados DMARC que cubren desde 00:00:00 UTC a 23:59:59 UTC para un día dado. A medianoche UTC (que no necesariamente es la medianoche de tiempo local) SecurityGateway consume sus datos almacenados para generar los reportes. SecurityGateway necesitar en ejecución en ese momento o los datos almacenados podrían incrementarse y nunca ser consumidos. Por esto, si no ejecuta SecurityGateway 24/7 no debe habilitar el reporteo agregado DMARC. Los reportes agregados DMARC se encuentran deshabilitados por omisión.

A fin de soportar el reporteo de fallas DMARC las disposiciones RFC 5965 "An Extensible Format for Email Feedback Reports", RFC 6591 "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652 "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6651 "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting" y RFC 6692 "Source Ports in Abuse Reporting Format (ARF) Reports" han sido implementadas totalmente. Los reportes de fallo se crean en tiempo real conforme ocurren los incidentes que los detonan. SecurityGateway implementa reportes de falla tipo DMARC AFRF y no reportes tipo IODEF. Por esto, solo los valores "afrf" en la etiqueta DMARC "rf=" tag se respetan. Vea la especificación DMARC para detalles completos. Se pueden generar múltiples reportes de falla a partir de un único mensaje dependiendo del número de destinatarios en el registro de la etiqueta DMARC "ruf=" y del valor del tag "fo=" tag por el número de fallos de autentificación independiente que se encuentren durante el procesamiento del mensaje. Cuando el tag DMARC "fo=" solicita reporteo de fallos relacionados SPF, SecurityGateway envía reportes de fallo SPF de acuerdo al RFC 6522. Por esto, las extensiones de esa especificación deben estar presentes en el registro SPF del dominio. Los reportes de fallo SPF no se envían independientemente del procesamiento DMARC o en la ausencia de las extensiones de la RFC 6522. Cuando el tag DMARC "fo=" solicita reporteo de fallos relativos a DKIM, SecurityGateway envía reportes de fallo DKIM y ADSP de acuerdo a la disposición RFC 6651. Por esto, las extensiones de esa especificación deben estar presentes en el campo del encabezado DKIM-Signature header y el dominio debe publicar un registro TXT de reporteo DKIM en su DNS y/o extensiones ADSP válidas en su registro TXT ADSP. Los reportes de fallos DKIM y ADSP no se envían independientemente del procesamiento DMARC o en ausencia de las extensiones del RFC 6651. Ver las varias especificaciones referidas aquí para detalles completos. El reporteo de fallos DMARC se encuentra deshabilitado por omisión.

Nota Importante: Un registro DMARC puede especificar que los reportes se deben enviar a un intermediario operando por parte del propietario del dominio. Esto se hace cuando el propietario del dominio contrata una entidad para monitorear los flujos de correo para detectar problemas de abuso y desempeño. La recepción por terceros de tales datos puede o no estar permitido por su política de privacidad, términos de uso o cualquier otra disposición gubernamental. Deberá revisar y entender si sus propias políticas internas restringen el uso y transmisión del reporteo DMARC y si es así deberá deshabilitar el reporteo DMARC.

DMARC requiere el uso de STARTTLS siempre que se ofrezca por los receptores de reporte, sin embargo no hay manera de predecir o controlar esto. Sin embargo, deberá habilitar STARTTLS si aún no lo ha hecho (ver Instalar / Usuarios | Sistema | Encriptación).

El encabezado Authentication-Results se ha ampliado para incluir los resultados del procesamiento DMARC. Note que Authentication-Results incluye algunos datos en comentarios para propósitos de depuración, incluyendo la política DMARC solicitada por el propietario del dominio que no es necesariamente la acción que se toma sobre el mensaje. Por ejemplo, cuando el resultado de una verificación DMARC es "pass" no importa que la política DMARC establece como política que solo se aplica a verificaciones DMARC con valor "fail". Similarmente, cuando el resultado de una verificación DMARC es "fail" y la política es "reject" el mensaje puede ser aceptado de todas maneras por razones de política local. El uso de este encabezado para filtrado deberá tomar todo esto en cuenta. Alternativamente, filtre por "X-SGDMARC-Fail-policy: quarantine" o "X-SGDMARC-Fail-policy: reject" para filtrar estos mensajes en las carpetas de spam o cualquier cosa que desee ejecutar. SecurityGateway toma el encabezado "X-SGDMARC-Fail-policy:" de todos los mensajes entrantes.

Los mensajes deben conformarse a la sección DMARC 15.1 con respecto al encabezado From de la RFC 5322 o no se procesan lo que básicamente significa que la ausencia de un (uno y solo uno) encabezado From formado correctamente (de acuerdo a las especificaciones RFC) hace que el mensaje se considere inválido generalmente y por esto inválido para procesamiento DMARC.

Se agregaron varias pantallas nuevas en Seguridad | Anti-Spoofing donde se pueden configurar varias opciones relativas al uso de DMARC.

DMARC requiere de la verificación SPF y/o DKIM para ser habilitado ya que se basa en las identidades verificadas que proporcionan esos dos mecanismos. No puede hacer uso productivo de DMARC para correo entrante sin que se encuentre habilitada una o ambas tecnologías. La interface gráfica forzará esto.

[3961] Ligar el dominio a una dirección IP

Para servidores que cuentan con múltiples direcciones IP asignadas, cada dominio puede estar ligado a una dirección IP específica. El correo del dominio se enviará desde esa IP.

También se puede especificar un nombre de servidor SMTP para este dominio. Este valor es un Fully Qualified Domain Name (FQDN) que será utilizado en la instrucción SMTP HELO/EHLO al enviar correo desde el dominio. Para conexiones entrantes, este valor se utilizará a menos que múltiples dominios se encuentren ligados a la dirección IP, en cuyo caso el FQDN utilizado será uno que esté asociado con el primer dominio en orden alfabético.

CAMBIOS Y NUEVAS FUNCIONALIDADES

CORRECCIONES

Copyright ©2008-2016 Alt-N Technologies, Ltd.