Para limitar qué sistemas pueden enviar correo saliente no autenticado a través de un MTA de Zimbra, configure el atributo de ese servidor zimbraMtaMyNetworkscon una lista corta de direcciones IP o redes CIDR de confianza. Mantenga la interfaz loopback en la lista, conserve los hosts de confianza existentes que aún necesiten retransmisión y elimine los rangos amplios en los que ya no confía. A continuación, reinicie Postfix y pruebe tanto una fuente aprobada como una no aprobada.
Esta configuración controla los clientes SMTP de confianza que pueden reenviar mensajes sin autenticación SMTP. No bloquea todos los mensajes salientes de un usuario autenticado de Zimbra ni establece el servidor de correo del siguiente salto. Si su objetivo es requerir autenticación para los clientes de correo itinerantes o restringir cuentas de usuario específicas, utilice los controles de autenticación o de política de correo correspondientes.
El MTA de Zimbra utiliza Postfix. En Postfix, un cliente cuya dirección de origen coincide mynetworksse considera de confianza para el reenvío. Zimbra expone esta lista a través de zimbraMtaMyNetworks. Un host incluido en la lista puede enviar correo a destinos externos sin autenticarse, por lo que cada entrada representa una decisión de confianza significativa.
No confunda la lista de permitidos con el servidor de retransmisión zimbraMtaRelayHost. La lista de permitidos determina qué clientes SMTP pueden retransmitir a través de este MTA. Un servidor de retransmisión es el servidor ascendente al que el MTA reenvía los mensajes no locales, por ejemplo, cuando un proveedor de red requiere un servidor de retransmisión inteligente. Modificar uno no reemplaza al otro.
Las páginas del Centro Tecnológico de Zimbra describen este atributo y los comandos correspondientes, pero parte del material está marcado como trabajo en progreso o documentación archivada. Confirme el comportamiento con su versión instalada de Zimbra y el diseño de implementación antes de aplicar los cambios. Los ejemplos a continuación utilizan las herramientas de línea de comandos de Zimbra como zimbracuenta de servicio, de acuerdo con las directrices de Zimbra para MTA.
Utilice un rango CIDR de un solo host, como por ejemplo /32para una dirección IPv4. Por ejemplo, 198.51.100.25/32representa un host IPv4; esta dirección, que solo se incluye en la documentación, es un ejemplo y no debe copiarse como una dirección de servidor real. Un rango más amplio, como , /24confía en todas las direcciones de esa subred. No añada redes públicas ni rangos de proveedores extensos solo para que la prueba sea exitosa.
Inicie sesión en el host MTA y cambie a la cuenta de servicio de Zimbra. Reemplace mta.example.comcon el nombre exacto del servidor que devuelve el zmhostnamecomando de su instalación.
su - zimbra
zmhostname
zmprov gs mta.example.com zimbraMtaMyNetworks
postconf mynetworksLa primera consulta lee el valor almacenado para el objeto del servidor Zimbra y postconfmuestra la configuración efectiva de Postfix. Guarde ambos resultados. Si el atributo LDAP no está configurado, es posible que Postfix esté usando un valor predeterminado, por lo que no asuma que una consulta vacía significa que no hay redes de confianza. Verifique el valor efectivo y el comportamiento de configuración de su versión antes de continuar.
Crea una lista que contenga la interfaz de bucle invertido más cada fuente que realmente necesite retransmisión no autenticada. Para un servidor que solo debería aceptar retransmisión desde localhost y un host de aplicación fijo, la estructura sería la siguiente:
127.0.0.0/8 198.51.100.25/32Sustituya la dirección de ejemplo por la dirección real visible para el MTA. Incluya las interfaces locales necesarias del servidor o los servicios de confianza adicionales solo después de confirmar que son necesarios. Evite dejar una subred de oficina amplia si solo se debe confiar en un servidor; redúzcala a una entrada de host siempre que sea posible.
Se utiliza zmprov mspara establecer el atributo a nivel de servidor. Este comando reemplaza el valor, así que incluya todas las entradas que desee conservar, incluido el bucle de retorno:
zmprov ms mta.example.com zimbraMtaMyNetworks '127.0.0.0/8 198.51.100.25/32'Para múltiples direcciones IP, incluya la lista completa de direcciones aprobadas entre comillas, separadas por espacios. No ejecute un comando de ejemplo sin modificar. Si su configuración depende de un valor global, anulaciones a nivel de servidor, IPv6, múltiples MTA o un comportamiento específico de la versión, verifique cómo funcionan la herencia y la configuración generada de Postfix en esa implementación antes de establecer el atributo.
Después de cambiar la configuración de Zimbra, reinicie Postfix como cuenta de servicio de Zimbra y, a continuación, consulte de nuevo el valor efectivo:
postfix reload
postconf mynetworks
zmprov gs mta.example.com zimbraMtaMyNetworksLa salida debe coincidir con la lista de permitidos que usted especificó, incluyendo la interfaz de bucle invertido. Si Postfix informa de una red mal formada o los valores difieren, detenga el proceso y resuelva ese problema de configuración antes de probar el flujo de correo. Las entradas CIDR deben usar el límite de red correcto; para un solo host, use la dirección del host con /32, en lugar de una máscara de red que incluya hosts vecinos.
Realice la prueba desde un sistema controlado y autorizado, utilizando la misma ruta de red y el mismo servidor SMTP que la aplicación real. Envíe un mensaje a un buzón de correo que controle fuera de los dominios de Zimbra. Confirme que el host autorizado puede enviarlo y que los registros del MTA muestran una aceptación o entrega exitosa. La actividad del MTA de Zimbra se registra habitualmente /var/log/zimbra.log; inspeccione la marca de tiempo y la dirección IP de origen correspondientes, en lugar de confiar únicamente en el mensaje de éxito del cliente de correo.
Luego, realice la prueba desde un host que no esté en la lista de permitidos y que no esté autenticado. El resultado esperado es una denegación de retransmisión al intentar enviar a un destinatario remoto. Consulte el registro del MTA para ver la conexión rechazada y la dirección de origen observada por Postfix. Un cliente no autenticado aún podría enviar correo a destinatarios locales de Zimbra; esto es recepción de correo normal y no demuestra que pueda retransmitir correo saliente.
Pruebe también cualquier aplicación legítima que estuviera en la lista anterior. Un envío de aplicación fallido suele significar que se incluyó una dirección de origen incorrecta en la lista de permitidos, se eliminó una dependencia de confianza antigua o la aplicación necesita autenticación SMTP. Si los clientes se desplazan entre redes o su IP de salida no es estable, la autenticación SMTP sobre TLS suele ser más fácil de gestionar que modificar repetidamente una lista de permitidos de IP.
Si las aplicaciones aprobadas dejan de enviar, restaure el valor guardado exacto en lugar de agregar una subred estimada. Aplíquelo con zmprov ms, recargue Postfix y confirme el valor efectivo con postconf mynetworks. Compruebe si un balanceador de carga, puerta de enlace NAT, host de contenedor o proxy de salida cambia la dirección de origen antes de que llegue al MTA.
Una Relay access deniedrespuesta negativa también puede significar que el cliente no está autenticado y que su IP de origen no figura en la lista de confianza. Para los usuarios de correo electrónico habituales, configure el envío SMTP con autenticación en lugar de agregar todas las redes de usuarios a la lista zimbraMtaMyNetworks. Las listas de permitidos amplias crean una mayor superficie de retransmisión no autenticada y pueden exponer el servidor a abusos si una red de confianza contiene dispositivos no administrados.
Si el valor de MTA parece correcto pero el comportamiento no cambia, confirme que editó el servidor que aceptó la conexión, que la recarga se realizó correctamente y que ninguna otra instancia de Postfix o dispositivo de red está gestionando SMTP. No edite directamente los archivos de Postfix generados por Zimbra como solución permanente; la administración de la configuración podría regenerarlos. Consulte la documentación de administración de Zimbra o el canal de soporte de su versión para obtener procedimientos específicos cuando el valor de LDAP y la configuración de tiempo de ejecución no coincidan.
postconf mynetworksSolo muestra las direcciones de bucle invertido y las direcciones o redes de origen confiables previstas.Este método restringe el reenvío no autenticado por dirección IP de origen. No reemplaza la autenticación SMTP, TLS, los controles de velocidad, la seguridad de la cuenta ni la monitorización, y no puede distinguir entre aplicaciones individuales que comparten una misma dirección NAT pública. Úselo como un control específico y revise la lista de permitidos cada vez que cambien las funciones de salida de la red o del MTA.
Solucione los errores de descifrado de Element Web comprobando la verificación del dispositivo, la copia de seguridad de claves, las claves de recuperación y las claves de sala faltantes, sin poner en riesgo el historial de mensajes.
Aprenda cómo habilitar los proveedores de autenticación de dos factores (2FA) de Nextcloud, cómo aplicar la autenticación de dos factores a usuarios o grupos, cómo preparar la recuperación y cómo verificar los inicios de sesión y las aplicaciones cliente.
Limite el reenvío de correo saliente no autenticado en Zimbra a direcciones IP de confianza con zimbraMtaMyNetworks. Aprenda cómo inspeccionar, actualizar, recargar y verificar la lista de permitidos de forma segura.
Establezca el límite de memoria de PHP en al menos 512 MB para Nextcloud, busque la configuración web de PHP correcta, reinicie Apache o PHP-FPM y verifique que la advertencia haya desaparecido.
Configura Coturn con Synapse para llamadas Matrix WebRTC. Configura las credenciales compartidas, NAT, puertos del firewall, opciones TLS y distingue entre TURN heredado, MatrixRTC y LiveKit.
Configura Nextcloud Mail con OAuth2 para Gmail o Microsoft 365, verifica el acceso IMAP/SMTP, soluciona problemas de redireccionamiento y conoce los límites.
Solucione el problema de la advertencia de sesión "No se puede verificar la identidad" de Element verificándola con otro dispositivo de confianza o una clave de recuperación, y aprenda cuándo es seguro restablecer la configuración.
Compara la migración de Kopano con la de grommunio y Zammad. Descubre qué datos de buzón puede conservar cada método, cómo realizar pruebas piloto y verificar los resultados, y cuándo es apropiado utilizar IMAP o una importación personalizada.
Traslada un directorio de datos de Nextcloud a un disco duro externo sin romper las referencias de archivos. Utiliza copias de seguridad, un montaje persistente, rsync, permisos y enlaces simbólicos de forma segura.
Solucione los problemas con los temporizadores cron de systemd de Nextcloud en Ubuntu comprobando el usuario del servicio, las rutas de PHP y Nextcloud, la activación del temporizador y el historial de ejecución de trabajos.
