[Reox]

En el tema de los PTR sobre el DNS de OVH es probable que tengas tu la razón, estoy mas aconstumbrado a gestionar redes completas que al alquiler de servidores y las pruebas que he hecho avalan tu respuesta.

El incremento de carga respecto al servidor de correo al activar esta característica proviene de la validación de la mayoria de los sistemas antispam que poseen los destinatarios (generalmente hotmail, gmail, yahoo, etc...) que incrementan un poquito mas el coste de la transferencia de un correo al validar la consulta de spf (si mandas un medio millon de correos se nota, para el resto es imperceptible).

[josu]

¿Que tienen que ver los SPF con mi POST? Yo estoy hablando del campo PTR, no de los posibles TXT que pongas para el SPF.

Una cosa es la resolución de un dominio y otra cosa es la resolución inversa de una IP. En el caso de OVH la inversa la resuelven ellos en sus DNS y para ello implementan la opción en su panel de control. Aunque la resuelvan los DNS de OVH, deberías poner los mismos PTR en tus servidores DNS.

Si la resolución inversa es importante, sí, muchos servidores de correo te la van a exigir.

Una vez dicho esto, no entiendo como puede incrementarte la carga definir una resolución inversa que ni siquiera tus servidores la van a resolver por norma.

Josu.

[Reox]

Uhmm, ¿estás seguro de esas cifras?

...

PD: Igual lo confundís con el hecho de que un servicio (apache, qmail, etc) realice resoluciones inversas sobre las IPs de sus registros/logs. Eso sí que carga la máquina y suele aconsejarse desactivarlos.

Las cifras son estimativas sobre el parcial de carga del servicio de correo y de uso meramente estimativo, es decir, son únicamente para hacerse una idea aproximada aunque según mi experiencia se aproximan bastante a la realidad.

Sobre lo de ponerlo en el DNS de OVH no estoy de acuerdo del todo partiendo de la idea de que el spf lo que hace es validar que el origen del correo sea el mismo al que apunta el mx del dominio del emisor.

Si nos vamos a herramientas online para que lo vea todo el mundo podemos ver que en un sencillo test: http://www.kitterman.com/spf/validate.html
Pasa el test cualquier dominio que tenga definido el spf en el dns al que apunta el dominio que puede ser el mismo servidor de correo porque lo que estamos validando no es la ruta que sigue el correo sino la ip del emisor con respecto a la mx del DNS.

[josu]

Te confirmo que sí, el PTR carga mucho mas el servidor un 5% mas de ram y el trafico consumido por el correo aumenta del orden de un 2%.

Uhmm, ¿estás seguro de esas cifras?

Realmente cuando alguien pide una resolución inversa de tu IP pasa por los servidores de OVH y no los tuyos. El PTR válido es el que configures en el panel de OVH:

$ dig NS 160.251.213.in-addr.arpa.

; <<>> DiG 9.4.2 <<>> NS 160.251.213.in-addr.arpa.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16659
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;160.251.213.in-addr.arpa. IN NS

;; ANSWER SECTION:
160.251.213.in-addr.arpa. 86400 IN NS dns.ovh.net.
160.251.213.in-addr.arpa. 86400 IN NS ns.ovh.net.

;; ADDITIONAL SECTION:
ns.ovh.net. 172690 IN A 212.27.32.132
dns.ovh.net. 170735 IN A 213.186.33.102

;; Query time: 147 msec
;; SERVER: 212.142.144.66#53(212.142.144.66)
;; WHEN: Tue Apr 29 12:06:40 2008
;; MSG SIZE rcvd: 116

Lo cual no quita para que tengas en tus DNS definidos los mismos PTR que en el panel de OVH.

Josu.

PD: Igual lo confundís con el hecho de que un servicio (apache, qmail, etc) realice resoluciones inversas sobre las IPs de sus registros/logs. Eso sí que carga la máquina y suele aconsejarse desactivarlos.

[Reox]

Configuratelo usando este wizard: http://old.openspf.org/wizard.html

Te confirmo que sí, el PTR carga mucho mas el servidor un 5% mas de ram y el trafico consumido por el correo aumenta del orden de un 2%.

[Pepeton]

Gracias reox.

Osea, debo de cambiar el TXT en todos los dominio como me explicas (con espacio despues de include

"v=spf1 a mx ptr include: dominio.com exp=spf-err -all"

Y ¿la entrada PTR es como estaba xxx.xxx.xxx.xxx/24?

Perdona, pero cuanto mas consulto a don Google menos claro lo tengo, por eso consulto a gente con mas conocimientos que yo.

Saludos y gracias.

Edito: En algún sitio lei que usar el PTR carga mas el servidor por las consultas que se hacen a este para cada correo enviado. (no lo se).

[Reox]

Buenas,

Esto que has escrito significa que te va funcionar el spf para los correos que mandes desde la dirección ip de correo como tucorreo@XXX.XXX.XXX.XXX

"v=spf1 a mx ip4:XXX.XXX.XXX.XXX -all"

pero no desde una dirección por dominio como tucorreo@dominio.com, evidente en el caso que has puesto no se necesita el PTR por que no existe ningun dominio que resolver sobre el que hacer el dns reverso.

Lo lógico seria que la entrada fuera del tipo:

"v=spf1 a mx ptr include: dominio.com exp=spf-err -all"

y ahi si necesitas el ptr porque sino no se hace el RDNS sobre el dominio.

[Pepeton]

Buenos días.

Pues eso, igual es una pregunta tonta. Pero resulta que no lo tengo claro, en algún sitio he visto que con poner un registro TXT para activar la ptotección SPF en el correo es suficiente, pero en otros veo que es necesario el registro PTR.

Espero que algún "gurú" de las DNS me puede aclarar un poquito el tema.

En mi servidor con panel Plesk viene por defecto una entrada PTR para cada dominio apuntando a la IP/24. En algunos dominios lo he quitado y he incluido una entrada TXT del tipo "v=spf1 a mx ip4:XXX.XXX.XXX.XXX -all" para activar el SPF.

A simple vista funciona todo correctamente en estos dominios, pero ¿borro o no borro la entrada PTR apuntando a la IP?.

Saludos y gracias.