[GTER] combate ao spam no brasil ganha novas diretrizes do cgi.br

Renato de Oliveira Diogo renato.diogo at gmail.com
Fri May 22 21:25:33 -03 2009


Senhores

temos que ver, por outro lado na qualidade do serviço. Por mais que
isto seja tortuoso para nós administradores, o resultado final dessas
mudanças é bom. Temos que pensar, também, na segurança do usuário e da
rede, e querendo ou não isso ajuda na segurança, economiza link de
dados, economiza processamento e assim vai. Todos tem que colaborar,
desde o administrador até o usuário pois no final é beneficio ao
mesmo. O usuário tem que ser mais consciente dos problemas que é
prejuízo para ele mesmo.
Agora vamos pensar no seguinte, para que um usuário com acesso discado
ou acesso de banda larga com IP dinâmico precisa ter a porta 25
liberada para ele ter um servidor em casa? Isso é um serviço mais
complexo e exige profissionalismo.
Aqui a mais ou menos um mês tenho a seguinte regra:
* bloqueio qualquer tráfego vindo da minha rede para internet com
destino a porta 25;
* libero servidores destinos conhecidos, basta o cliente solicitar uma
única vez, e com todo prazer fazemos a liberação para o mesmo. Depois,
periodicamente pego a mesma lista e replico a todos os firewall, pois
se o cliente mudar de ponto, ou outros clientes usarem o mesmo serviço
não terá problemas.

E digo outra coisa, já coloco cadastrado serviços comuns, como uol,
bol, terra, hotmail, meu servidor próprio e outros que sei que o
pessoal usa na região. E em 1 mês, não houve nenhuma ligação
reclamando sobre tal.

Atenciosamente
________________________________________________
Renato de Oliveira Diogo

Bacharel em Ciência da Computação
UNESP - Bauru

LPIC1 - Linux Professional Institute Certification - Nível 1

renato.diogo at gmail.com
renato.diogo at yahoo.com.br



2009/5/22 Rafael Henrique Faria <rafaelhfaria at cenadigital.com.br>:
>> Será?
>>
>> Gostei particularmente desta:
>>
>> 2.1. Que em redes de usuários finais, de caráter residencial e/ou com endereçamento IP dinâmico, sejam implementadas restrições para impedir a entrega direta de mensagens a partir de máquinas clientes.
>>
>>    * 2.1.1. Estas restrições devem ser implementadas através do bloqueio do tráfego de saída para a porta 25/TCP.
>>
>
> Concordo, mas ao mesmo tempo me deu uma preocupação.
> Configuração no usuário final.
>
> Se o IP não pode conectar a IPs com portas de destino 25, ele não
> poderá mais facilmente configurar um smtp. Terá que utilizar outra
> porta para o smtp, e de preferencia já utilizar via TLS. Realmente é
> muito melhor. Mas já é dificil explicar para um usuário final leigo
> como colocar apenas o endereço do smtp, imaginem explicar a alteração
> de porta, protocolo, entre outras informações.
>
> Já foi implantado algo parecido com isso na UNESP.
> Todas os IPs da UNESP não tem permissão para enviar para um IP externo
> pacotes com destino porta 25, com exceção os MTAs.
> E internamente, os usuários podem se conectar na porta 25 do MTA, por
> não está bloqueada para uso na propria rede.
> Porém alguns usuários que querem usar MTAs externos não conseguem. E
> em 90% dos casos que isso ocorreu, o MTA externo não utilizava outros
> protocolos. Apenas a porta 25. E o usuário não poderia utilizar o
> nosso MTA para enviar este e-mail pois o dominio do qual ele queria
> enviar e-mail possuia SPF, então a mensagem iria ser barrada no
> destino.
>
> Para que isso funcione todos os provedores, e serviços de hospedagem,
> de e-mails, devem configurar outras portas para envio dos e-mails. O
> que eu acho um pouco dificil, já que pelo visto uma grande parte dos
> serviços de hospedagem utilizam sistemas prontos, e na maioria destes
> sistemas o smtp não é configurável. E os administradores destes
> serviços não sabem como alterar na mão.
>
> A idéia é muito boa. Mas acredito que levará um bom tempo até que tudo
> se adapte.
>
> --
> Rafael Henrique da Silva Faria
> Assistente de Informática II
> STI - Faculdade de Ciências e Letras
> Campus de Araraquara - UNESP
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list