Estou transferindo o MTA para servidores mais recentes que executam o Ubuntu 20.04 LTS. O SMTPS está funcionando bem, permitindo que os clientes enviem e-mails após a autenticação. No entanto, ao enviar e-mails de MTAs remotos para entrega local, o postfix falha devido 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
Existem perguntas aqui sobre questões semelhantes. Mas desta vez é diferente:
- SASL está funcionando bem, autenticando no diretório LDAP via saslauthd. Portanto, não falta instalação de plugin para SASL.
- A autenticação funciona bem ao conectar via SMTPS. Está apenas falhando na porta SMTP 25 normal.
Ao testar a conectividade SMTP com o netcat, a conexão é fechada antes do envio da string HELO do servidor. Então, eu descobri que isso está relacionado smtpd_client_restrictionsem/etc/postfix/main.cf:
smtpd_client_restrictions =
permit_sasl_authenticated
# postgrey:
check_policy_service inet:localhost:10023
Isso é necessário para evitar que e-mails enviados de remetentes autenticados sejam sujeitos à lista cinza.
Em nome de/etc/postfix/main.cfSASL está configurado assim:
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous,noplaintext
smtpd_sasl_tls_security_options = noanonymous
broken_sasl_auth_clients = yes
As linhas 2 e 3 aqui são necessárias para evitar logins de texto simples em SMTP não criptografado, mas aceite-as depois que o cliente iniciar o TLS via STARTTLS ou no caso de o cliente se conectar via SMTPS. Vejo que o cenário STARTTLS pode ser eliminado para forçar toda a autenticação a passar por SMTPS criptografado por TLS e eu poderia ativar o SASL via master.cf apenas para SMTPS. Mas os usuários existentes não devem ajustar suas configurações.
Responder1
Pelo que posso dizer, o problema se deve a
smtpd_sasl_security_options = noanonymous,noplaintext
em combinação com autenticação SASL no diretório LDAP via saslauthd. Isso está fazendo com que PLAIN e LOGIN sejam apenas métodos de login disponíveis. Ambos estão desativados devido a noplaintextaqui. Quero que o postfix não ofereça nenhuma autenticação quando não houver métodos SASL disponíveis.
Para fins de testeEu fui capaz deconsertarisso adicionando outro método de login em/etc/postfix/sasl2/smtpd.conf:
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN CRAM-MD5
Dessa forma, o SMTP aceitava conexões de entrada no SMTP para MTAs remotos.Contudo, esta não é uma soluçãopor enquanto, existe um método de login que os clientes reais escolheriam para autenticação, embora não se espere que ele tenha sucesso. Verhttp://www.postfix.org/SASL_README.htmlpara obter informações adicionais sobre como configurar o Cyrus SASL para uso com saslauthd.
Então, continuei pesquisando e me deparei com outra opção que obviamente estava interpretando mal e, portanto, pulando a transferência da configuração: smtpd_tls_auth_only. Esta opção booleana controla se o TLS é necessário para autenticação. Ele é definido nopor padrão, fazendo com que a autenticação SASL seja configurada para SMTP não criptografado. Depois de mudar esta opção para yesemprincipal.cfarquivo SMTP está funcionando bem novamente.
Responder2
Descobri que a correção foi descomentar esta linha no arquivo master.cf
-o smtpd_tls_auth_only=yes