Estoy transfiriendo MTA a servidores más nuevos que ejecutan Ubuntu 20.04 LTS. SMTPS funciona bien, lo que permite a los clientes enviar correos electrónicos después de la autenticación. Sin embargo, cuando se envían correos desde MTA remotos para entrega local, Postfix falla debido a fatal: no SASL authentication mechanisms.
Dec 28 12:22:03 smtp postfix/smtpd[63402]: connect from unknown[1.2.3.4]
Dec 28 12:22:03 smtp postfix/smtpd[63402]: warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
Dec 28 12:22:03 smtp postfix/smtpd[63402]: fatal: no SASL authentication mechanisms
Dec 28 12:22:04 smtp postfix/master[63342]: warning: process /usr/lib/postfix/sbin/smtpd pid 63402 exit status 1
Dec 28 12:22:04 smtp postfix/master[63342]: warning: /usr/lib/postfix/sbin/smtpd: bad command startup -- throttling
Aquí existen preguntas sobre temas similares. Pero esta vez es diferente:
- SASL funciona bien y se autentica en el directorio LDAP a través de saslauthd. Por lo tanto, no falta ninguna instalación de complemento para SASL.
- La autenticación funciona bien cuando se conecta mediante SMTPS. Simplemente está fallando en el puerto SMTP 25 normal.
Al probar la conectividad SMTP con netcat, la conexión se cierra antes de enviar la cadena HELO al servidor. Entonces, descubrí que esto está relacionado smtpd_client_restrictionscon/etc/postfix/main.cf:
smtpd_client_restrictions =
permit_sasl_authenticated
# postgrey:
check_policy_service inet:localhost:10023
Esto es necesario para evitar que los correos salientes de remitentes autenticados estén sujetos a listas grises.
A nombre de/etc/postfix/main.cfSASL está configurado así:
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous,noplaintext
smtpd_sasl_tls_security_options = noanonymous
broken_sasl_auth_clients = yes
Las líneas 2 y 3 aquí son necesarias para evitar inicios de sesión en texto plano en SMTP no cifrado, pero acéptelas después de que el cliente haya iniciado TLS a través de STARTTLS o en caso de que el cliente se conecte a través de SMTPS. Veo que el escenario STARTTLS podría descartarse para forzar que toda la autenticación pase a través de SMTPS cifrado con TLS y podría habilitar SASL a través de master.cf solo para SMTPS. Pero los usuarios existentes no deben ajustar su configuración en absoluto.
Respuesta1
Por lo que puedo decir, el problema se debe a
smtpd_sasl_security_options = noanonymous,noplaintext
en combinación con la autenticación SASL contra el directorio LDAP a través de saslauthd. Esto hace que PLAIN y LOGIN sean solo métodos de inicio de sesión disponibles. Ambos están discapacitados por culpa de noplaintextaquí. Quiero que postfix no ofrezca ninguna autenticación cuando no haya métodos SASL disponibles.
Para fines de pruebafui capaz dearreglaresto agregando otro método de inicio de sesión en/etc/postfix/sasl2/smtpd.conf:
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN CRAM-MD5
De esta manera, SMTP aceptaba conexiones entrantes en SMTP para MTA remotos.Sin embargo, esta no es una solución.Por ahora existe un método de inicio de sesión que los clientes reales elegirían para la autenticación, aunque no se espera que tenga éxito. Verhttp://www.postfix.org/SASL_README.htmlpara obtener información adicional sobre cómo configurar Cyrus SASL para usar con saslauthd.
Entonces, seguí buscando y me topé con otra opción que obviamente estaba malinterpretando y por lo tanto me salté la transferencia de la configuración: smtpd_tls_auth_only. Esta opción booleana controla si se requiere TLS para la autenticación. Está configurado node forma predeterminada, lo que hace que la autenticación SASL se configure para SMTP no cifrado. Después de cambiar esta opción a yesenprincipal.cfEl archivo SMTP vuelve a funcionar bien.
Respuesta2
Descubrí que la solución era descomentar esta línea en el archivo master.cf.
-o smtpd_tls_auth_only=yes