Iniciar uma conversa

Como configurar a porta 587 (submission port)?

Não deixe de ler este artigo indicando que a maior parte dos datacenters/provedores brasileiros devem passar a exigir a porta 587 ao realizar autenticação SMTP para o envio de e-mails, até Dezembro de 2012, conforme indicação do Comitê Gestor da Internet no Brasil. O objetivo é, em linhas gerais, exigir que todos seus usuários enviem e-mails via porta 587 do SMTP, de forma autenticada, eliminando vírus e bots que tentar enviar spam, ao ocorrer abuso de determinada conta, usando a porta 25.

Não estranhe se um cliente seu, mesmo caso você não tenha ainda implementado a porta de submissão em seu servidor, ligue informando que não consegue enviar e-mails, pois o provedor de acesso dele pode estar bloqueando a mesmo, sendo necessário usar uma porta alternativa. Tal bloqueio pode estar partindo da conexão do seu usuário e não do seu sistema, caso ainda não tenha configurado para a porta 587 autenticada ser obrigatória para envio de e-mails via SMTP.

Isso vale para qualquer tipo de conexão SMTP para envio de e-mails, desde seus clientes enviarem emails via seu SMTP, como também relay via outro servidor para envio de emails, regras de roteamento, backup domains, etc. Por exemplo, uma empresa que possui servidor próprio em uma conexão de banda larga e faz relay via provedor, pode ter uma sintaxe como usuario@dominio:senha@host no campo Relay, em Correio/Geral/Aba Entrega/campo Usar servidor de relay, sendo necessário alocar, ao final, a porta 587, devido a possível bloqueio do provedor de acesso e/ou do provedor derelay. Fica então: usuario@dominio:senha@host:587

O IceWarp normalente vem com a porta 366 como alternativa à 25, também permitindo 465 SSL. Futuramente, o IceWarp deve vir por padrão mapeado com a porta 587 no lugar da porta 366 (no campo Porta 2a porta básica, em Sistema/Serviços, duplo clique no serviço SMTP e aba "Outro").

Não esqueça de abrir a porta 587 (e 465 SSL caso já não aberta), no seu firewall.

Note que apenas atrelar a porta 587 ao serviço SMTP não é aderir completamente à implementação da porta de submissão 587, conforme documentos RFC. Pode, entretanto, ser uma boa saída temporária, até que tenha tempo de alertar os usuarios. Ou seja, altere a porta 366 nas propriedades do SMTP  para 587 ou adicione mais um atrelamento na parte de baixo em "Endereços IP's de serviços". Dessa forma, caso o usuário esteja sendo bloqueado na porta 25 pelo provedor de acesso dele, conseguirá enviar usando a porta 587 do seu servidor.

O correto para ter uma implementação completa de submission port, seria além de mapeá-la como 2a porta básica, ativar o "submission port" via API, o que fará com que todos seus usuários sejam obrigados a enviar e-mails AUTENTICANDO (opção "Meu servidor requer autenticação" nos clients) e usando a porta 587 (sem SSL ou via TLS) ou 465 (SSL). Caso não ative o submission port via API e apenas inclua a porta 587 nos atrelamentos, deverá conseguir fugir de bloqueio da porta 25 realizado por parte dos provedores de acesso. Pode até ser um cenário relativamente seguro apenas atrelar a porta 587 e nao ativar o submission.

Normalmente, conforme pode ser lido nas melhores práticas, o IceWarp JÁ obriga usuários a autenticarem SMTP, independente da porta, mas fornece outros mecanismos de relay. O Submission entretanto, garantiria que mesmo que fatores negativos, configurações digamos não recomendados, não entrem em acao. Por exemplo, POP antes de SMTP (que recomendamos desativar) ou IPs de usuários finais ou de servidores web que enviem formulários sem autenticar estejam nos IPs confiáveis. Mesmo caso isso ocorra, com a 587, o usuário tem que autenticar e enviar e-mails via porta 587.

Além disso, ao fechar a porta 25 para envio de e-mails, felizmente muitos botnets/vírus e spammers não conseguirão realizar spam através de suas conexões de ADSL/cabo... A porta 25 seria usada somente entre servidores.

Outra vantagem em usar a porta 587 é que você tem conexões distintas dela com relação à 25. Por exemplo, se o seu SMTP entrante está definido para 100 conexões simultâneas, você tem 100 conexões na 25 (entre servidores) e 100 para usuários autenticarem/enviarem e-mails para fora.

Ressaltando que tais decisões sao do administrador e aqui expressamos a opinião da nossa equipe, baseado em diversos aspectos e fornecendo as ferramentas para que você possa tomar a decisão que julgar ideal.

Usuários do WebMail não são afetados, bastando você, como administrador, alterar a porta do SMTP usado pelo webmail (ex 127.0.0.1:587).

É importante informar aos usuários e possívelmente atualizar seus tutoriais, pois implica em mudar configuração de porta SMTP no programa cliente de e-mail de 25 para 587 ou 465 SSL (normalmente na guia Avançado do client). No site http://www.antispam.br/porta25/, há varios tutoriais de provedores como Terra e dicas disponíveis para auxiliar na mudança.

No IceWarp, em Sistema/Serviços, duplo clique em SMTP e altere a 2º porta básica, na guia Outro, para 587.

Realize o procedimento abaixo apenas caso tenha entendido seu funcionamento e consequências por completo.

Para ativar submission port (implementação completa da porta 587), faça uma busca em Arquivo/Console API por "submission" e, ao localiza a string, caso esteja "false" (falso), dê um duplo clique para que fique "true", ou seja, verdadeiro, submission ativado.

OU então, na raíz do IceWarp: tool modify system c_mail_smtp_delivery_messagesubmission 1

Reinicie o SMTP em Sistema/Serviços, botão da direita no SMTP e Reiniciar módulo SMTP. Verifique o log SMTP caso esteja preocupado em localizar casos de "Permission denied", pelo fato do usuário estar tentando enviar via porta 25.

IMPORTANTE: Vale ressaltar que, ao ativar tal opção, usuários e sistemas que utilizam seu SMTP para enviar e-mails, precisam necessariamente enviar e-mails apenas via porta 587 e autenticando (meu servidor requer autenticação), caso negativo, recebem o erro "Permission denied". A porta 25 continua sendo usada entre servidores. Ainda, existem casos em que o remetente se apresenta como sendo de um domínio local, para fazer uma entrega local e não necessariamente enviar e-mails para fora (relay). Nesse caso, se a conta existe localmente, IceWarp permite o recebimento via porta 25, mesmo o MAIL FROM sendo de um domínio local. Se a conta não existe localmente, IceWarp recusará o e-mail devido ao submission port e você poderá passar a autenticar em tal envio OU, a partir versão 11, usar o bypass do Submission port. Para usar o bypass, crie um arquivo em icewarp/config/submissionbypass.dat usando a mesma sintaxe vista nos outros bypasses.

Por exemplo, l: seria para liberar remetentes locais (local senders), o que tira um pouco o sentido do recurso, já que você criaria um bypass para todos remetentes locais, que poderiam usar a porta 25.

Outros exemplos:

Liberando range de IP's -> i:189.38.80.0/20
Liberado um remetente específico -> s:remetente@dominio.com

Você pode usar o bypass de outro recurso, como DNSBLs (Correio/Segurança), adicionando aspectos como comentários e recortar/colar a respectiva linha para dentro do submissionbypass.dat.

IMPORTANTE 2: É necessário também alterar o campo SMTP do Cliente Web, em GroupWare/Client Web, no console. Ex: 127.0.0.1:587

Vale ressaltar que tal definição de porta, feita em GroupWare/Cliente Web, também é usada pelo Exchange ActiveSync, portanto, ativando submission via API, é essencial que defina a porta 587 conforme explicado (127.0.0.1:587).

OBS: O uso do submission port, ativado via API, implica em não poder usar a opção "Habilitar mensagens de erro para destinatários com falha no envio", em Opções do Admin/Correio/Geral do WebMail (logado com conta admin). Tal opção permite enviar e-mails mesmo com algum destinatário local incorreto ou causando erro fatal, mas por fazer um relay local, não funcionaria caso ative porta de submissão (por não ocorrer autenticação neste reenvio).


Escolher arquivos ou arraste e solte arquivos
Esse artigo foi útil?
Sim
Não
  1. Flávio Zarur Lucarelli

  2. Publicado
  3. Atualizado

Comentários