SSL_accept erro quando o cliente de e-mail se conecta ao postfix

4

Consegui configurar postfix e dovecot com certificado autoassinado no meu servidor. Eu posso enviar e receber e-mail usando o comando telnet lá. Agora eu quero me conectar ao meu servidor de e-mail de um cliente Thunderbird no meu laptop, mas ele falha e aqui está a saída de /var/log/mail.log :

postfix/submission/smtpd[11560]: connect from unknown[95.134.50.75]
postfix/submission/smtpd[11439]: SSL_accept error from unknown[95.134.50.75]: lost connection
postfix/submission/smtpd[11439]: lost connection after CONNECT from unknown[95.134.50.75]

Veja uma parte do /etc/postfix/master.cf que alterei na configuração:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       -       -       -       smtpd
smtps     inet  n       -       -       -       -       smtpd
#smtp      inet  n       -       -       -       1       postscreen
#smtpd     pass  -       -       -       -       -       smtpd
#dnsblog   unix  -       -       -       -       0       dnsblog
#tlsproxy  unix  -       -       -       -       0       tlsproxy


submission inet n       -       -       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth

E aqui está meu /etc/postfix/main.cf :

myhostname = mail.myserver.com
myorigin = /etc/mailname
mydestination = mail.myserver.com, myserver.com, localhost, localhost.localdomain
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

smtpd_tls_cert_file=/etc/ssl/certs/mailcert.pem
smtpd_tls_key_file=/etc/ssl/private/mail.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_protocols = !SSLv2, !SSLv3

smtpd_tls_security_level = may
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1

local_recipient_maps = proxy:unix:passwd.byname $alias_maps

inet_protocols = all

Além disso, não tenho certeza se isso pode ajudar, mas telnet localhost 25 e telnet localhost 465 trabalham no servidor, mas apenas telnet myserver.com 465 funciona no meu laptop; quando tento a porta 25, ele diz telnet: Unable to connect to remote host: Connection timed out . ufw está inativo no servidor.

O que devo fazer para corrigir isso?

    
por Anton 13.11.2014 / 14:11

2 respostas

11

A porta 465 é para SMTPS, usa SSL imediatamente ao estabelecer a conexão e, em seguida, usa o mesmo protocolo SMTP normalmente encontrado na porta 25 depois que a conexão segura é estabelecida. Você testa da linha de comando com:

openssl s_client -connect smtp.example.com:465

O uso do telnet para conectar-se à porta 465 resultará em uma mensagem de erro nos arquivos de log porque o protocolo SSL não é usado.

Apenas para completar: para testar o TLS na porta SMTP normal, o TCP / 25

openssl s_client -starttls smtp -connect  smtp.example.com:25
    
por 13.11.2014 / 16:35
0

A única vez que vi isso é quando o Postfix está bloqueando o cliente devido a configurações restritivas de TLS / SSL:

smtpd_tls_protocols =! SSLv2,! SSLv3

Se o seu cliente de e-mail está tentando usar o SSL2 ou 3, esse seria o motivo. Se não, também poderia ser devido a um bloqueio, mas você acha que a porta seria bloqueada e você não veria a conexão do cliente normalmente (por exemplo, meu ISP bloqueia completamente a porta 25 e ao tentar se conectar a um servidor de email você não vejo nada nos logs).

    
por 12.07.2018 / 22:33