Greylisting com Postfix - É possível não usar greylist conexões que são do MX do host?

Question

Eu configurei recentemente um servidor de e-mail e estou usando o greylisting como uma maneira de lidar com spam. A principal desvantagem da greylisting é que ela pode atrasar seu email. No entanto, pensei em uma maneira de acelerar. Se o host X se conectar e quiser enviar um e-mail de [email protected] e o registro MX de example.com, não o digite, e deixe-o embora imediatamente.

Isso deve evitar spam da maneira normal e eliminar o atraso de alguns hosts, certo?

Existe alguma maneira de fazer isso ou estou incorreto?

Estou usando o Postfix e o postgrey.

    

Answer 1

O Postgrey não vai apoiar isso, no entanto, não há nada que o impeça de criar ou encontrar um servidor de políticas que faça isso. Se o seu primeiro servidor de políticas, vamos chamá-lo dns-checker.sh, passa então o e-mail é entregue. Se falhar, o postfix passa para a próxima verificação, em ordem, sob smtpd_recipient_restrictions.

Para qualquer servidor de lista cinza, recomendo definir a duração máxima para 63 dias, ou seja, dois meses completos, mais um dia. Eu prefiro tempo de atraso para ser 30 seg. Um atraso tende a ser um atraso, independentemente de quanto tempo ele é e muitos servidores de webmail grandes tentam novamente em um minuto para que o atraso geral seja muito baixo. Você também desejará usar a classe C como parte da tupla, em vez do IP específico, que deve ser o padrão. Eu também uso a lista de permissões automática do domínio se um número x de e-mails for retransmitido, o que é bastante liberal. Com essas configurações, raramente tenho problemas com atraso.

O site do Postfix lista vários addons no cabeçalho do Policy Server nesse URL. link O pacote smtpd-policy-template parece ser o mais interessante, pois é basicamente um modelo para criar seu próprio servidor de políticas. É claro que ainda cabe a você escrever a lógica e realmente codificar. : -)

    

Answer 2

Você pode dizer ao postgrey para não organizar alguns hosts ( /etc/postgrey/whitelist_clients ), ou você pode colocar em uma lista de acesso antes da checagem da política postgrey que lista (e aceita) seus MXes. O que fizer mais sentido para você.

    

Answer 3

Eu nunca usei o Postfix e o postgrey, mas a teoria deve funcionar se você puder fazer isso acontecer.

Também estou usando greylisting em nosso servidor de e-mail e o uso há alguns anos. Funciona muito bem, blocos 95 +% spam inicialmente de entrar. E porque eu tenho a mesma preocupação que a sua, eu só faço isso fora do trabalho, como desligá-lo às 6:00 pm e ligá-lo novamente às 7:00 da manhã seguinte .

    

Answer 4

Eu uso o Postgrey com o Postfix eu mesmo e tenho hosts MX externos que têm suas prioridades definidas, então eles só devem receber e-mails se o servidor principal não puder ser acessado. Em alguns casos, esses servidores MX não são administrados por mim, portanto, não posso assumir que o e-mail que vem deles não seja spam.

A forma como o Postgrey trabalha olha para uma tupla de envio de IP, endereço do remetente e endereço do destinatário. Para o correio enviado por um MX, o IP de envio será sempre o do seu MX. Que enquanto sim você poderia whitelist o IP, derrotaria o propósito de greylisting no primeiro lugar.

A menos que você tenha certeza de que o e-mail enviado para o seu servidor de e-mail a partir de um MX não seja spam, sugiro que não tente causar um curto-circuito no processo de lista cinza. Se o e-mail for regular, o atraso só ocorrerá quando uma nova tupla for vista e o e-mail fluirá suavemente a partir de então.

    

Answer 5

Os spammers estão se recuperando e o graylisting pode não ser tão eficaz quanto costumava ser. Se você puder, tente usar alguns RBLs, acho que eles são mais eficazes. YMMV.

AFAIK, postgrey não pode determinar se o IP do servidor remoto corresponde ao IP do registro MX do domínio do remetente. Algumas outras ferramentas podem ser mais adequadas à tarefa, dê uma olhada na página complementar do postfix para isso.

Como uma nota lateral, qualquer técnica que você use, pode ter um lado negativo. Às vezes, as RBLs podem bloquear alguns emails legítimos (embora eu ache isso muito raro com boas RBLs e geralmente valham a pena) e o graylisting causa um atraso. Além disso, em relação ao seu plano, a caixa do remetente pode não ser a mesma para a qual o registro MX está apontando, portanto, pode não ser eficiente se você estiver lidando principalmente com e-mails de grandes domínios. Você precisará do endereço do remetente para procurar o registro MX do domínio e, como sabemos, é facilmente falsificado. Servidores ocasionalmente processam mensagens para mais de um domínio.

Em um lado mais claro, o postgray implementa listas de permissões automáticas de clientes que repetidamente demonstram ser capazes de passar a lista de greyl. Então, a menos que você realmente precise, talvez você não devesse se preocupar muito com o atraso.