Matt:

That is the conclusion that I have reached ..

Our employees who check messages at home with ISP's blocking SMTP - will
naturally fail this.

Also I am still trying to figure out web responses.

Based on all that I have seen and read it appears a slight negative weight
to reduce FP's is all the use I see for this test... I think a positive test
will only increase our FP rate.

Regards,
Kami

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
Sent: Friday, December 19, 2003 12:14 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] SPF support to be added to next beta

Scott,

I've been looking over this trying to figure out how to best implement it
for my domains.  It seems that since they are all on one class C, I should
do the following:

    v=spf1 +a/24 +mx/24 -all

Now three very important questions...

1) If I implement this, will intra-server E-mail fail this test?  i.e. 
local mail customer at client IP 123.123.123.123 E-mail's me, where
123.123.123.123 is not a local address, but the address of the border router
at the client's location. 

2) When my clients who are SMTP blocked by their ISP (port 25), and forced
to use their ISP's mail server, am I correct in assuming that this will
fail?

3) If the answer is yes to either one of these, does this make more sense to
implement against HELO instead of MAILFROM?  This would seem to be more
problematic than SPAMDOMAINS if it operates on MAILFROM, even if local
domains could be excluded.  Naturally, I might not be understanding this
fully.  If I changed the test to +all in order to prevent these issues (if
real), then it seems that it would only be useful as a negative weight test
when my data is used.

Thanks,

Matt




R. Scott Perry wrote:

> We will be adding support for SPF ("Sender Permitted From", at 
> http://spf.pobox.com ) to the next beta of Declude JunkMail.  This is 
> a system that lets owners of domains publish information on what 
> mailservers people can use to send mail from the domain.  We expect 
> that this can be very useful in blocking spam (similar to the 
> SPAMDOMAINS test), as well as helping ensure that legitimate mail gets 
> through.
>
> http://spf.pobox.com/dns.html covers how to add an SPF record for your 
> own domain.  At its simplest, if all your E-mail is coming from your 
> mailserver, and your mailserver is listed in your MX record, you would 
> add a TXT record of "v=spf1 +mx -all" for your domain.  The SPF 
> records always start with "v=spf1"; the "+mx" means that any E-mail 
> from an IP listed in your MX records is good,  and the "-all" is a 
> default so that any other E-mail is bad.
>
> The SPF system is much, much more flexible than the SPAMDOMAINS test, 
> and it lets domain owners control the settings (which allows them to 
> be much more accurate).  If widely implemented, it will make it much 
> more difficult for spammers to get their spam delivered.
>
>                                                    -Scott



---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To unsubscribe,
just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe
Declude.JunkMail".  The archives can be found at
http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Reply via email to