Re: [Declude.JunkMail] SPF - Missing the Point
ng them can help of course. My opinion remains that SPF, while well intentioned, lacks the ability to be accurate enough to be used reliably in real world circumstances, and it can create more issues than it solves on even properly administrated systems. It totally fails at it's original primary goal of authenticating good E-mail. All of these issues should have been obvious since the very beginning. IMO, this effort should have gone into pushing port 587 functionality and adoption in not just mail servers, but also in mail clients as a default config so that we could move towards blocking port 25 on broadband connections without affecting legitimate use. This would cut down on not just spam, but also the viruses that opened the computers in the first place. Resistance to blocking port 25 is totally a consequence of not having a legitimate alternative. Matt Andy Schmidt wrote: Hi Matt: I read your posting (because you are always insightful), but I'm not sure that your message actually applies to what I had said (and to which Andrew had commented on) or if you may be answering to a different part of the conversation. Certainly nothing Utopian in what I wrote? a) It is plain fact that the largest providers do check SPF, which in turn means that Joe-Jobs have a drastically lower impact on the spoofed domain's owner. b) It is also a fact, that spammers are very SPF aware (to the point that they create SPF records.) c) Based on my personal, admittedly anecdotal, experience (supported by common sense) it further appears to me that SPF protected domains would be less likely to get picked for Joe-Jobs than unprotected domains. Here is what I had written: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? 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, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: Thursday, September 08, 2005 01:55 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPF - Missing the Point But isn't this utopian? The majority of situations have exceptions as they apply to SPF, and in a world where there are open relays on every corner, many servers without proper reverse DNS records, etc., would you really want to trust others to maintain SPF records accurately? I use a custom filter for tagging local domains in incoming E-mail. Since all of my customers' servers are whitelisted, and hosted clients are also whitelisted through AUTH, I can add a couple of points for anything with a Mail From that matches something that I handle. This does have false positives, many in fact due to mailers that forge such as greeting cards or feedback forms, devices that send out notifications with their own SMTP engine, people that are port 25 blocked or proxied, configured to use their own ISP's SMTP server, Web applications, etc. SPF isn't required to do this. I don't trust how well some random admin manages their own SPF records, and if I had my own SPF records, I wouldn't trust how some random admin treated a failure among my own customers. At least they aren't going to be tagged for sending E-mail from someplace that they didn't know not to send from, and is otherwise perfectly acceptable. I am obviously not going to give any credit to anyone for passing SPF either. Passing SPF is a better indication of spam than of legitimate E-mail these days for incoming traffic. I have never been a big fan of SPF because of what I saw as an impractical and unreliable implementation in the real world. It really isn't any better than Habeas once you get down to it, but people ate that up for a while as well. We have many tools available to us these days that are quite effective and much more accurate. Forging spam almost never leaks through my system, and it's not something that I care to focus on at all these days. It's things like Advance Fee Fraud, Phishing, Niche Spam, and First Run Static Spam that concern me. Matt Colbeck, Andrew wrote: That's right on the money, Andy. I agree 100%. Andrew 8) -Or
RE: [Declude.JunkMail] SPF - Missing the Point
Hi Matt: I read your posting (because you are always insightful), but I'm not sure that your message actually applies to what I had said (and to which Andrew had commented on) or if you may be answering to a different part of the conversation. Certainly nothing Utopian in what I wrote? a) It is plain fact that the largest providers do check SPF, which in turn means that Joe-Jobs have a drastically lower impact on the spoofed domain's owner. b) It is also a fact, that spammers are very SPF aware (to the point that they create SPF records.) c) Based on my personal, admittedly anecdotal, experience (supported by common sense) it further appears to me that SPF protected domains would be less likely to get picked for Joe-Jobs than unprotected domains. Here is what I had written: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names?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, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Thursday, September 08, 2005 01:55 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] SPF - Missing the Point But isn't this utopian? The majority of situations have exceptions as they apply to SPF, and in a world where there are open relays on every corner, many servers without proper reverse DNS records, etc., would you really want to trust others to maintain SPF records accurately?I use a custom filter for tagging local domains in incoming E-mail. Since all of my customers' servers are whitelisted, and hosted clients are also whitelisted through AUTH, I can add a couple of points for anything with a Mail From that matches something that I handle. This does have false positives, many in fact due to mailers that forge such as greeting cards or feedback forms, devices that send out notifications with their own SMTP engine, people that are port 25 blocked or proxied, configured to use their own ISP's SMTP server, Web applications, etc. SPF isn't required to do this. I don't trust how well some random admin manages their own SPF records, and if I had my own SPF records, I wouldn't trust how some random admin treated a failure among my own customers. At least they aren't going to be tagged for sending E-mail from someplace that they didn't know not to send from, and is otherwise perfectly acceptable. I am obviously not going to give any credit to anyone for passing SPF either. Passing SPF is a better indication of spam than of legitimate E-mail these days for incoming traffic.I have never been a big fan of SPF because of what I saw as an impractical and unreliable implementation in the real world. It really isn't any better than Habeas once you get down to it, but people ate that up for a while as well. We have many tools available to us these days that are quite effective and much more accurate. Forging spam almost never leaks through my system, and it's not something that I care to focus on at all these days. It's things like Advance Fee Fraud, Phishing, Niche Spam, and First Run Static Spam that concern me.MattColbeck, Andrew wrote: That's right on the money, Andy. I agree 100%. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt Sent: Thursday, September 08, 2005 8:48 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] SPF - Missing the Point 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. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? 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 bomb
Re: [Declude.JunkMail] SPF - Missing the Point
But isn't this utopian? The majority of situations have exceptions as they apply to SPF, and in a world where there are open relays on every corner, many servers without proper reverse DNS records, etc., would you really want to trust others to maintain SPF records accurately? I use a custom filter for tagging local domains in incoming E-mail. Since all of my customers' servers are whitelisted, and hosted clients are also whitelisted through AUTH, I can add a couple of points for anything with a Mail From that matches something that I handle. This does have false positives, many in fact due to mailers that forge such as greeting cards or feedback forms, devices that send out notifications with their own SMTP engine, people that are port 25 blocked or proxied, configured to use their own ISP's SMTP server, Web applications, etc. SPF isn't required to do this. I don't trust how well some random admin manages their own SPF records, and if I had my own SPF records, I wouldn't trust how some random admin treated a failure among my own customers. At least they aren't going to be tagged for sending E-mail from someplace that they didn't know not to send from, and is otherwise perfectly acceptable. I am obviously not going to give any credit to anyone for passing SPF either. Passing SPF is a better indication of spam than of legitimate E-mail these days for incoming traffic. I have never been a big fan of SPF because of what I saw as an impractical and unreliable implementation in the real world. It really isn't any better than Habeas once you get down to it, but people ate that up for a while as well. We have many tools available to us these days that are quite effective and much more accurate. Forging spam almost never leaks through my system, and it's not something that I care to focus on at all these days. It's things like Advance Fee Fraud, Phishing, Niche Spam, and First Run Static Spam that concern me. Matt Colbeck, Andrew wrote: That's right on the money, Andy. I agree 100%. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt Sent: Thursday, September 08, 2005 8:48 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] SPF - Missing the Point 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. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? 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, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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.
Re: [Declude.JunkMail] SPF - Missing the Point
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: 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.
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.
Re: [Declude.JunkMail] SPF - Missing the Point
Excellent point, Andy. Not just detecting spoofing, but changing behavior to avoid future spoofing. Darin. - Original Message - From: "Andy Schmidt" <[EMAIL PROTECTED]> To: Sent: Thursday, September 08, 2005 11:47 AM Subject: RE: [Declude.JunkMail] SPF - Missing the Point >> 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. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? 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, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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.
RE: [Declude.JunkMail] SPF - Missing the Point
That's right on the money, Andy. I agree 100%. Andrew 8) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt > Sent: Thursday, September 08, 2005 8:48 AM > To: Declude.JunkMail@declude.com > Subject: RE: [Declude.JunkMail] SPF - Missing the Point > > >> 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. > > However, that ignores what SPF is designed to do: > > How many times have we received angry emails or hundreds of > bounce messages from other ISPs because some Spammer was > sending mail with a fake email sender - using OUR domain names? > > 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, because they know > that a lot of their spam would never reach anyone. Instead, > they now use their own domain names and even set up SPF for > those. To me - that ripple effect alone justifies SPF! > > Thus, without question, SPF should be in place for all > domains you control. > Specially for alias/vanity/web-only domains that never send any email. > Ideally, in addition, set up SMTP AUTH for your clients so > that you can use SPFFAIL for incoming mail and, if you > choose, ignore SPFPASS for now. > > Best Regards > Andy Schmidt > > Phone: +1 201 934-3414 x20 (Business) > Fax:+1 201 934-9206 > > --- > 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.
RE: [Declude.JunkMail] SPF - Missing the Point
>> 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. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? 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, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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.
