[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DNS y registro SPF en debian 6



On Tue, 14 May 2013 17:38:15 +0000 (UTC), Camaleón wrote:
El Tue, 14 May 2013 13:09:50 -0400, luis escribió:

Hola a todos, una duda y no se cual variante seleccionar, ,la mejor, la
que se más seguridad en los correos para evitar el span.

¿Aún no te funciona el servidor de correo y ya estás pensando en SPF?
Caray :-O

Y por cierto, los registros SPF no sirven exclusivamente para evitar el spam sino más bien para comprobar que el remitente es quien dice ser y eso no tiene por qué ser considerado "necesariamente" spam. Para luchar
contra el spam mejor usa un filtro como SpamAssassin o listas grises.

Para mi la 2 pero quisiera la opinión de ustedes y que me recomiendan.

variante 1.
---------------------------------
v=spf1 a mx ip4:200.55.141.3 ~all

---> si autoriza explicitamente el envio de mail desde servidores no no
declarados en el servicio SPF


Variante 2
---------------------------------
v=spf1 a mx ip4:200.55.141.3 -all

---> no autoriza explicitamente el envio de mail desde servidores no no
declarados en el servicio SPF


alguien puede alcararme ??

Wikipedia explica los calificadores:

***
Qualifiers

Each mechanism can be combined with one of four qualifiers:

+ for a PASS result. This can be omitted; e.g., +mx is the same as mx.
? for a NEUTRAL result interpreted like NONE (no policy).
~ (tilde) for SOFTFAIL, a debugging aid between NEUTRAL and FAIL.
Typically, messages that return a SOFTFAIL are accepted but tagged.
- (minus) for FAIL, the mail should be rejected (see below).

(...)

Interpretation

SPF FAIL policies can be an effective but problematic tool. A typical
example is a user that wishes to send an email from a private PC or a
mobile phone: the user uses his corporate email address but may use a
different outgoing SMTP server which is not listed in the SPF record. The corporate domain may therefore be secure by blocking all email that does not originate from themselves, but have thereby limited some of their own users. Many organizations consider this compromise acceptable and even
desirable.

SPF PASS is useful for authenticating the domain for use as a parameter
to a spam classification engine. That is, the domain in the sender
address can be considered to be authentic if the originating IP yields an SPF PASS. The domain can then be referenced against a reputation database.

SPF results other than PASS (used in combination with a reputation
system) and FAIL cannot be meaningfully mapped to PASS and FAIL. However, a reputation system can easily track independent reputations for each SPF
result, i.e. example.com:PASS and example.com:NEUTRAL would have
different reputations, and ditto for the other results. This approach is useful even without whitelisting plain forwarders, since the FAIL results
from the plain forwarders simply accrue an independent reputation.

The meaning of PASS, SOFTFAIL, FAIL is sometimes incorrectly interpreted to mean "not-spam", "maybe-spam", "spam" respectively. However SPF does nothing of the sort. SPF merely offers an organization firstly the means to classify emails based on their domain name instead of their IP address (SPF PASS); and secondly, the means to block unauthorized use of their
domain (SPF FAIL).
***

Yo empezaría con el más suave "~" mientras haces las pruebas.

Saludos,

--
Camaleón

hola Camaleón, tienes razón pero todos los días hay que aprnder más y mejorar más.

Cierto el tema del servidor de correo mmm si tengo varias dudas pero eso un poco más adelante estoy algo complicado y corto de tiempo, espero contar con tu atuda y los de la lista.

Se de tus respuestas pero admiro y considro a todo el que sabe y lo respeto siempre, así debe ser

Saludos y gracias a todos


Reply to: