Estoy ejecutando postfix en un Linode.
Linux redacted 5.3.11-x86_64-linode131 #1 SMP PREEMPT Wed Nov 13 18:51:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
amavisd-new-postfix/xenial,xenial,now 1:2.10.1-2ubuntu1 all [installed]
postfix/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-mysql/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-pcre/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-policyd-spf-python/xenial,xenial,now 1.3.2-1 all [installed,automatic]
En lugar de complicarme con la cuarentena, tengo mi instalación de Postfix configurada para rechazar el correo electrónico RBL y SPFFAIL. Lamentablemente, tengo una empresa de la que necesito recibir un correo electrónico que tiene un registro SPF incorrecto y que ha estado así durante algún tiempo. Como tal, en lugar de correo electrónico, recibo registros agradables como este:
1 de abril 10:41:42 postfix/smtpd redactado[18833]: NOQUEUE: rechazar: RCPT de us-smtp-delivery-134.mimecast.com[216.205.24.134]: 550 5.7.1: Dirección del destinatario rechazada: Mensaje rechazado debido a: Error de SPF - no autorizado. Por favor mirahttp://www.openspf.net/Why?s=mfrom;id=redacted;ip=216.205.24.134;r=redacted; from=< redactado> a=< redactado> proto=ESMTP helo=< us-smtp-delivery-134.mimecast.com>
Dicha empresa no tiene un contacto que pueda solucionar este problema en su sitio web o en su información de WHOIS (supongo que un registrante @dnstinations.com [algún proveedor externo] ignorará un correo electrónico de un tercero que dice El DNS está mal configurado).
La primera vez que recibí este registro en lugar de un correo electrónico, intenté incluir en la lista blanca *.mimecast.com, pero eso no hizo ninguna diferencia, así que hoy eché un vistazo a mi main.cf. Vi que la configuración de SPF estaba en una línea diferente a mis listas blancas, así que pensé que tal vez podría crear una lista blanca separada de SPF específica. Así es como se veía mi main.cf antes:
smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access regexp:/etc/postfix/rbl_client_regex, check_client_access hash:/etc/postfix/rbl_client_override, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service unix:private/policy-spf
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access, reject_unknown_sender_domain
Así es como se ve ahora:
smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access regexp:/etc/postfix/rbl_client_regex, check_client_access hash:/etc/postfix/rbl_client_override, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, regexp:/etc/postfix/spf_client_regex, check_policy_service unix:private/policy-spf
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access, reject_unknown_sender_domain
Básicamente, todo lo que hice en main.cf fue agregar "expresión regular:/etc/postfix/spf_client_regex," antes "check_policy_service unix:privado/policy-spf" en el "smtpd_recipient_restrictions" sección.
También creé /etc/postfix/spf_client_regex con esta entrada (esto parece bastante seguro ya que mimecast es un proveedor antispam):
/.*\.mimecast\.com$/ OK
Probé eso con postmap -q, obtuve el resultado esperado "OK", ejecuté "postmap /etc/postfix/spf_client_regex" para actualizar lo que sea que se actualice y recargué postfix. Desafortunadamente, el correo de este remitente continúa bloqueado por fallas de SPF.
Entonces, esperaba que los pasos anteriores fueran correctos considerando que son básicamente los mismos que los pasos tomados para las reglas de la lista blanca en la sección smtpd_client_restrictions que hacen que se ignoren las reglas de rechazo_rbl_client, pero no funciona. Como se indica en el título de esta publicación: ¿Puedo anular la política SPF usando una lista blanca? ¿Cómo?
Respuesta1
Bien, leí un poco el manual después del comentario deAcantilado Armstrong, y creo que he encontrado una solución. Primero, descubrí que si bien smtpd_client_restrictions y smtpd_sender_restrictions permiten el análisis de tablas, ninguno permite el procesamiento de políticas. A continuación, encontré quepolíticas personalizadasse puede crear, pero esto parecía algo que no debería requerir que yo aprendiera un lenguaje de programación para poder resolverlo, así que hice una búsqueda que me llevó aesta publicacióncon algunas quejas razonables sobre un delegado de políticas del SPF en particular y explicaciones sobre cómo incluir en la lista blanca a ambos delegados de políticas del SPF que están disponibles actualmente.
Quiso la suerte que ya tenía instalado el "mejor" delegado de políticas, así que no tuve que cambiarlo:
~$ apt list | grep policyd-spf
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
postfix-policyd-spf-perl/xenial,xenial 2.010-2 all
postfix-policyd-spf-python/xenial,xenial,now 1.3.2-1 all [installed,automatic]
A continuación, revisé el archivo comentado (bueno, en mi caso estaba comprimido con gzip, así que hice una copia en gunzip y luego eliminé esa copia cuando terminé) y encontré estos comentarios relevantes:
# Whitelist: CIDR Notation list of IP addresses not to check SPF for.
# Example (default is no whitelist):
# Whitelist = 192.168.0.0/31,192.168.1.12
# Domain_Whitelist: List of domains whose sending IPs (defined by passing
# their SPF check should be whitelisted from SPF.
# Example (default is no domain whitelist):
# Domain_Whitelist = pobox.com,trustedforwarder.org
En base a eso, parecelista_blanca_dominiono funcionará para mí ya que el comentario dice "definido al pasar su verificación de SPF debe estar incluido en la lista blanca de SPF". Esto parece extraño (si el remitente pasó la verificación spf del dominio, no necesitaría incluirlo en la lista blanca), pero todavía tengo lalista blancaopción, así que encontrédocumentación mimecast spfy luego recopiló las IP usando nslookup:
~$ nslookup
> set type=txt
> us._extnetblocks.mimecast.com
;; Truncated, retrying in TCP mode.
Server: 50.116.58.5
Address: 50.116.58.5#53
Non-authoritative answer:
us._extnetblocks.mimecast.com text = "v=spf1 ip4:207.211.30.40 ip4:207.211.30.41 ip4:207.211.30.42 ip4:207.211.30.43 ip4:207.211.30.44 ip4:207.211.30.45 ip4:207.211.30.46 ip4:207.211.30.47 ip4:207.211.30.48 ip4:207.211.30.49 ip4:205.139.111.40 ip4:205.139.111.41 ip4:205.139.111.42 " "ip4:205.139.111.43 ip4:205.139.111.44 ip4:205.139.111.45 ip4:205.139.111.46 ip4:205.139.111.47 ip4:205.139.111.48 ip4:205.139.111.49 ~all"
Authoritative answers can be found from:
mimecast.com nameserver = dns02.mimecast.net.
mimecast.com nameserver = dns03.mimecast.net.
mimecast.com nameserver = dns04.mimecast.net.
mimecast.com nameserver = dns01.mimecast.net.
Luego tomé esos resultados y los colgué en el archivo de configuración:
Whitelist = 207.211.30.40, 207.211.30.41, 207.211.30.42, 207.211.30.43, 207.211.30.44, 207.211.30.45, 207.211.30.46, 207.211.30.47, 207.211.30.48, 207.211.30.49, 205.139.111.40, 205.139.111.41, 205.139.111.42, 205.139.111.43, 205.139.111.44, 205.139.111.45, 205.139.111.46, 205.139.111.47, 205.139.111.48, 205.139.111.49
Esto no es ideal ya que permitirá automáticamente que estas IP se envíen desde otros dominios y las IP podrían cambiar de manos, pero es lo suficientemente bueno para mi implementación privada. Como tal, no voy a intentar aprender a crear mi propio delegado ni a contratar a alguien para que cree uno por mí. Si obtengo otro resultado NOQUEUE similar a pesar de estos cambios, agregaré una nota a esta respuesta.