Parámetros óptimos establecidos para Postfix "smtpd_recipient_restrictions"


8

hemos heredado el DNS de otro ISP y ahora nuestro servidor de correo está bombardeado por aproximadamente 1000 correos electrónicos por minuto, el 99.99% de estos correos electrónicos son solo spam. Estamos tratando de optimizar el filtrado / rechazo del spam sin mucha suerte.

¿Cuál sería en tu opinión el conjunto óptimo para smtpd_recipient_restrictions?

La configuración del sistema: Ubuntu + Amavis + Postfix + MySQL + Fail2Ban-Postfix

Cualquier consejo es bienvenido!

UDPATE, 2012-08-08

Al modificar la configuración de posftix como sigue y configurar el servicio Potrgey, el nivel de spam disminuyó 10 veces

smtpd_recipient_restrictions = 
permit_mynetworks, 
permit_sasl_authenticated, 
reject_non_fqdn_hostname, 
reject_invalid_hostname, 
reject_non_fqdn_sender, 
reject_unknown_sender_domain, 
reject_non_fqdn_recipient, 
reject_unknown_recipient_domain, 
check_policy_service inet:127.0.0.1:10023, 
reject_rbl_client zen.spamhaus.org, 
check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf,
reject_unauth_pipelining, 
reject_unauth_destination

ingrese la descripción de la imagen aquí


1
¡Quiero comprar ese dominio! Por favor haga una oferta.
mailq

¿Qué intentas resolver? ¿Cual es tu problema? Solo dices que rechazas el spam. Pero esto no es un problema. Esta es una solucion.
mailq

@mailq: de ninguna manera lo siento
Igor

@mailq: la idea es rechazar el spam de manera más efectiva, reducir las cargas del sistema
Igor

Respuestas:


6

Tu orden de reglas es muy mala. Si desea conservarlos todos y no agregar nada más, el orden debe ser:

smtpd_recipient_restrictions = 
permit_mynetworks, 
permit_sasl_authenticated, 
reject_unauth_pipelining, 
reject_invalid_hostname, 
reject_non_fqdn_sender, 
reject_unknown_sender_domain, 
reject_unauth_destination, 
reject_unknown_recipient_domain, 
reject_rbl_client zen.spamhaus.org,
check_recipient_access proxy:mysql:/etc/postfix/mysql-virtual_recipient.cf, 
reject_non_fqdn_recipient

Y si eso todavía no es suficiente, lea sobre postscreenen http://www.postfix.org/POSTSCREEN_README.html .


lo siento pero importa el orden o no? en cierto sentido, postfix verifica al principio "permit_mynetworks" y, por último, "accept_non_fqdn_recipient".
Igor

1
Definitivamente! El orden importa. De izquierda a derecha (o de arriba a abajo). Como se describe en postfix.org/SMTPD_ACCESS_README.html
mailq

5

Sugeriría una smtpd_recipient_restriction similar a la siguiente:

smtpd_recipient_restricdtions = 
# Whitelisting or blacklisting:
check_recipient_access proxy:mysql:/etc/postfix/mysql-virtual_recipient.cf,
# Everyone should play after rules:
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unknown_recipient_domain,
reject_unknown_sender_domain,
reject_unauth_pipelining,
# Mails from your users:
permit_mynetworks,
permit_sasl_authenticated,
# This will block mails from domains with no reverse DNS record. Will affect both spam and ham mails, but mostly spam. 
reject_unknown_reverse_client_hostname,
# Instead of reject_unknown_reverse_client_hostname you can also use reject_unknown_client_hostname, which is an even harder rule. 
# Reject ugly HELO/EHLO-hostnames (could also affect regular mails):
reject_non_fqdn_hostname,
reject_invalid_helo_hostname,
# Reject everything you're not responsible for:
reject_unauth_destination,
# Only take mails for existing accounts:
reject_unverified_recipient,
# DNS lookups are "expensive", therefore should be at bottom
reject_rbl_client zen.spamhaus.org

Puede encontrar información detallada sobre smtpd_recipient_restrictions aquí: http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions

Quizás también desee utilizar postgrey , postscreen , postfwd o algún otro demonio de políticas .

Y también verifique que esté usando su amavisd-new en modo pre-cola.


Esto es malo. La segunda línea bloquea el correo para cualquier destinatario saliente. Por lo tanto, no puede enviar correos desde su servidor al mundo exterior. Las consultas MySQL son igual de caras que las consultas DNS. Por lo tanto, también debe mover las consultas MySQL al final.
mailq
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.