Well, it's entirely up to you: Tell your users to send out through your server instead of their ISP(over port 587 if the ISP is blocking 25) or use the SPF neutral response instead of pass or fail.
Yes, it requires a little work, but for us it has proven useful. I don't think anyone is saying it's perfect, but it can be implemented in a useful fashion. Darin. ----- Original Message ----- From: "Tyran Ormond" <[EMAIL PROTECTED]> To: <Declude.JunkMail@declude.com> Sent: Thursday, September 08, 2005 12:39 PM Subject: RE: [Declude.JunkMail] SPF - Missing the Point 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. --- 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.
