Postfix replace_unknown_reverse_client_hostname: reemplace default unknown_client_reject_code (450) a 550. ¿Por qué / cuándo no debería?

En la batalla diaria contra el SPAM, en varias ocasiones he tenido la tentación de hacer cumplir los requisitos de DNS de los clientes que se conectan desde Internet.

En detalle, habría agregado la configuración del rechazo_desconocido_reverso_nombre_host_cliente dentro de mi sección smtpd_client_restrictions , como en:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            reject_unknown_reverse_client_hostname
            reject_unauth_pipelining 

De todos modos, noté que cuando se aplica dicha restricción, el comportamiento de Postfix es bastante "blando" ya que el valor predeterminado para unknown_client_reject_code450 es. Por lo tanto, se invita al cliente a seguir intentándolo nuevamente.

Mientras investigaba una respuesta 550, me encontré con la siguiente declaración, en la documentación oficial de Postfix :

Estoy absolutamente no un experto acerca de todo el RFC 5321 , pero como alguien lo suficientemente mayor para saber RFC 821 , realmente no veo por qué, una respuesta en lugar de un 450 550, podría afectar mi ejemplo Postfix en el nivel máximo de SMTP ( romper el cumplimiento de RFC), especialmente considerando que en caso de errores temporales, Postfix se mantendrá con un 450 independientemente de la configuración explícita.

Entonces, ¿alguien puede ayudarme a entender cuál es el problema con tal reemplazo?

PD: mientras tanto, terminé con una restricción "relajada":

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            warn_if_reject reject_unknown_reverse_client_hostname
            reject_non_fqdn_helo_hostname
            reject_unauth_pipelining 
            reject_invalid_helo_hostname 

Comenzaré con dos respuestas prácticas.

1. La primera y más obvia respuesta es que, en el caso de que haya un error temporal de DNS, un rebote temporal permitirá que el servidor de correo del remitente vuelva a intentarlo hasta que se solucione el error de DNS. En este caso, un rebote permanente impedirá que el correo de jamón real llegue a usted.

2. La segunda respuesta es que se envía una gran cantidad de correo no deseado a través de cajas de botnet que no tienen ninguna forma de programas funcionales reales para enviar el correo. Rociarán su basura solo una vez, y no intentarán reenviar ningún mensaje si dicho mensaje recibe un error temporal o permanente. Entonces, al usar un error temporal, está bloqueando un gran porcentaje del spam para siempre, pero todavía está permitiendo que Ham lo intente nuevamente. (Por cierto, esta es la razón por la que las listas grises todavía funcionan y aún atrapan mucho spam).

Además de estas, también hay una respuesta que se relaciona más con la teoría y el RFC.

El RFC dice en la sección 4.2.1. ese:

Una regla general para determinar si una respuesta encaja en la categoría 4yz o 5yz (ver más abajo) es que las respuestas son 4yz si pueden tener éxito si se repiten sin ningún cambio en el formulario de comando o en las propiedades del remitente o receptor (es decir, , el comando se repite de forma idéntica y el receptor no presenta una nueva implementación).

En el caso de una falla de búsqueda inversa, sería posible que el mensaje fuera aceptable sin ningún cambio en el mensaje mismo, siempre que el error de DNS sea reparado. Por lo tanto, esto debería ser un error temporal.

En el caso de que el mensaje no sea spam, el administrador del servidor de correo remitente puede notar el mensaje de error y solucionar el problema de DNS, de modo que el mensaje se pueda entregar sin que el usuario tenga que intervenir y volver a enviar el mensaje. Y a menos que el usuario que envía el correo electrónico también esté a cargo del servidor de correo y / o sus entradas DNS, incluso si obtienen un rebote permanente directamente, no podrán hacer nada con él, a diferencia, por ejemplo, del caso de un error ortográfico habla a.

Por supuesto, siempre tiene el derecho de rechazar cualquier correo electrónico por cualquier motivo.