[GTER] Re: GTER Digest, Vol 23, Issue 9

[Wilson Barbosa]

Oi Pessoal,

Estou usando o qmail com spamassassin e com outro qmail atendendo na
frente da internet. Implementei algumas solucoes para barrar spam, uma
das que mais gostei foi o qgreylist, reduziu em muito o trafego de
email, assim como, a verificacao de reverso. Continuo recebendo uma
serie de emails falsos, gostaria de saber como fazer o qmail (uso
netqmail1.05) checar a validade do emissor via MX valido. Existe
alguma solucao via tcpserver e/ou em maquina receptora, antes do
servidor real? Algum proxy de email que possa fazer isto?

Obrigado antecipadamente,
Wilson.


On Tue,  1 Feb 2005 20:33:03 -0200 (BRST),
gter-request at eng.registro.br <gter-request at eng.registro.br> wrote:
> Send GTER mailing list submissions to
>         gter at eng.registro.br
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://eng.registro.br/mailman/listinfo/gter
> or, via email, send a message with subject or body 'help' to
>         gter-request at eng.registro.br
> 
> You can reach the person managing the list at
>         gter-owner at eng.registro.br
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of GTER digest..."
> 
> Today's Topics:
> 
>    1. Re: Re: Re: Re: Qmail - Cluster (Lao DanTong)
>    2. Re: C.E.F. (Jeronimo Zucco)
>    3. Re: Re: Qmail - Cluster (Juliano Primavesi - Cyberweb Networks)
>    4. Re: Re: Re: Re: Qmail - Cluster (Armando Araujo Filho)
>    5. Re: Re: Re: Qmail - Cluster (Aristeu Gil Alves Jr)
>    6. Ipchains -> Iptables (Leonardo Queiroz de Mello)
>    7. Re: Re: Re: Re: Qmail - Cluster (Lao DanTong)
>    8. Re: Re: Qmail - Cluster (Aristeu Gil Alves Jr)
>    9. Re: Qmail - Cluster (Marcelo Estanislau)
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 1 Feb 2005 17:32:59 -0200 (BRST)
> From: Lao DanTong <danton at inexo.com.br>
> Subject: Re: [GTER] Re: Re: Re: Qmail - Cluster
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
>         <gter at eng.registro.br>
> Message-ID: <Pine.LNX.4.60.0502011732280.6798 at newquantum.inexo.com.br>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Tue, 1 Feb 2005, Juliano Dapper wrote:
> 
> > nem tudo que está funcionando está bom :-)
> 
> mas vocês tem que admitir que estar funcionando é muito melhor que estar
> bom (e não necessariamente funcionando)
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 01 Feb 2005 17:29:27 -0300
> From: Jeronimo Zucco <jczucco at ucs.br>
> Subject: Re: [GTER] C.E.F.
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
>         <gter at eng.registro.br>
> Message-ID: <41FFE6A7.2020403 at ucs.br>
> Content-Type: text/plain;       charset=iso-8859-1;     format=flowed
> 
> Uma pesquisa no google depois:
> 
> http://www.zago.eti.br/firewall/modelos-governo.txt
> 
> "O google é o meu pastor e o suporte não me faltará !"
> 
> Nesse link tem exemplos para diversos programas do governo que precisam
> de configuracao especial.
> 
> --
> Jeronimo Zucco
> LPIC-1 Linux Professional Institute Certified
> Certificado Conectiva Linux
> Núcleo de Processamento de Dados
> Universidade de Caxias do Sul
> 
> "First they ignore you,
> then they laugh at you,
> then they fight you,
> then you win." (Mahatma Gandhi)
> 
> Jorge Luiz Godoy Filho escreveu:
> 
> >Em Terça 01 Fevereiro 2005 17:59, Marcelo Marques Pinheiro escreveu:
> >
> >
> >>Em Iptables funciona, mais em ipchains nao estou conseguindo fazer
> >>funciona...
> >>
> >>
> >
> >Atualizaram a documentação para iptables?  Que progresso!  Da última vez ainda
> >estava em ipchains...  Já era hora.
> >
> >Eu não tenho mais nenhum script usando ipchains para verificar documentação ou
> >regras, desculpe.
> >
> >
> >
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 01 Feb 2005 17:35:58 -0200
> From: Juliano Primavesi - Cyberweb Networks <juliano at cyberweb.com.br>
> Subject: Re: [GTER] Re: Qmail - Cluster
> To: Rodrigo Campos <camposr at gmail.com>, Grupo de Trabalho de
>         Engenharia e Operacao de Redes <gter at eng.registro.br>
> Message-ID: <41FFDA1E.8050703 at cyberweb.com.br>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Apenas um ponto (.) ... a idéia que citei de usar a ramdisk é no MX, nao
> nos servidores de envio, observando-se o ítem 7, extremamente bem colocado.
> 
> Juliano
> 
> Rodrigo Campos escreveu:
> > On Tue, 01 Feb 2005 14:34:42 -0200, Alexandre Hautequest
> > <hquest at onda.com.br> wrote:
> >
> >>Adriano Nagelschmidt Rodrigues wrote:
> >>
> >>>Juliano Primavesi - Cyberweb Networks writes:
> >>>
> >>>
> >>>>O que voce pode fazer com qmail e funciona, que deixa o servidor mais
> >>>>rapido, é colocar a queue em uma ramdisk (512 mb eh suficiente e como
> >>>>servidor de emails nao usa muita ram, ainda vai sobrar),
> >>>
> >>>
> >>>Deixar a fila em ramdisk?? Você quer dizer ram volátil? Do tipo que é
> >>>perdida quando a força cai ou o computador trava?
> >>
> >>Se voce nao confia no equipamento, nao deve deixa-lo ser um servidor de
> >>qualquer coisa.
> >>
> >
> >
> > My 2 (or more) cents,
> >
> > Não se trata de confiar ou não no equipamento, só não vejo sentido em
> > usar o queue em um sistema de arquivos montado em área volátil, e
> > explico porquê:
> >
> > 1. Necessidade: Isso só faz sentido se você tem discos lentos e/ou de
> > baixa qualidade, se os seus discos instalados no equipamento foram
> > dimensionados corretamente para a demanda de tráfego de mensagens,
> > eles devem atender ao IO exigido. Se for para discutir infra-estrutura
> > e confiança no equipamento, comecemos por aí...
> >
> > 2. Complexidade: Colocar o queue em uma área volátil adiciona uma
> > carga de complexidade no setup do sistema, um simples shutdown/startup
> > do sistema faz com que seja necessário o destaging das informações em
> > memória para o disco e subsequente restauração dessas informações
> > antes de se reiniciar o daemon de processamento de fila. K.I.S.S.
> >
> > 3. Segurança: Dependendo da plataforma usada, uma outra aplicação "mal
> > comportada" pode corromper a sua fila em caso de falha de segmentação.
> >
> > 4. Confiabilidade: Não quero fazer juízo de ninguém da lista, mas
> > acreditem, é muito mais fácil ter um sistema de alta disponibilidade
> > no provedor "familiar" de até 20 servidores do que em um "carrier
> > grade data center", falhas no fornecimento de energia não são tão
> > incomuns assim independente do investimento feito na infraestrutura de
> > fornecimento de energia.
> >
> > 5. Comprometimento: Para algumas pessoas um e-mail é "apenas uma
> > mensagem", mas para muita gente isso é uma ferramenta estratégica do
> > negócio e *nenhuma* mensagem pode ser perdida, eu não posso dar a
> > desculpa de que "foi mal aí mas a fonte queimou".
> >
> > 6. Custo: Podem me chamar de "old fart", mas eu lembro das aulas de
> > arquitetura de sistemas em que martelavam insistentemente a máxima:
> > "Memória é caro, disco é barato".
> >
> > 7. Disponibilidade de terceiros: Você tem um FS em RAM de 512Mb, ou
> > até 1Gb, e de repente o UOL|BOL|Terra|iG|Hotmail|Yahoo caem, zilhões
> > de e-mails vão ficando na fila (usuários seus mandando e-mail, bounce
> > para dropboxes, etc...), e o FS em RAM lota, seus usuários começam a
> > receber inconvenientes mensagens de falta de espaço em disco.
> >
> >
> >
> >>--
> >>Alexandre
> >>--
> >>GTER list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >
> >
> >
> 
> ------------------------------
> 
> Message: 4
> Date: Tue,  1 Feb 2005 17:36:01 -0200
> From: Armando Araujo Filho <listas.do.armando at fastpack.com.br>
> Subject: Re: [GTER] Re: Re: Re: Qmail - Cluster
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
>         <gter at eng.registro.br>
> Message-ID: <1107286561.41ffda218aac7 at cartman.intranet.matriz>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Citando Lao DanTong <danton at inexo.com.br>:
> 
> > eu acho que esta conversa está ficando meio besta. mail-toasters podem
> > ser
> > feitos com praticamente qualquer MTA, até o bom e velho sendmail
> > incrementado com LDAP dá bem no couro. que tal parar com essa ridícula
> > querela religiosa de postfix x qmail?
> 
>   Que bom que alguém teve coragem de escrever. Realmente acho que a "coisa"
> está se passando. Apenas perde-se a boa qualidade das discussões que vemos
> por aqui.
> 
> Valeu,
> 
> Armando
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 1 Feb 2005 18:15:11 -0200
> From: "Aristeu Gil Alves Jr" <suporte at wahtec.com.br>
> Subject: [GTER] Re: Re: Re: Qmail - Cluster
> To: <gter at eng.registro.br>
> Message-ID: <008501c5089a$bbf1a9d0$1503000a at wahtemp>
> Content-Type: text/plain;       charset="iso-8859-1"
> 
> Não quero prolongrar uma discução que já acabou. Apenas discutindo um
> assunto que tem sido recorrente na lista como bug de MTAs: o teste de
> usuários no envelope.
> 
> Como o postfix/sendmail/exim/... implementam proteção contra
> mapeamento de
> usuários? Gostaria de saber algumas técnicas, pois não sou grande
> usuário destes MTAs.
> 
> Fazer verificação de usuários em nível de envelope pode gerar um
> problema de mapeamento de usuários com o mesmo dicionário utilizado
> por spamers. A unica coisa que o cara vai fazer é verificar "550 User
> unknown" ou "250 Ok". Existem ferramentas para automatizar esse
> processo.
> 
> Retira-se o VRFY dos servidores, mas testa-se os usuários logo no
> envelope. Não sei
> se isso chega a ser um problema real para grandes provedores.
> Acaba, no final, sendo uma relação custo vs benefício, ou Economia de
> Banda vs Harvesting. É um bom tema para discução, ou não. :-)
> 
> []'s
> --aristeu
> 
> > --------------------------------------------------------------------
> --
> >
> > Message: 1
> > Date: Tue, 1 Feb 2005 15:30:37 -0200 (BRST)
> > From: Lao DanTong <danton at inexo.com.br>
> > Subject: Re: [GTER] Re: Re: Re: Qmail - Cluster
> > To: security at onda.com.br, Grupo de Trabalho de Engenharia e Operacao
> > de Redes <gter at eng.registro.br>
> > Message-ID:
> <Pine.LNX.4.60.0502011524570.1943 at newquantum.inexo.com.br>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > On Tue, 1 Feb 2005, Anderson Nadal wrote:
> >
> > > Todo software tem bug, inclusive os utilizados pela NASA, nao
> esqueca
> > > que 2 onibus espaciais literalmente foram pro espaco. :)
> >
> > em nenhum caso, que eu saiba, por causa de bug de software.
> >
> > eu acho que esta conversa está ficando meio besta. mail-toasters
> podem ser
> > feitos com praticamente qualquer MTA, até o bom e velho sendmail
> > incrementado com LDAP dá bem no couro. que tal parar com essa
> ridícula
> > querela religiosa de postfix x qmail?
> >
> > quanto a ter um volume imenso de mensagens, sem ser um UOL da vida,
> convém
> > verificar se você não está aceitando um número imenso de spams e
> gerando
> > também um número imenso de bounces porque não faz verificação da
> validade
> > dos endereços de destinatário no envelope. o qmail, por default, não
> faz
> > tal verificação e sofre ataques de spammers que enviam mensagem para
> todo
> > o dicionário at domínio.
> >
> > ------------------------------
> 
> ------------------------------
> 
> Message: 6
> Date: Tue, 1 Feb 2005 18:33:20 -0200 (BRST)
> From: "Leonardo Queiroz de Mello" <lqmello at valencaonline.com>
> Subject: [GTER] Ipchains -> Iptables
> To: gter at eng.registro.br
> Message-ID:
>         <42041.200.244.128.130.1107290000.squirrel at 200.244.128.130>
> Content-Type: text/plain;charset=iso-8859-1
> 
> Hau lista,
> 
> Tenho mais de 3000 regras de ipchains para iptables, alguem sabe de alguma
> ferramenta para facilitar a migracacao.
> 
> ______________________________________________
> Email Seguro de Virus e Spam
> Acesse nossa página: http://www.valencaonline.com/
> 
> ------------------------------
> 
> Message: 7
> Date: Tue, 1 Feb 2005 18:54:23 -0200 (BRST)
> From: Lao DanTong <danton at inexo.com.br>
> Subject: Re: [GTER] Re: Re: Re: Qmail - Cluster
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
>         <gter at eng.registro.br>
> Message-ID:
>         <Pine.LNX.4.60.0502011843300.10569 at newquantum.inexo.com.br>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Tue, 1 Feb 2005, Aristeu Gil Alves Jr wrote:
> 
> > Não quero prolongrar uma discução que já acabou. Apenas discutindo um
> > assunto que tem sido recorrente na lista como bug de MTAs: o teste de
> > usuários no envelope.
> 
> há dois testes que podem ser feitos no envelope, um é o SPF, com o MAIL
> FROM comparado ao endereço IP. Outro é com o RCPT TO comparado com a lista
> de caixas postais locais.
> 
> pessoalmente sou a favor de testar o RCPT TO e dar erro se o destinatário
> não existir. ok, vão argumentar que assim um spammer pode validar
> endereços, mas em relação a problemas reais que já enfrentei, validação de
> endereços é café pequeno perto do estorvo que é um spam enviado para o
> dicionário do aurélio @ teu.dominio. são zilhões de mensagens entupindo
> tua fila, com outros tantos zilhões de bounces, virtualmente nocauteando
> o MTA. já enfrentei essa situação ao vivo e em cores, porisso em meus MTAs
> sempre faço a verificação do destinatário no envelope, com um requinte de
> sadismo: se der erro espero um tempo exponencialmente crescente antes de
> retornar a mensagem.
> 
> > Fazer verificação de usuários em nível de envelope pode gerar um
> > problema de mapeamento de usuários com o mesmo dicionário utilizado
> > por spamers. A unica coisa que o cara vai fazer é verificar "550 User
> > unknown" ou "250 Ok". Existem ferramentas para automatizar esse
> > processo.
> 
> sim, mas a estratégia de 'tarpitting', segurando a conexão quando o cara
> erra, torna a colheita inviável. no décimo 550 o cara já tem que esperar
> 1024 segundos, pois eu dobro o tempo a cada erro e começo com um segundo.
> 
> > Retira-se o VRFY dos servidores, mas testa-se os usuários logo no
> > envelope. Não sei
> > se isso chega a ser um problema real para grandes provedores.
> > Acaba, no final, sendo uma relação custo vs benefício, ou Economia de
> > Banda vs Harvesting. É um bom tema para discução, ou não. :-)
> 
> não é só de banda. tem a bendita fila, e todos os bounces que
> provavelmente vão dar erro porque os endereços de remetente tabém são
> falsos...
> 
> ------------------------------
> 
> Message: 8
> Date: Tue, 1 Feb 2005 18:58:43 -0200
> From: "Aristeu Gil Alves Jr" <suporte at wahtec.com.br>
> Subject: [GTER] Re: Re: Qmail - Cluster
> To: <gter at eng.registro.br>
> Message-ID: <009201c508a0$d0d13bd0$1503000a at wahtemp>
> Content-Type: text/plain;       charset="iso-8859-1"
> 
> * Agora, com corretor ortográfico. sorry.
> 
> Não quero prolongar uma discussão que já acabou. Apenas discutindo um
> assunto que tem sido recorrente na lista como bug de MTAs: o teste de
> usuários no envelope.
> 
> Como o postfix/sendmail/exim/... implementam proteção contra
> mapeamento de
> usuários? Gostaria de saber algumas técnicas, pois não sou grande
> usuário destes MTAs.
> 
> Fazer verificação de usuários em nível de envelope pode gerar um
> problema de mapeamento de usuários com o mesmo dicionário utilizado
> por spamers. A única coisa que o cara vai fazer é verificar "550 User
> unknown" ou "250 Ok". Existem ferramentas para automatizar esse
> processo.
> 
> Retira-se o VRFY dos servidores, mas testa-se os usuários logo no
> envelope. Não sei
> se isso chega a ser um problema real para grandes provedores.
> Acaba, no final, sendo uma relação custo vs benefício, ou Economia de
> Banda vs Força Bruta. É um bom tema para discussão, ou não. :-)
> 
> []'s
> --aristeu
> 
> >
> > --------------------------------------------------------------------
> > --
> > >
> > > Message: 1
> > > Date: Tue, 1 Feb 2005 15:30:37 -0200 (BRST)
> > > From: Lao DanTong <danton at inexo.com.br>
> > > Subject: Re: [GTER] Re: Re: Re: Qmail - Cluster
> > > To: security at onda.com.br, Grupo de Trabalho de Engenharia e
> Operacao
> > > de Redes <gter at eng.registro.br>
> > > Message-ID:
> > <Pine.LNX.4.60.0502011524570.1943 at newquantum.inexo.com.br>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > On Tue, 1 Feb 2005, Anderson Nadal wrote:
> > >
> > > > Todo software tem bug, inclusive os utilizados pela NASA, nao
> > esqueca
> > > > que 2 onibus espaciais literalmente foram pro espaco. :)
> > >
> > > em nenhum caso, que eu saiba, por causa de bug de software.
> > >
> > > eu acho que esta conversa está ficando meio besta. mail-toasters
> > podem ser
> > > feitos com praticamente qualquer MTA, até o bom e velho sendmail
> > > incrementado com LDAP dá bem no couro. que tal parar com essa
> > ridícula
> > > querela religiosa de postfix x qmail?
> > >
> > > quanto a ter um volume imenso de mensagens, sem ser um UOL da
> vida,
> > convém
> > > verificar se você não está aceitando um número imenso de spams e
> > gerando
> > > também um número imenso de bounces porque não faz verificação da
> > validade
> > > dos endereços de destinatário no envelope. o qmail, por default,
> não
> > faz
> > > tal verificação e sofre ataques de spammers que enviam mensagem
> para
> > todo
> > > o dicionário at domínio.
> > >
> > > ------------------------------
> >
> 
> ------------------------------
> 
> Message: 9
> Date: Tue, 01 Feb 2005 20:32:54 -0200
> From: Marcelo Estanislau <marcelo at standardnet.com.br>
> Subject: [GTER] Re: Qmail - Cluster
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
>         <gter at eng.registro.br>
> Message-ID: <42000396.6070605 at standardnet.com.br>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Tenho certeza que cada administrador provê de configurações diferentes
> de um para o outro, seja no tamanho de inodes alocados para cada
> partição, práticas adotadas para a entrega de e-mails, acondicionamento
> dos servidores e tudo mais.
> 
> Confesso que no primeiro instante fiquei um pouco "boquiaberto" com a
> alocação da fila queue na ramdisk, como é considerado uma coisa
> *inusitada* por mim, não podemos perder o respeito pelo amigo e ver isso
> como uma alternativa a ser considerada para os que viram isso com
> simpatia. Sinceramente, sem perder o respeito, sou um pouco mais
> reservado, por não possuir uma estrutura de primeiro mundo, sinto-me
> mais seguro com uma configuração mais tradicional e replicação para
> outros servidores.
> 
> Também devemos lembrar muito bem que quando falamos em sistema
> operacional de verdade e uptime de máquinas, não estamos falando de
> estações windows que após atualizações devem ser reiniciados. É possível
> aplicar patches ao kernel e fazer atualização de componentes/aplicativos
> sem necessidade restartar o servidor.
> 
> Alexandre Hautequest wrote:
> 
> >
> >
> >A unica coisa que nao foi atualizada foi o kernel. Para todas as outras,
> >init 1 e a console do equipamento sao meus amigos.
> >
> >Nao me preocupo com meu uptime estratosferico, porque tem ao menos
> >outras 15 maquinas na internet com uptime maior que o meu, conforme
> >podemos ver neste endereco: http://uptime.netcraft.com/up/today/top.avg.html
> >
> >Se nao me engano, ha um tempo atras (ano passado, maio, abril...) houve
> >um topico aqui na lista onde comentavamos exatamente sobre o tal bug do
> >uptime no linux, e nas comparacoes que aconteceram na continuacao do
> >mesmo, "perdemos" para um FreeBSD que deve estar hoje na casa dos 4 anos
> >online.
> >
> >E pelo contrario, a administracao existe e esta sendo pontual: a maquina
> >funciona perfeita ha quase 3 anos.
> >
> >
> >
> 
> --
> Marcelo Estanislau Geyer
> marcelo at standardnet.com.br
> Standard Net Tecnologia e Informação
> http://www.standardnet.com.br
> 
> ------------------------------
> 
> --
> GTER digest list    https://eng.registro.br/mailman/listinfo/gter
> 
> End of GTER Digest, Vol 23, Issue 9
> ***********************************
>