Mailinglist Archive: opensuse-es (2081 mails)
| < Previous | Next > |
Re: [suse-linux-s] Re: acerca del dnsreport y SPF Record
- From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
- Date: Thu, 9 Nov 2006 15:41:48 +0000 (UTC)
- Message-id: <Pine.LNX.4.64.0611091617360.4080@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El 2006-11-09 a las 15:20 +0100, Camaleón escribió:
> El 9/11/06, Carlos E. R. escribió:
>
> > No, eso está bien hecho así. Si se usara el campo from todos los correos
> > de la lista darían falsos. Es a propósito.
>
> El campo "From" tampoco es un dato válido. Lo que importa es la ip y
> el servidor, nada más. Si ambos datos coinciden, pasa la prueba del
> psf, lo cual te dice al menos "de dónde viene ese mensaje".
No se puede, piensalo bien.
El correo te lo está entregando un servidor que dice ser "alfa" (en el
ehlo me parece que es). Miras en el DNS y te dice que debe tener la IP
x.x.x.x, y además tiene un SPF que dice que la IP autorizada para el
dominio es la x.x.x.x, y el postfix comprueba que la conexión viene,
efectivamente, de esa IP, o sea, todo correcto. Luego el correo pasa, es
válido, según ese test.
Pero resulta que el servidor "alfa" es un nido de spammers. En realidad,
el correo dice venir del banco de españa en el campo from. Luego no has
conseguido nada, el spam entra y a raudales, le has abierto la puerta de
par en par.
>
> > Si que la tiene, pero no he conseguido ver si funciona. Acabo de mirar
> > correos recibidos de gmail directos y no veo que el SA diga nada del SPF
> > si o no.
>
> Tienes que activar la regla, creo que viene desactivada.
La tengo activada en "/etc/mail/spamassassin/init.pre":
loadplugin Mail::SpamAssassin::Plugin::SPF
Mira, de un correo tuyo que recibí directo en septiembre pasado:
Return-Path: <noelamac en gmail.com>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on nimrodel.valinor
X-Spam-Level:
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,
DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3
No dice nada de SPF sí o no.
> > No, a ellos no les beneficia, sería a nosotros. Ellos no pueden rechazar
> > correo con eso.
>
> Claro que pueden. Por ejemplo, las cuentas de Gmail. Hay muchos
> mensajes de spam en los que su From o su return-path son de
> "gmail.com" cuando realmente esos datos son falsos. Si Gmail tiene
> configurado spf y el servidor de la lista lo usa, pues todos esos
> correos quedan fuera.
Son dos cosas distintas. Una, que suse defina campos SPF en su DNS, que no
lo ha hecho, lo cual nos impide a nosotros rechazar los falsos usando SPF.
Otra es que SuSE emplee filtros basados en SPF en la entrada, y no lo
hace, ni siquiera emplea listas negras en el postfix (sí en el
spamassassin).
Gmail en cambio sí lo tiene en su DNS, pero no tengo ni idea de si usa
filtros de entrada y cuales.
> > No, no es eso el problema. No se puede usar el campo "from". El return
> > path indica cual es el servidor que se responsabiliza del correo, es la
> > dirección del remite del sobre. El "from" está en el interior, no se puede
> > mirar.
>
> Yo no he hablado del campo From, Carlos. Ese dato también suele ser falseado.
¿Y entonces cual usarías? Porque el identificador del servidor que llega
creo que en EHLO tampoco vale, lo he demostrado arriba.
>
> > Eso sí que lo sabes con SPF. Si recibes un correo de un dominio
> > determinado sabes de que IP tiene que venir, y si viene de otra, lo
> > rechazas. En teoría.
>
> Pues ya es un paso. Es decir, si un servidor de correo me dice que
> efectivamente ese mensaje viene de él, puedo relajar las reglas de
> filtrado para ese correo, por ejemplo. En cambio, un correo tuyo ;-),
> como viene directamente de una ip y sólo tengo ese dato, pues le
> aplico todos los filtros posibles, porque el 90% de los casos suele
> ser un correo de spam.
No te fies mucho, porque te lo puedo envíar a través del relay de tesa, y
to'er mundo mudial sabe que telefonica y terra y sus alias son un nido de
spammers que te cagas. Hasta hay reglas en el SpamAssassin que hablan de
terra...
- --
Saludos
Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFFU0wutTMYHG2NR9URAk9yAJ4wkGXdH3VcUoTkPbduxIXH9itQLACeNc1Q
1mnjECdDVWaQnZeKN1e/RUY=
=E1un
-----END PGP SIGNATURE-----
Hash: SHA1
El 2006-11-09 a las 15:20 +0100, Camaleón escribió:
> El 9/11/06, Carlos E. R. escribió:
>
> > No, eso está bien hecho así. Si se usara el campo from todos los correos
> > de la lista darían falsos. Es a propósito.
>
> El campo "From" tampoco es un dato válido. Lo que importa es la ip y
> el servidor, nada más. Si ambos datos coinciden, pasa la prueba del
> psf, lo cual te dice al menos "de dónde viene ese mensaje".
No se puede, piensalo bien.
El correo te lo está entregando un servidor que dice ser "alfa" (en el
ehlo me parece que es). Miras en el DNS y te dice que debe tener la IP
x.x.x.x, y además tiene un SPF que dice que la IP autorizada para el
dominio es la x.x.x.x, y el postfix comprueba que la conexión viene,
efectivamente, de esa IP, o sea, todo correcto. Luego el correo pasa, es
válido, según ese test.
Pero resulta que el servidor "alfa" es un nido de spammers. En realidad,
el correo dice venir del banco de españa en el campo from. Luego no has
conseguido nada, el spam entra y a raudales, le has abierto la puerta de
par en par.
>
> > Si que la tiene, pero no he conseguido ver si funciona. Acabo de mirar
> > correos recibidos de gmail directos y no veo que el SA diga nada del SPF
> > si o no.
>
> Tienes que activar la regla, creo que viene desactivada.
La tengo activada en "/etc/mail/spamassassin/init.pre":
loadplugin Mail::SpamAssassin::Plugin::SPF
Mira, de un correo tuyo que recibí directo en septiembre pasado:
Return-Path: <noelamac en gmail.com>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on nimrodel.valinor
X-Spam-Level:
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,
DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3
No dice nada de SPF sí o no.
> > No, a ellos no les beneficia, sería a nosotros. Ellos no pueden rechazar
> > correo con eso.
>
> Claro que pueden. Por ejemplo, las cuentas de Gmail. Hay muchos
> mensajes de spam en los que su From o su return-path son de
> "gmail.com" cuando realmente esos datos son falsos. Si Gmail tiene
> configurado spf y el servidor de la lista lo usa, pues todos esos
> correos quedan fuera.
Son dos cosas distintas. Una, que suse defina campos SPF en su DNS, que no
lo ha hecho, lo cual nos impide a nosotros rechazar los falsos usando SPF.
Otra es que SuSE emplee filtros basados en SPF en la entrada, y no lo
hace, ni siquiera emplea listas negras en el postfix (sí en el
spamassassin).
Gmail en cambio sí lo tiene en su DNS, pero no tengo ni idea de si usa
filtros de entrada y cuales.
> > No, no es eso el problema. No se puede usar el campo "from". El return
> > path indica cual es el servidor que se responsabiliza del correo, es la
> > dirección del remite del sobre. El "from" está en el interior, no se puede
> > mirar.
>
> Yo no he hablado del campo From, Carlos. Ese dato también suele ser falseado.
¿Y entonces cual usarías? Porque el identificador del servidor que llega
creo que en EHLO tampoco vale, lo he demostrado arriba.
>
> > Eso sí que lo sabes con SPF. Si recibes un correo de un dominio
> > determinado sabes de que IP tiene que venir, y si viene de otra, lo
> > rechazas. En teoría.
>
> Pues ya es un paso. Es decir, si un servidor de correo me dice que
> efectivamente ese mensaje viene de él, puedo relajar las reglas de
> filtrado para ese correo, por ejemplo. En cambio, un correo tuyo ;-),
> como viene directamente de una ip y sólo tengo ese dato, pues le
> aplico todos los filtros posibles, porque el 90% de los casos suele
> ser un correo de spam.
No te fies mucho, porque te lo puedo envíar a través del relay de tesa, y
to'er mundo mudial sabe que telefonica y terra y sus alias son un nido de
spammers que te cagas. Hasta hay reglas en el SpamAssassin que hablan de
terra...
- --
Saludos
Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFFU0wutTMYHG2NR9URAk9yAJ4wkGXdH3VcUoTkPbduxIXH9itQLACeNc1Q
1mnjECdDVWaQnZeKN1e/RUY=
=E1un
-----END PGP SIGNATURE-----
| < Previous | Next > |