On 11:47 AM 9/8/2005 -0400, it would appear that Andy Schmidt wrote:
>> still unacceptable and reason enough for me to discard SPF completely. <<
I think the discusson is missing the key point of SPF. Sure, this list is
focused on INCOMING spam, and thus we restricting our discussions to
SPFFAIL/SPFPASS and how to use it in Declude..
[snip]
If you define SPF for your own (and client) domain names, then the largest
ISPs won't accept the spam that has your email address faked, thus you and
your clients will no longer be bombarded with responses/complaints/bounces
to messages you never sent in the first place.
The effect of having SPF defined is, that FEWER spammers even bother trying
to abuse YOUR domain name.
No, the effect is that if I define SPF (which I don't and won't as I'll
explain) then I am forced to either write includes for Netzero, Xmission,
Connect2 and every other ISP that my users (employees) use at home where
they also write emails that legitimately use @cvwrf.org. If I use SPF and
*don't* write those includes then I am forcing a FAIL when those users send
mail through their home ISP using @cvwrf.org. If, however, I don't have
any SPF record (which I don't) then at worst an SPF test is required to
return a NONE/NEUTRAL. Some ISPs do reject on FAIL but I have yet to find
one that rejects on a NONE/NEUTRAL because the RFC specifies that
NONE/NEUTRAL should not be rejected out of hand. For example, SPFFAIL is
*not* triggered if a domain has no SPF record.
From the Junkmail manual:
Note that it will not be triggered for E-mail that has other problems (no
SPF record, unknown results from the SPF record, etc.). So any E-mail
failing the SPFFAIL test is E-mail that is not authorized per the
administrator of the domain the E-mail is being sent from.
In short, I better ensure my that my users can send mail regardless of
their location by not having any SPF record. That also means that I do no
SPF checks on incoming mail, in my view it is simply too
unreliable. Besides, my other Declude tests are already catching 97% of
the SPAM we receive with only 0.03% of those messages caught being false
positives.
As to using port 587 as you suggested early Andy, we may do that eventually
but currently 587 usage is still not widespread enough on the client
side. Sure, I can *make* 587 work for nearly any client out there but that
will break port 25 usage on many of those clients. Example: Any Eudora
client older than 17 June 2005 can use *either* port 25 or port 587 for
sending. Besides, I *really* don't want to make 73 house calls to get my
users over to port 587. ;)
Tyran Ormond
Programmer/LAN Administrator
Central Valley Water Reclamation Facility
[EMAIL PROTECTED]
---
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.
