Re: [MASOCH-L] [GTER] Bloqueio Porta 25
Rubens Kuhl
> 2.1.1. Estas restrições devem ser implementadas através do bloqueio do tráfego de saída para a porta 25/TCP.
>
>
> Sobre esse bloqueio gostaria de saber se é obrigatório o bloqueio ou não,
Nada é obrigatório, nem o bloqueio, nem a SpamHaus te tirar da lista
deles, nem as pessoas usarem listas de bloqueios, nem elas aceitarem
seus e-mails.
> pois estou tendo problemas com o provedor de email @uai.com.br , onde o meu clientetem 2 emails com eles, só que não tem e não querem (conforme informaram os atendentes do 0800) implementar essa melhoria no seu servidor de emails, liberando outra porta de saída smtp para seus clientes usuarios de email.
Taí um caso para reportamos pro grupo de trabalho que o CGI.br montou
para tocar isso. Quem sabe um chega-junto não ajude.
> Neste caso, fui obrigado a liberar o uso da porta 25 para nao prejudicar meu cliente e, ocorrendo o bloqueio dos meus ip´s no http://www.spamhaus.org/ . atrapalhando o acesso ao webmailde outro cliente empresarial e, não quero que nenhum desses dois clientes empresariais fique prejudicados.
Porque você não libera porta 25 para o MX do Uai apenas ? Isso pode
deixar passar alguns spams mas dificilmente colocará você numa lista
de bloqueio.
Rubens
__
masoch-l list
https://eng.registro.br/mailman/listinfo/masoch-l
Danilo Marques de Gouveia
entender esse método de bloqueio da porta 25 a algum tempo e ainda não
compreendi.
Não sou um ISP, trabalho em uma empresa comum prestando serviços de TI.
Com essa resolução isso quer dizer que os MXs da empresa devem escutar uma
outra porta que não a 25 para receber os emails é isso? Procurei vagamente
no site antispam.br um documento que explicasse como essa gerencia deveria
ocorrer mas nenhum fez a "ficha cair". Será que alguém pode me indicar
algum documento ou site para eu ler mais sobre isso?
Muito Obrigado
--
Danilo Marques de Gouveia
Roberto Alcântara
servidor do seu provedor é que necessariamente usa a porta 587 com
autenticação (submissão de e-mail ao SEU servidor de e-mail).
No antispam.br tem muito material sobre isso.
- Roberto
2012/3/7 Danilo Marques de Gouveia <dm.go...@gmail.com>:
> Com essa resolução isso quer dizer que os MXs da empresa devem escutar uma
> outra porta que não a 25 para receber os emails é isso? Procurei vagamente
> no site antispam.br um documento que explicasse como essa gerencia deveria
> ocorrer mas nenhum fez a "ficha cair". Será que alguém pode me indicar
> algum documento ou site para eu ler mais sobre isso?
ri...@opcaonet.com.br
----- Mensagem original -----
Danilo Marques de Gouveia
E-mails.
Então na verdade meu cliente sai pela porta 587 se conecta ao meu MX e o
meu MX se conecta através da porta 25 com o Hotmail (por exemplo) é isso?
Ou eu devo colocar que o meu MX vai sair pela porta 587 para se conectar a
outro domínio ?
Obrigado,
Henrique de Moraes Holschuh
> Eu tinha entendido que o meu MX iria escutar a porta 587 para
> receber E-mails.
Seu MX vai usar a porta 25. Mas você vai bloquear nas firewalls para
que a porta 25 possa apenas ser utilizada pelo seu MX.
O que acontece é que é criado uma nova função no sistema de email, o MSA
(mail submissio agent), *que pode ficar no MX*.
Usuários só enviam email atráves de SMTP AUTENTICADO, porta 587, para o
MSA (que como eu disse, pode ser o seu MX). O MSA envia via porta 25
mesmo para o MX, ou se for o próprio MX, para o resto do mundo.
Mas usuários precisam ser bloqueados para não mais falar via porta 25
com ninguém. Aqui permitimos que falem via SMTP autenticado com o MSA
também na porta 25, mas não conseguem falar via porta 25 com mais
ninguém, e todo mundo é avisado para usar a porta 587.
Porta 587 deve ser liberada na firewall, se for o caso, para que
clientes externos possam enviar email através de você e para que
clientes internos possam enviar email via outros provedores de email.
> Então na verdade meu cliente sai pela porta 587 se conecta ao meu MX
> e o meu MX se conecta através da porta 25 com o Hotmail (por exemplo)
> é isso?
Sim.
> Ou eu devo colocar que o meu MX vai sair pela porta 587 para se
> conectar a outro domínio ?
Não, porta 587 é só para SMTP AUTENTICADO (é *obrigatório*), e só para
os MUAs (programas de email dos usuários) enviarem email para o MSA.
A nomeclatura ficou assim:
MUA : programa de email do usuário
MSA : o MUA conecta com o MSA para *enviar* email, porta 587,
sempre autenticado. O MSA então encaminha a email para um
MTA via porta 25.
MTA : servidor que encaminha emails, só fala com outros MTAs, MX
e MSA. Nunca fala com usuário final. Usa a porta 25.
MX : MTA, em uma função que fala com MTAs externos (pode ser
MX de entrada ou de saída). Na verdade, era para ser só
o MTA de entrada que está declarado no DNS, mas o termo meio
que virou sinônimo de MTA de borda.
MDA : último MTA na cadeia de transmissão, armazena a mensagem na
caixa de mensagens do usuário.
Lembrar que isso é só o nome de chapéu, sites pequenos tem as funções de
MSA, MTA e MX, e às vezes até MDA na mesma máquina, rodando tudo na
mesma instância do exim/postfix/etc.
O protocolo falado na porta 587 é o ESMTPA (ESMTP autenticado) ou de
preferência o ESMTPSA (ESMTP sobre TLS, autenticado).
> On Wed, Mar 7, 2012 at 10:05 AM,<ri...@opcaonet.com.br> wrote:
>
>> Pelo q eu intendi os servidores smtp deve escutar na porta 587 para
>> os clientes daquele servidor se conectarem nela, e a porta 25 ficar
>> para comunicação entre os mx. Assim os ISPs podem bloquear a porta
>> 25 para os clientes (pois deverá ser só utilizado entre os mx's) ,
>> dessa forma previne que por exemplo uma máquina com virus envie
>> spam para os mx.
Isso. Mas tem o detalhe da autenticação ser obrigatória na porta 587.
Se não fosse, não iria adiantar para grande coisa.
--
Henrique de Moraes Holschuh <h...@ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464
Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.
Rafael Cresci
Marcelo Coelho
On Mar 7, 2012, at 10:55 AM, Rafael Cresci wrote:
> Eu tenho preferido simplificar a questão ao lidar com o usuário: faço ele usar a 465 com o SSL mesmo. Nada de trocar porta pra 587 para submissão. Ela está disponível, mas é mais fácil mandar o cara usar tudo com SSL que os MUAs já mudam a porta para 465 sem precisar o sujeito ir lá e clicar em vários campos. Em alguns casos, o suporte disso é sacal, tem usuário que consegue extrapolar o limite da "inutilidade" (burrice é pouco).
>
__
masoch-l list
https://eng.registro.br/mailman/listinfo/masoch-l
Danton Nunes
> Senhores, desculpe a minha ignorância no assunto mas estou tentando
> entender esse método de bloqueio da porta 25 a algum tempo e ainda não
> compreendi.
a porta 25/tcp é para TRANSPORTE de email, isto é, para a conversa entre
MTAs. o usuário final deve SUBMETER o email pela porta 587. o protocolo é
o mesmo SMTP, exceto que na submissão exige-se autenticação.
resumindo: com a justa exceção de seus servidores de email NINGUÉM conecta
na porta 25/tcp de qualquer host externo. Seus clientes devem rotear email
pelos seus servidores ou, se forem clientes de relays externos, usar a
porta 587 COM AUTENTICAÇÃO. Todos os bons provedores de serviços de email
são capazes de receber email para retransmissão pela 587.
os bots geralmente não sabem enviar email com autenticação, então este
bloqueio os derrota.
Capisce?
-- Danton
Rubens Kuhl
> E como fica a performance do servidor com o uso de SMTP e SSL?
Mesmo em portas 587 ou 25, muita gente usa criptografia através do
comando STARTTLS.
Rubens
Rubens Kuhl
> Eu tenho preferido simplificar a questão ao lidar com o usuário: faço ele usar a 465 com o SSL mesmo. Nada de trocar porta pra 587 para submissão. Ela está disponível, mas é mais fácil mandar o cara usar tudo com SSL que os MUAs já mudam a porta para 465 sem precisar o sujeito ir lá e clicar em vários campos. Em alguns casos, o suporte disso é sacal, tem usuário que consegue extrapolar o limite da "inutilidade" (burrice é pouco).
É por isso que eu acho a solução de fazer NAT automático de porta 25
vindo dos acessos residenciais para porta 587 a mais prática. O
cliente não muda porta, e perguntar usuário/senha quase todo programa
permite hoje em dia.
Mas você lembrou um bom ponto: o que está previsto é "gestão da porta
25", não "bloqueio da porta 25 e uso da 587". A segunda é uma das
formas de implementar, mas há outros mecanismos de envio autenticado
de e-mail (465, 993) e há formas diferentes de drop (NAT, por
exemplo). Qualquer implementação que faça com que os usuários
residenciais não chegam aos servidores de correio que não os que eles
tem conta é boa.
Rubens
Danton Nunes
> Então na verdade meu cliente sai pela porta 587 se conecta ao meu MX e o
> meu MX se conecta através da porta 25 com o Hotmail (por exemplo) é isso?
> Ou eu devo colocar que o meu MX vai sair pela porta 587 para se conectar a
> outro domínio ?
porta 25 = transporte entre MTAs.
porta 587 = submissão de email do MUA -> MSA
MTA = Mail Transport Agent (p.ex. sendmail)
MUA = Mail User Agent (p.ex. Thunderbird)
MSA = Mail Submission Agent (p.ex. sendmail -C /etc/mail/submit.cf)
Danton Nunes
> Eu tenho preferido simplificar a questão ao lidar com o usuário: faço
> ele usar a 465 com o SSL mesmo. Nada de trocar porta pra 587 para
> submissão. Ela está disponível, mas é mais fácil mandar o cara usar tudo
> com SSL que os MUAs já mudam a porta para 465 sem precisar o sujeito ir
> lá e clicar em vários campos. Em alguns casos, o suporte disso é sacal,
> tem usuário que consegue extrapolar o limite da "inutilidade" (burrice é
> pouco).
a 465 usa ssl para garantir sigilo, mas não autenticação! há bots de spam
que sabem se virar muito bem com a 465. a não ser que você configure o
comportamento dela exatamente como o da 587, isto é, email só sai para
fora do domínio com credenciais válidas.
Henrique de Moraes Holschuh
> os bots geralmente não sabem enviar email com autenticação, então
> este bloqueio os derrota.
Tem vírus que usa a API de mensagens do Windows para fazer o
Outhouse ou outro agente to caos mandar o lixo devidamente autenticado.
Não vi botnet fazer isso ainda, mas roubar credencial do Outhouse não
deve ser difícil e vai virar moda logo logo.
Só que como é autenticado, você bloqueia a senha do usuário sempre que
notar o problema (alguém reclamar, seu servidor ir parar em
blacklist...) e mandar spam passa a ser um tremendo incomodo para ele.
--
Henrique de Moraes Holschuh <h...@ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464
Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.
Danton Nunes
> 2012/3/7 Marcelo Coelho <mar...@tpn.com.br>:
>> E como fica a performance do servidor com o uso de SMTP e SSL?
>
> Mesmo em portas 587 ou 25, muita gente usa criptografia através do
> comando STARTTLS.
sim, bem colocado, Rubens. O TLS é uma alternativa interessante ao SSL
para garantir sigilo, mas o problema aqui não é sigilo, é autenticação e
são dois problemas diferentes e, até certo ponto, independentes.
Rafael Cresci
Senão nego faz isso aqui, ó:
http://vidadesuporte.com.br/wp-content/uploads/2012/03/Flagra_Proxy.jpg
Marcelo Coelho
Digamos um servidor com 1.000 usuários com SMTP autenticado na porta 587.
Se todos estes usuários fossem migrados para SMTP com SSL na porta 465, o impacto na performance seria muito grande em termos de processamento?
Danton Nunes
> Não formulei muito bem minha pergunta.
>
> Digamos um servidor com 1.000 usuários com SMTP autenticado na porta 587.
>
> Se todos estes usuários fossem migrados para SMTP com SSL na porta 465, o impacto na performance seria muito grande em termos de processamento?
se o servidor já suporta TLS, o impacto deve ser mínimo, porque clientes
que também suportam TLS o usam e a contaiada do SSL é basicamente a mesma
do TLS, a diferença está em que ponto do protocolo a coisa acontece.
se não, a diferença é a mesma entre http: e https:, os seja, pouco
perceptível.
Danilo Marques de Gouveia
> https://eng.registro.br/**mailman/listinfo/masoch-l<https://eng.registro.br/mailman/listinfo/masoch-l>
>
--
Danilo Marques de Gouveia
Henrique de Moraes Holschuh
> A autenticação é forçada de qualquer forma no lado do servidor; a
> diferença apenas é que pra selecionar a 465 não obriga o usuário a
> digitar a porta 587 manualmente em configs. avançadas (e mexer onde
> não deve), basta mandar ele marcar pra usar SSL. É menos um
> item/menos um passo para o suporte.
SSLv3 não é seguro para nenhuma das partes. Aliás, não me espantaria se
ele colocar a chave secreta do servidor em risco. Então, só deve ser
utilizado como risco calculado.
Leitura obrigatória para quem vai recomendar o uso de SSL ou TLS:
http://en.wikipedia.org/wiki/Transport_Layer_Security
--
Henrique de Moraes Holschuh <h...@ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464
Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.
Henrique de Moraes Holschuh
MSA é um STD (standard, o nível mais definitivo que uma norma técnica da
IETF pode alcançar).
RFC6409 / STD 072: Message Submission for Mail
ftp://ftp.rfc-editor.org/in-notes/rfc6409.txt
ftp://ftp.rfc-editor.org/in-notes/std/std72.txt
O serviço na porta 587 deve obrigatoriamente seguir as determinações
deste RFC/STD para um MSA.
Autenticação é obrigatória no MSA, mas a forma da autenticação não é
definida no RFC/STD. TLS/SSL não é exigido, mas em geral é a única
escolha para conseguir proteger a autenticação em um provedor típico.
Nunca use SSL quando obrigar o uso de TLS for uma alternativa viável,
SSL não é seguro. Aliás, TLSv1.0 também não é tão seguro assim, mas já
é muito melhor que SSLv3.
http://en.wikipedia.org/wiki/Transport_Layer_Security
--
Henrique de Moraes Holschuh <h...@ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464
Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.
Marcio Merlone
> Então na verdade meu cliente sai pela porta 587 se conecta ao meu MX e o
> meu MX se conecta através da porta 25 com o Hotmail (por exemplo) é isso?
> Ou eu devo colocar que o meu MX vai sair pela porta 587 para se conectar a
> outro domínio ?
Quem fala com MX é servidor somente. O teu cliente de email (MUA:
Outlook, Thunderbird) é que vai falar com o servidor smtp pela porta
587. Ou seja:
MUA -> SMTP: Porta 587
SMTP (do seu email) -> MX (do destino): Porta 25
Claro, o MX também vai falar o protocolo SMTP, ou seja, ambas as portas
25 e 587 usam o protocolo SMTP pra conversar. Quando se fala "SMTP" logo
se pensa na porta 25, mas SMTP não implica necessariamente em porta 25.
Precisa ter isto claro pra não confundir.
Colocando em outras palavras: a porta 25 usa o protocolo SMTP e se chama
"SMTP", enquanto que a porta 587 também usa o protocolo SMTP mas se
chama "Submission".
A finalidade da gerência da porta 25 (também conhecido como "bloqueio")
é que somente servidores se conectem na porta 25 e somente do MX, com
verificação anti-spam, anti-virus, etc, e não os clientes. Já a porta
587 é usado somente pelos clientes (pessoas), não permite conexão de
servidores (porta 25 fechada) e só permite envio depois de autenticado e
dependendo do caso dispensa qualquer medida adicional de segurança
(visto que você vai poder catracar o responsável se houver abuso).
Sds.
--
*Marcio Merlone*