EOT (was: Re: Off Topic - SPF - What a Disaster)
Do you guys even read the thread you're contributing to? This thread has passed its expiration date long ago. Stop beating a dead horse. One last time: End. Of. Thread. I'll personally chastise any offenders, and reserve the right to turn on moderation or unsubscribe. You want the police when there's someone bouncing mail. Accept the police. This is not Spam-L. -- char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Off Topic - SPF - What a Disaster
On Sat 27 Feb 2010 06:13:58 PM CET, Marc Perkel wrote You're making the assumption that the person who has the recipient domain has any control over the SPF rules. What often happens is that one domain is on a server with 1000 other domains and the hosting compant controls the rules. such life i dont have So if you say forward your old comcast account to your new domain then the new domain rejects all your good comcast email because of SPF. then recipient domain MUST whitelist the forward IP to make sure SPF still works, no matter what domain is being forwarded from that IP will not being spf fail then, or if thats impossible add the forward ip to the sender domain spf record Or if you use my spam filtering service or Postini or some other filter and forward service then restrictive SPF breaks that to. i dont need it :) -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Off Topic - SPF - What a Disaster
At 06:02 AM 2/27/2010, you wrote: Benny Pedersen writes: > On Thu 25 Feb 2010 10:31:16 PM CET, Kai Schaetzl wrote >> I don't know to what you disagree, but SPF is not an anti-spam tool. Full >> stop. > > oh so what is spf then ? It is an anti-forgery tool. SPF as defined in RFC 4408, is an email validation system designed to prevent e-mail spam by addressing a common vulnerability, source address spoofing. Quoted from the RFC: " The current E-Mail infrastructure has the property that any host injecting mail into the mail system can identify itself as any domain name it wants. Hosts can do this at a variety of levels: in particular, the session, the envelope, and the mail headers. Although this feature is desirable in some circumstances, it is a major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam)." I think this argument is now over. Best Regards, Jeff Koch, Intersessions
EOT (was: Re: Off Topic - SPF - What a Disaster)
Was my reply 3 hours ago to the very same post that hard to understand? Take it somewhere else. End of Thread. -- char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Off Topic - SPF - What a Disaster
Benny Pedersen wrote: On Sat 27 Feb 2010 12:15:58 PM CET, Marc Perkel wrote but you constantly refuse to use SPF the same way... Yep - fcrdns doesn't break email forwarding. spf works as designed, but it does not help domain owners to make the right spf record on dns to support forwarding if that is wanted one more point is that a recipient domain should properly know where mails that is spf protected where its forwarded from (ip), forwared host dont change ip wake up Marc ! You're making the assumption that the person who has the recipient domain has any control over the SPF rules. What often happens is that one domain is on a server with 1000 other domains and the hosting compant controls the rules. So if you say forward your old comcast account to your new domain then the new domain rejects all your good comcast email because of SPF. Or if you use my spam filtering service or Postini or some other filter and forward service then restrictive SPF breaks that to.
EOT (was: Re: Off Topic - SPF - What a Disaster)
End of Thread. -- char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Off Topic - SPF - What a Disaster
On Sat 27 Feb 2010 12:02:15 PM CET, Graham Murray wrote Benny Pedersen writes: On Thu 25 Feb 2010 10:31:16 PM CET, Kai Schaetzl wrote I don't know to what you disagree, but SPF is not an anti-spam tool. Full stop. oh so what is spf then ? It is an anti-forgery tool. so i can safely remove my own spf record and dont check for forged senders, it will not make any sense in the amount of spam i get ?, but i keep it, its more simple to be clueless :) -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Off Topic - SPF - What a Disaster
On Sat 27 Feb 2010 12:15:58 PM CET, Marc Perkel wrote but you constantly refuse to use SPF the same way... Yep - fcrdns doesn't break email forwarding. spf works as designed, but it does not help domain owners to make the right spf record on dns to support forwarding if that is wanted one more point is that a recipient domain should properly know where mails that is spf protected where its forwarded from (ip), forwared host dont change ip wake up Marc ! -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Off Topic - SPF - What a Disaster
Benny Pedersen writes: > On Thu 25 Feb 2010 10:31:16 PM CET, Kai Schaetzl wrote >> I don't know to what you disagree, but SPF is not an anti-spam tool. Full >> stop. > > oh so what is spf then ? It is an anti-forgery tool.
Re: Off Topic - SPF - What a Disaster
Matus UHLAR - fantomas wrote: On 25.02.10 15:22, Marc Perkel wrote: I'd like to find a way to get people to get their FCrDNS correct. The way I see it if they can't get RDNS correct they aren't going to get SPF correct. Unfortunately I get a lot of ham from IPs with no RDNS. Matus UHLAR - fantomas wrote: fcrdns can't be used to filter spam because many spammers use ir properly. On 26.02.10 09:52, Marc Perkel wrote: I use FCRDNS mostly for whitelisting. If FCRDNS is good and it is listed in my lists of 14k host names then it sails through without checking. but you constantly refuse to use SPF the same way... Yep - fcrdns doesn't break email forwarding.
Re: Off Topic - SPF - What a Disaster
>> On 25.02.10 15:22, Marc Perkel wrote: >>> I'd like to find a way to get people to get their FCrDNS correct. The >>> way I see it if they can't get RDNS correct they aren't going to get >>> SPF correct. Unfortunately I get a lot of ham from IPs with no RDNS. > Matus UHLAR - fantomas wrote: >> fcrdns can't be used to filter spam because many spammers use ir properly. On 26.02.10 09:52, Marc Perkel wrote: > I use FCRDNS mostly for whitelisting. If FCRDNS is good and it is listed > in my lists of 14k host names then it sails through without checking. but you constantly refuse to use SPF the same way... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
Re: Off Topic - SPF - What a Disaster
On Thu 25 Feb 2010 10:31:16 PM CET, Kai Schaetzl wrote I don't know to what you disagree, but SPF is not an anti-spam tool. Full stop. oh so what is spf then ? -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Off Topic - SPF - What a Disaster
On Fri, 26 Feb 2010, Benny Pedersen wrote: On Fri 26 Feb 2010 06:50:12 PM CET, Marc Perkel wrote And - SPF was originally introduced as a spam fighting solution. alot of lies out there Okay, this is getting stupid. Everyone on this thread, go to: http://www.openspf.org/Introduction Spammers are explicitly identified as one of the problems addressed. And even if this were somehow a 'lie', the original intent of the authors does not change whether SPF is *effective* for a given role. So this petulant arguing over its purpose is. (ad hominems snipped). Take it off list, PLEASE. - C
Re: Off Topic - SPF - What a Disaster
On 26-Feb-10 11:24, Marc Perkel wrote: Jason Bertoch wrote: SPF wasn't meant to block spam, please stop asserting that. http://old.openspf.org/howworks.html Quoting the page: And as a user, SPF can help you sort the good from the bad. Reject mail that fails an SPF check. And? that's what I use it for. that's what it's good for. I reject mail that claims to be from paypal that fails SPF. (well, I score it high enough that it amounts to the same thing). You know, my car is very useful for getting groceries. The car was not designed with the intent of getting groceries, and no number of trips to the grocery store in a car will ever change that fact. Even though my car's *primary* use is hauling groceries, it is still not a 'grocery hauler device'. -- The real American folksong is a rag -- a mental jag A rhythmic tone for the chronic blues
Re: Off Topic - SPF - What a Disaster
Jason Bertoch wrote: Every modern mail solution allows an account holder to pop/imap to another account to pull in mail from somewhere else. But this introduces a security hole, where the password to an account on System A is stored on System B. Forwarding avoids that. Joseph Brennan Columbia University Information Technology
Re: Off Topic - SPF - What a Disaster
On Fri 26 Feb 2010 06:50:12 PM CET, Marc Perkel wrote And - SPF was originally introduced as a spam fighting solution. But they backed off when it was clear that it didn't fight spam. alot of lies out there -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Off Topic - SPF - What a Disaster
Jason Bertoch wrote: SPF wasn't meant to block spam, please stop asserting that. http://old.openspf.org/howworks.html Quoting the page: And as a user, SPF can help you sort the good from the bad. Reject mail that fails an SPF check.
Re: Off Topic - SPF - What a Disaster
Matus UHLAR - fantomas wrote: LuKreme wrote: Here's where spf is useful. On 25.02.10 15:31, Marc Perkel wrote: Except that it breaks forwarded email. Matus UHLAR - fantomas wrote: I have never seen any occurence of SPF breaking forwarding. On 26.02.10 09:46, Per Jessen wrote: Really? Do you know which problem SRS was meant to address then? If SPF doesn't break forwarding, surely we have no need for SRS. I have explained it many times, even in the mail you quote. I don't see reason to repeat that to people who can't / don't want to understand. The funniest anti-SPF anti-SRS argument at http://david.woodhou.se/why-not-spf.html was the "alternative" SES which was inspired by SRS. You can keep repeating it be you are still dead wrong. The SPF people don't get it. You act line using the original sender is prohibited and SRS is normal. That's your parallel universe. In the real world using the orinial sender is norman and SRS is mangling.
Re: Off Topic - SPF - What a Disaster
Matus UHLAR - fantomas wrote: On 25.02.10 15:22, Marc Perkel wrote: I'd like to find a way to get people to get their FCrDNS correct. The way I see it if they can't get RDNS correct they aren't going to get SPF correct. Unfortunately I get a lot of ham from IPs with no RDNS. fcrdns can't be used to filter spam because many spammers use ir properly. I use FCRDNS mostly for whitelisting. If FCRDNS is good and it is listed in my lists of 14k host names then it sails through without checking.
Re: Off Topic - SPF - What a Disaster
Jason Bertoch wrote: On 2/25/2010 8:08 PM, Marc Perkel wrote: The forward issue is definitely an annoyance. But SPF has a problem in that as the supporters admit, it doesn't block spam, and it can't be used as a white rule because spammers often use SPF correctly. I'm not sure what you mean that forwarding has been depricated. Lots of people forward email for a lot of different reasons. I don't understand what you mean. SPF wasn't meant to block spam, please stop asserting that. It may prove useful as part of an overall spam fighting solution, but that's not the point of the original design. Just as FCrDNS has proven to be a useful tool in spam fighting, it was never intended to be used that way either. Off-site forwarding has been deprecated, mostly due to spam fighting methods, but for many other good reasons too. Every modern mail solution allows an account holder to pop/imap to another account to pull in mail from somewhere else. Forwarding only assists the lazy and breaks spam filtering. If there wasn't another option, sure, off-site forwarding would still be needed/wanted/required. That's just not the case anymore, and fighting it causes greater loss of service than adopting it. Spam filtering is simply more important than handling the exception cases where someone refuses to pull in mail from somewhere else. I understand this doesn't match the design of your service, but that doesn't make SPF wrong for the reasons you state. Off-site forwarding is old technology and old thinking. Solutions exist to fix your problem, as I stated previously. SPF may break forwarding, but forwarding breaks spam filtering...and what's more important when there's already a plethora of solutions to deal with forwarding? /out So why would I want to break email forwarding for SPF? Then there's the reality disconnect. You said: "SPF *wasn't meant to block spam*, please stop asserting that. It may prove useful as part of an overall *spam fighting solution*, but that's not the point of the original design." Seems like a contradiction. And - SPF was originally introduced as a spam fighting solution. But they backed off when it was clear that it didn't fight spam.
Re: Off Topic - SPF - What a Disaster
On 25-Feb-2010, at 17:48, Lee Dilkie wrote: One of the problems is that in SA, an SPF_FAIL (hard) doesn't score much above a SPF_SOFTFAIL but in my view it should. If an admin has made the effort to setup a hardfail record, it should be trusted. There are far too many incompetent admins to trust them to the detriment of user's real, valid emails. SA's scores are based on real world testing, but you are free to set hard fail scores however you want. -- HIGH EXPLOSIVES AND SCHOOL DON'T MIX Bart chalkboard Ep. 8F03
Re: Off Topic - SPF - What a Disaster
On 26/02/2010 14:20, LuKreme wrote: On 26-Feb-2010, at 07:13, LuKreme wrote: SPF_PASS 0.001 SPF_fail 5.0 whitelist_from_spf *...@ebay.com whitelist_from_spf *...@paypal.com You forgot "whitelist_from_spf *...@*.apache.org" -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Off Topic - SPF - What a Disaster
On 26-Feb-2010, at 07:13, LuKreme wrote: SPF_PASS 0.001 SPF_fail 5.0 whitelist_from_spf *...@ebay.com whitelist_from_spf *...@paypal.com -- I WILL NOT AIM FOR THE HEAD Bart chalkboard Ep. 8F13
Re: Off Topic - SPF - What a Disaster
On 25-Feb-2010, at 18:08, Marc Perkel wrote: it doesn't block spam, But as I said the absence of SPF can be used to block the most harmful and risky of spams. and it can't be used as a white rule because spammers often use SPF correctly. It can't be used INDISCRIMINATELY as a whitelist. One cannot say, "hey, this random message from someone I never heard of passes SPF, it must be OK." One CAN say "hey, this email from {bob, mom, the bank, ebay, paypal, dell, microsoft} passes SPF, it must be ok." In SA terms SPF_PASS 0.001 SPF_fail 5.0 -- (...) IT IS NOT YET MIDNIGHT? 'I shouldn't think it's more than a quarter past eleven.' THEN WE HAVE THREE-QUARTERS OF AN HOUR 'How can you be sure?' BECAUSE OF DRAMA, MISS FLITWORTH.. THE KIND OF DEATH WHO POSES AGAINST THE SKYLINE AND GETS LIT UP BY LIGHTNING FLASHES, said Bill Door, disapprovingly, DOESN'T TURN UP AT FIVE-AND-TWENTY PAST ELEVEN IF HE CAN POSSIBLY TURN UP AT MIDNIGHT. --Reaper Man
RE: Off Topic - SPF - What a Disaster
Original Message From: Marc Perkel [mailto:m...@perkel.com] Sent: Thursday, February 25, 2010 6:11 PM To: Rick Cooper Cc: 'ram'; users@spamassassin.apache.org Subject: Re: Off Topic - SPF - What a Disaster > Rick Cooper wrote: >> >> >>> The anti-SPF bandwagon is not ego driven but results driven. Than >> you >>> for admitting that SPF in not a spam filtering solution. >> However it >>> is also not a white listing solution because as many >> people have said >>> here - spammers are the ones who are using SPF >> correctly. I can see >>> some theoretical benefits that if you have a >> list of banks with SPF >>> and you receive an email from an address >> that the bank lists then you >>> can safely pass it. But I find that an >> easier way to do that is to >>> use FCrDNS to do the same thing. >> >> >>> On the down site SPF breaks email forwarding and it creates a false >> >>> sense that people are doing something to fight spam or protect ham >> >>> that is not supported by reality. SPF has received intellectual >> >>> welfare because stuff that doesn't work tends to be culled out of >> >>> spam assassin and other than backscatter most people here are >> telling >>> the SPF supporters that it doesn't work. If SPF is becoming >> more >>> popular it just means that more people are misled. >> >> So then SRS Doesn't work for forwarding systems? I ask because I am >> not a forwarding service and, as I only handle corporate mail >> systems, do not give access to arbitrary forwarding to the mail >> users so we do not have tons of (external) forwarding going on. Since >> SPF and SRS are like legs on the same body I will assume trying to walk >> with >> one leg produces results similar to a forwarding service using SPF >> without SRS. I personally would love comcast would list all of their >> Valid outbound mail hosts and hard fail all others, same with aol, >> yahoo, gmail, etc. Seems to me if you are going to push email all over >> hell's half acre it behooves you To use any and all tools available to >> take responsibility for those mails and SPF is One of several tools that >> can do that, at least to some extent. If there would have been Some kind >> of total commitment to spam 10 years ago we would not be where we are >> today and Spamassassin (as it is) would not be quite so necessary. >> >> (My apologies for the pathetic attempt at manually reformatting >> the original html post) >> >> > > SRS is even more broken than SPF. I allow users to white list or black > list based on the sender. If you rewrite the sender then you lose sender > based conditionals. SRS has no use other than to try to fix SPF which > has no use in the first place. I suppose you would have to add logic to your whitlisting to accommodate an SRS message, it's not like you cannot tell and the return path remains intact so the original sending address is still available for the white list. Pobox.com uses it (of course) and the are a forwarding service. I don't personally see SPF as a spam tool so much as someone taking responsibility for the mail they send. I suppose since all forwarding services are legitimate the world should just take messages originating from them as legitimate as well My bad Rick -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Off Topic - SPF - What a Disaster
On 25/02/2010 23:31, Marc Perkel wrote: As someone who forwards email what I see is this. Sender has restrictive SPF. Recipient server enforces SPF. Mail coming through me bounces. Then they call me to complain and I say, I didn't bounce it. Get rid of your SPF nd your email will be received. In your scenario, there are two broken systems. Neither of which are SPF. The first broken system is your user. They've applied SPF to their domain. They've set up mail forwarding from your service. Yet they still apply SPF checking against your servers? That is stupid. They've misconfigured their mail service. They should either remove SPF, get rid of the forwarding, or change the forwarding provider to one which rewrites the envelope sender. The second broken system is your forwarding system. It's is forging the envelope sender instead of correctly rewriting it. Fix that, or continue to offer a sub-standard forwarding service. Your choice. It's not SPF's fault that your clueless user can't receive some email. It's a combination of your broken forwarding configuration, and your clueless users misconfiguration of their email. It's too late anyway. Your opinion is no longer relevant. SPF is absolutely here to stay. It is supported by *many* large providers, and a large proporition of ham is already using SPF. Ideally, 100% of Ham and 100% of Spam would use SPF. You don't seem to get this though. You think SPF is only useful if 100% of Ham uses it and 0% of Spam uses it. That's a flaw in your understanding of what it's there for. If a Spam comes from "example.com" and it's SPF protected, then you know the domain hasn't been forged, and it's safe to blacklist it. If it *isn't* SPF protected, then for all you know it has been forged and blacklisting it might cause collateral damage. The positive aspects of *any* mail being "signed" with SPF, ham *or* spam, are so damn obvious, I don't know how you manage to mis-represent them so blatantly and so poorly. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Off Topic - SPF - What a Disaster
> >> LuKreme wrote: > >>> Here's where spf is useful. > > > > On 25.02.10 15:31, Marc Perkel wrote: > >> Except that it breaks forwarded email. > Matus UHLAR - fantomas wrote: > > I have never seen any occurence of SPF breaking forwarding. On 26.02.10 09:46, Per Jessen wrote: > Really? Do you know which problem SRS was meant to address then? If > SPF doesn't break forwarding, surely we have no need for SRS. I have explained it many times, even in the mail you quote. I don't see reason to repeat that to people who can't / don't want to understand. The funniest anti-SPF anti-SRS argument at http://david.woodhou.se/why-not-spf.html was the "alternative" SES which was inspired by SRS. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. If Barbie is so popular, why do you have to buy her friends?
Re: Off Topic - SPF - What a Disaster
Matus UHLAR - fantomas wrote: >> LuKreme wrote: >>> Here's where spf is useful. > > On 25.02.10 15:31, Marc Perkel wrote: >> Except that it breaks forwarded email. > > I have never seen any occurence of SPF breaking forwarding. Really? Do you know which problem SRS was meant to address then? If SPF doesn't break forwarding, surely we have no need for SRS. /Per Jessen, Zürich
Re: Off Topic - SPF - What a Disaster
> LuKreme wrote: >> Here's where spf is useful. On 25.02.10 15:31, Marc Perkel wrote: > Except that it breaks forwarded email. I have never seen any occurence of SPF breaking forwarding. But if you forward e-mail from someone and you are pretending to be him, we may reject it because you are forging. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I intend to live forever - so far so good.
Re: Off Topic - SPF - What a Disaster
On 25.02.10 17:08, Marc Perkel wrote: > The forward issue is definitely an annoyance. But SPF has a problem in > that as the supporters admit, it doesn't block spam, and it can't be > used as a white rule because spammers often use SPF correctly. Marc, why are YOU trolling? Are you attempting to say that whitelisting on IPs can't be used because spammers use IPs correctly? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I drive way too fast to worry about cholesterol.
Re: Off Topic - SPF - What a Disaster
On 25.02.10 15:22, Marc Perkel wrote: > I'd like to find a way to get people to get their FCrDNS correct. The > way I see it if they can't get RDNS correct they aren't going to get SPF > correct. Unfortunately I get a lot of ham from IPs with no RDNS. fcrdns can't be used to filter spam because many spammers use ir properly. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The early bird may get the worm, but the second mouse gets the cheese.
Re: Off Topic - SPF - What a Disaster
Marc, > > > > Which fails when you have someone that has multiple domains that may be > > sending mail "from" the same organization. Mail to me from Citi may comes > > from any one of at least 6 different domains, and the mailserver is not > > necessarily in the same domain. > > > Whitelist all 6 domains. > > What if Citi starts using mail services from another provider with a different ptr. Do you expect them to announce that on this mailing list ? Conversely what if City stops services from one and then a phisher/spammer buys of the server space. Thanks to the stupid whitelist I will be sending all these spams whitelisted until we have angry calls on the customer support helpdesk. This is useless for me to keep tracking what servers Citi ,Bank of America, or ICICIBank uses. I put just 1 line in my ".cf" file and forget about it. Because their SPF record already keeps track. Even the largest banks today are outsourcing their email. FcRDNS works only if the organization runs their own mailing and dont keep changing their mailhost names. Thanks Ram
Re: Off Topic - SPF - What a Disaster
On Thu, 25 Feb 2010, Marc Perkel wrote: Jason Bertoch wrote: On 2/25/2010 6:37 PM, Marc Perkel wrote: > > A lot of posts with useless rants on a personal grievance against > SPF ... Marc, I suspect you're not seeing a bunch of supporters of SPF post on this thread because most find it tiresome, bothersome, pointless, or all of the above. ... /out The forward issue is definitely an annoyance. But SPF has a problem in that as the supporters admit, it doesn't block spam, ... Followups-To: alt.advocacy.spf.headdesk.headdesk.headdesk.headdesk.headdesk -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- W-w-w-w-w-where did he learn to n-n-negotiate like that? --- 139 days since President Obama won the Nobel "Not George W. Bush" prize
Re: Off Topic - SPF - What a Disaster
On 2/25/2010 8:08 PM, Marc Perkel wrote: The forward issue is definitely an annoyance. But SPF has a problem in that as the supporters admit, it doesn't block spam, and it can't be used as a white rule because spammers often use SPF correctly. I'm not sure what you mean that forwarding has been depricated. Lots of people forward email for a lot of different reasons. I don't understand what you mean. SPF wasn't meant to block spam, please stop asserting that. It may prove useful as part of an overall spam fighting solution, but that's not the point of the original design. Just as FCrDNS has proven to be a useful tool in spam fighting, it was never intended to be used that way either. Off-site forwarding has been deprecated, mostly due to spam fighting methods, but for many other good reasons too. Every modern mail solution allows an account holder to pop/imap to another account to pull in mail from somewhere else. Forwarding only assists the lazy and breaks spam filtering. If there wasn't another option, sure, off-site forwarding would still be needed/wanted/required. That's just not the case anymore, and fighting it causes greater loss of service than adopting it. Spam filtering is simply more important than handling the exception cases where someone refuses to pull in mail from somewhere else. I understand this doesn't match the design of your service, but that doesn't make SPF wrong for the reasons you state. Off-site forwarding is old technology and old thinking. Solutions exist to fix your problem, as I stated previously. SPF may break forwarding, but forwarding breaks spam filtering...and what's more important when there's already a plethora of solutions to deal with forwarding? /out
Re: Off Topic - SPF - What a Disaster
Jason Bertoch wrote: On 2/25/2010 6:37 PM, Marc Perkel wrote: A lot of posts with useless rants on a personal grievance against SPF Marc, I suspect you're not seeing a bunch of supporters of SPF post on this thread because most find it tiresome, bothersome, pointless, or all of the above. I bit my lip until now for all of those reasons, but can't stand your continual whining. You're clearly only mad at SPF because of the forwarding issue. As has been stated in a multitude of threads over the years, including this one, SPF has its place for those that use it in the way it was intended. Although, I agree that FCrDNS is very useful, I'm also aware that it's just another tool in the box. For some unfortunate reason, many providers don't allow changes to PTR records to accommodate their customers. SPF provides an alternate means by which domain owners can publish useful mail source information on their own, regardless of provider cooperation/competence. Forwarding off-site has essentially been deprecated since spam filtering began and the wide-spread availability of mail submission ports/relaying via authentication. SPF isn't your problem, it's your ego. If you proxy your connections, like the rest of your [much] bigger competitors do, the forwarding issue goes away. Or, if you don't feel like coding, ask your customers to use the SPF include directive where you can publish additional allowable servers. SPF simply isn't the problem, please stop whining. /out The forward issue is definitely an annoyance. But SPF has a problem in that as the supporters admit, it doesn't block spam, and it can't be used as a white rule because spammers often use SPF correctly. I'm not sure what you mean that forwarding has been depricated. Lots of people forward email for a lot of different reasons. I don't understand what you mean.
Re: Off Topic - SPF - What a Disaster
On 2/25/2010 6:37 PM, Marc Perkel wrote: A lot of posts with useless rants on a personal grievance against SPF Marc, I suspect you're not seeing a bunch of supporters of SPF post on this thread because most find it tiresome, bothersome, pointless, or all of the above. I bit my lip until now for all of those reasons, but can't stand your continual whining. You're clearly only mad at SPF because of the forwarding issue. As has been stated in a multitude of threads over the years, including this one, SPF has its place for those that use it in the way it was intended. Although, I agree that FCrDNS is very useful, I'm also aware that it's just another tool in the box. For some unfortunate reason, many providers don't allow changes to PTR records to accommodate their customers. SPF provides an alternate means by which domain owners can publish useful mail source information on their own, regardless of provider cooperation/competence. Forwarding off-site has essentially been deprecated since spam filtering began and the wide-spread availability of mail submission ports/relaying via authentication. SPF isn't your problem, it's your ego. If you proxy your connections, like the rest of your [much] bigger competitors do, the forwarding issue goes away. Or, if you don't feel like coding, ask your customers to use the SPF include directive where you can publish additional allowable servers. SPF simply isn't the problem, please stop whining. /out
Re: Off Topic - SPF - What a Disaster
Marc Perkel wrote: > I'm not hearing from people in this forum who are saying it works. > Even those who are SPF evangelists can't point to any significant > results in either blocking spam or passing ham. > Well it's no magic bullet, but nothing is. I use SPF to try and make my domain less a target for spammers to forge. I got hit with a massive backscatter flood last week that killed my service and I changed my SPF records to "hardfail" and had to notify my (few) clients to let them know that they were now required to use my server for outgoing mail (auth on port 587). Only time will tell if helps. But I immediately saw the effect in the bounce messages, domains like gmail were aware of the hardfail on their spf check. One of the problems is that in SA, an SPF_FAIL (hard) doesn't score much above a SPF_SOFTFAIL but in my view it should. If an admin has made the effort to setup a hardfail record, it should be trusted. SPF_PASS shouldn't be trusted as far as spam processing, as we all know, as spammers can setup valid SPF records. But it does help against spambot's, doesn't it? It's hard to setup valid SPF records when you're sending spam from a million infected machines. -lee
Re: Off Topic - SPF - What a Disaster
On Thu, 2010-02-25 at 15:19 -0800, Marc Perkel wrote: > SPF will never be 99% adopted until it actually does something that is > significantly useful. Using it as a white list to bypass a grey list > isn't what I would call significantly useful. SPF fails the "actually > works" test. > But it DOES do something useful. It reduces backscatter from spam that uses your domain as the forged sender. And it does so without costing you more cycles than a DNS lookup uses. That's it. I've said my say. I'm out of this unnecessary pissing match after saying to the OP who gratuitously started it: "May the fleas from a thousand camels infest your armpits". Martin
Re: Off Topic - SPF - What a Disaster
Kai Schaetzl wrote: Jeff Koch wrote on Thu, 25 Feb 2010 15:08:46 -0500: I disagree. I don't know to what you disagree, but SPF is not an anti-spam tool. Full stop. Kai You say that here but in your last message you said: " If SPF was adapted 99% (and always strict with no allowance of not-listed servers), then you could also do blacklisting based on this." You can't have it both ways. Which is another problem I have with SPF evangelists is that they say (now) that isn't not for blocking spam. But yet people are encouraged to use it to block spam. Everything else proposed here has to pass the reality test. It has to actually work. But for SPF we are lowering the bar for some reason. I don't see why SA has any SPF if it doesn't do anything.
Re: Off Topic - SPF - What a Disaster
LuKreme wrote: On 25-Feb-2010, at 10:29, Marc Perkel wrote: The anti-SPF bandwagon is not ego driven but results driven. Than you for admitting that SPF in not a spam filtering solution. However it is also not a white listing solution because as many people have said here - spammers are the ones who are using SPF correctly. If you blindly accept any email with a valid spf as being 'good' email then your not understanding the system. Here's where spf is useful. You have an emailer (a bank, a company, aol, hotmail, whatever) that is a frequent target of spoofing. You can either spend a lot of time and resources trying to catch the spoof emails while not trashing the real ones, or you can enable spf. Except that it breaks forwarded email. So, if an email comes in to my mailspool from paypal.com and it passes spf, it is treated as a normal message. It still goes through SA. But if it comes in "from" paypal.com and DOESN'T pass spf, it instantly gets 5 points added to it because if it's claiming to be from paypal AND it fails SPF, it is *not* from paypal. If the host isn't a paypal server or it hasn't passed a paypal server then it's bounced. All paypal email comes from *.paypal.com servers. So, while SPF is *not* an anti-spam tool, in the case of paypal, and ebay, and citibank (but not the mentally challenged lemurs at bankofamerica) the *lack* of SPF become an anti-spam tool (more often a anti-phishing tool, really). How any mailadmin can think this is a bad thing is staggering. Agreed about Bank of America being brain dead. I can see some theoretical benefits that if you have a list of banks with SPF and you receive an email from an address that the bank lists then you can safely pass it. But I find that an easier way to do that is to use FCrDNS to do the same thing. Which fails when you have someone that has multiple domains that may be sending mail "from" the same organization. Mail to me from Citi may comes from any one of at least 6 different domains, and the mailserver is not necessarily in the same domain. Whitelist all 6 domains. On the down site SPF breaks email forwarding uh huh. For certain values of "breaks" and "forwarding". Resend the message as a rfc2822 attachment and... zomg, nothing is broken. Recipient gets the original unaltered message and the SMTP process doesn't have to lie about who the sender of the message is. But that takes some degree of effort on the part of mailserver, so it is widely ignored as it would constitute work. Also, keep in mind that SPF has THREE states. Pass, fail, soft fail. $ dig kreme.com txt +short "v=spf1 mx include:covisp.net ~all" only my mx server or the specific domain covisp.net is allowed to send email 'from' my domain. No other host sending mail from my domain is to be considered valid. I could do, instead: "v=spf1 mx include:covisp.net ?all" This means, hey, my mx server or any machine at this domain will send mail for me. If the email comes from there, SPF passes, but if it DIDN'T come from there, it might still be me, so only do a soft fail. because sometimes I route my mail out over gmail, or my friend ziggy.tld." Many admins will reject both fail and soft-fail as failures, which is wrong. As someone who forwards email what I see is this. Sender has restrictive SPF. Recipient server enforces SPF. Mail coming through me bounces. Then they call me to complain and I say, I didn't bounce it. Get rid of your SPF nd your email will be received. and it creates a false sense that people are doing something to fight spam or protect ham that is not supported by reality. SPF has received intellectual welfare because stuff that doesn't work tends to be culled out of spam assassin and other than backscatter most people here are telling the SPF supporters that it doesn't work. If SPF is becoming more popular it just means that more people are misled. SPF is becoming more popular because it is *effective* at what it does. Currently I only use SPF within SA checks because it makes it trivial to catch most of the phishing scams. I'm not hearing from people in this forum who are saying it works. Even those who are SPF evangelists can't point to any significant results in either blocking spam or passing ham. Can you catch phishing without false positives from forwarding where the forwarder does not use SRS?
Re: Off Topic - SPF - What a Disaster
Jeff Koch wrote: At 02:31 PM 2/25/2010, you wrote: Marc Perkel wrote on Thu, 25 Feb 2010 09:29:48 -0800: > The anti-SPF bandwagon is not ego driven but results driven. Than you > for admitting that SPF in not a spam filtering solution. However it is > also not a white listing solution because as many people have said here > - spammers are the ones who are using SPF correctly. You make the same mistake again. SPF is for assuring that mail with a certain sender domain was sent from a mailserver that is allowed to send mail for that domain. Nothing more, nothing less. It's for instance often used to have mail bypass greylisting as it doesn't make sense to greylist mail from an apparent mailserver. This has nothing to do with spam. Certain combinations of SPF results and other stuff may typically indicate a spam or ham, but in general you just get a validation if that server was allowed to send. That is, by definition, whitelisting. If SPF was adapted 99% (and always strict with no allowance of not-listed servers), then you could also do blacklisting based on this. Still, this doesn't mean that you can use it for bland-and -white spam-filtering. You could just reject *some* spam (that is now rejected by RBLs and access lists, anyway). The only problem here is that a loose SPF definition can include all servers. To allow this was a big mistake. If someone doesn't want to restrict themselves to a certain range of servers, then they shouldn't use SPF. Kai I disagree. SPF is just one of the tools - among other tools (e.g. DKIM, domain keys, not accepting email from servers with no RDNS, etc) - developed to help reduce spam. I'd like to find a way to get people to get their FCrDNS correct. The way I see it if they can't get RDNS correct they aren't going to get SPF correct. Unfortunately I get a lot of ham from IPs with no RDNS.
Re: Off Topic - SPF - What a Disaster
Kai Schaetzl wrote: Marc Perkel wrote on Thu, 25 Feb 2010 09:29:48 -0800: The anti-SPF bandwagon is not ego driven but results driven. Than you for admitting that SPF in not a spam filtering solution. However it is also not a white listing solution because as many people have said here - spammers are the ones who are using SPF correctly. You make the same mistake again. SPF is for assuring that mail with a certain sender domain was sent from a mailserver that is allowed to send mail for that domain. Nothing more, nothing less. It's for instance often used to have mail bypass greylisting as it doesn't make sense to greylist mail from an apparent mailserver. This has nothing to do with spam. Certain combinations of SPF results and other stuff may typically indicate a spam or ham, but in general you just get a validation if that server was allowed to send. That is, by definition, whitelisting. If SPF was adapted 99% (and always strict with no allowance of not-listed servers), then you could also do blacklisting based on this. Still, this doesn't mean that you can use it for bland-and -white spam-filtering. You could just reject *some* spam (that is now rejected by RBLs and access lists, anyway). The only problem here is that a loose SPF definition can include all servers. To allow this was a big mistake. If someone doesn't want to restrict themselves to a certain range of servers, then they shouldn't use SPF. SPF will never be 99% adopted until it actually does something that is significantly useful. Using it as a white list to bypass a grey list isn't what I would call significantly useful. SPF fails the "actually works" test.
Re: Off Topic - SPF - What a Disaster
Rick Cooper wrote: >>> The anti-SPF bandwagon is not ego driven but results driven. Than you >>> for admitting that SPF in not a spam filtering solution. However it >>> is also not a white listing solution because as many people have said >>> here - spammers are the ones who are using SPF correctly. I can see >>> some theoretical benefits that if you have a list of banks with SPF >>> and you receive an email from an address that the bank lists then you >>> can safely pass it. But I find that an easier way to do that is to >>> use FCrDNS to do the same thing. >>> On the down site SPF breaks email forwarding and it creates a false >>> sense that people are doing something to fight spam or protect ham >>> that is not supported by reality. SPF has received intellectual >>> welfare because stuff that doesn't work tends to be culled out of >>> spam assassin and other than backscatter most people here are telling >>> the SPF supporters that it doesn't work. If SPF is becoming more >>> popular it just means that more people are misled. So then SRS Doesn't work for forwarding systems? I ask because I am not a forwarding service and, as I only handle corporate mail systems, do not give access to arbitrary forwarding to the mail users so we do not have tons of (external) forwarding going on. Since SPF and SRS are like legs on the same body I will assume trying to walk with one leg produces results similar to a forwarding service using SPF without SRS. I personally would love comcast would list all of their Valid outbound mail hosts and hard fail all others, same with aol, yahoo, gmail, etc. Seems to me if you are going to push email all over hell's half acre it behooves you To use any and all tools available to take responsibility for those mails and SPF is One of several tools that can do that, at least to some extent. If there would have been Some kind of total commitment to spam 10 years ago we would not be where we are today and Spamassassin (as it is) would not be quite so necessary. (My apologies for the pathetic attempt at manually reformatting the original html post) SRS is even more broken than SPF. I allow users to white list or black list based on the sender. If you rewrite the sender then you lose sender based conditionals. SRS has no use other than to try to fix SPF which has no use in the first place.
Re: Off Topic - SPF - What a Disaster
How silly. That's like saying an iPhone is not a gaming device even though plenty of people use it to play game apps. Perhaps you should re-read the SPF FAQ's. At 04:31 PM 2/25/2010, you wrote: Jeff Koch wrote on Thu, 25 Feb 2010 15:08:46 -0500: > I disagree. I don't know to what you disagree, but SPF is not an anti-spam tool. Full stop. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com Best Regards, Jeff Koch, Intersessions
Re: Off Topic - SPF - What a Disaster
Jeff Koch wrote on Thu, 25 Feb 2010 15:08:46 -0500: > I disagree. I don't know to what you disagree, but SPF is not an anti-spam tool. Full stop. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: Off Topic - SPF - What a Disaster
On 25-Feb-2010, at 10:29, Marc Perkel wrote: > > The anti-SPF bandwagon is not ego driven but results driven. Than you for > admitting that SPF in not a spam filtering solution. However it is also not a > white listing solution because as many people have said here - spammers are > the ones who are using SPF correctly. If you blindly accept any email with a valid spf as being 'good' email then your not understanding the system. Here's where spf is useful. You have an emailer (a bank, a company, aol, hotmail, whatever) that is a frequent target of spoofing. You can either spend a lot of time and resources trying to catch the spoof emails while not trashing the real ones, or you can enable spf. So, if an email comes in to my mailspool from paypal.com and it passes spf, it is treated as a normal message. It still goes through SA. But if it comes in "from" paypal.com and DOESN'T pass spf, it instantly gets 5 points added to it because if it's claiming to be from paypal AND it fails SPF, it is *not* from paypal. So, while SPF is *not* an anti-spam tool, in the case of paypal, and ebay, and citibank (but not the mentally challenged lemurs at bankofamerica) the *lack* of SPF become an anti-spam tool (more often a anti-phishing tool, really). How any mailadmin can think this is a bad thing is staggering. > I can see some theoretical benefits that if you have a list of banks with > SPF and you receive an email from an address that the bank lists then you can > safely pass it. But I find that an easier way to do that is to use FCrDNS to > do the same thing. Which fails when you have someone that has multiple domains that may be sending mail "from" the same organization. Mail to me from Citi may comes from any one of at least 6 different domains, and the mailserver is not necessarily in the same domain. > On the down site SPF breaks email forwarding uh huh. For certain values of "breaks" and "forwarding". Resend the message as a rfc2822 attachment and... zomg, nothing is broken. Recipient gets the original unaltered message and the SMTP process doesn't have to lie about who the sender of the message is. But that takes some degree of effort on the part of mailserver, so it is widely ignored as it would constitute work. Also, keep in mind that SPF has THREE states. Pass, fail, soft fail. $ dig kreme.com txt +short "v=spf1 mx include:covisp.net ~all" only my mx server or the specific domain covisp.net is allowed to send email 'from' my domain. No other host sending mail from my domain is to be considered valid. I could do, instead: "v=spf1 mx include:covisp.net ?all" This means, hey, my mx server or any machine at this domain will send mail for me. If the email comes from there, SPF passes, but if it DIDN'T come from there, it might still be me, so only do a soft fail. because sometimes I route my mail out over gmail, or my friend ziggy.tld." Many admins will reject both fail and soft-fail as failures, which is wrong. > and it creates a false sense that people are doing something to fight spam or > protect ham that is not supported by reality. SPF has received intellectual > welfare because stuff that doesn't work tends to be culled out of spam > assassin and other than backscatter most people here are telling the SPF > supporters that it doesn't work. If SPF is becoming more popular it just > means that more people are misled. SPF is becoming more popular because it is *effective* at what it does. Currently I only use SPF within SA checks because it makes it trivial to catch most of the phishing scams. -- They say only the good die young. If it works the other way too I'm immortal
Re: Off Topic - SPF - What a Disaster
At 02:31 PM 2/25/2010, you wrote: Marc Perkel wrote on Thu, 25 Feb 2010 09:29:48 -0800: > The anti-SPF bandwagon is not ego driven but results driven. Than you > for admitting that SPF in not a spam filtering solution. However it is > also not a white listing solution because as many people have said here > - spammers are the ones who are using SPF correctly. You make the same mistake again. SPF is for assuring that mail with a certain sender domain was sent from a mailserver that is allowed to send mail for that domain. Nothing more, nothing less. It's for instance often used to have mail bypass greylisting as it doesn't make sense to greylist mail from an apparent mailserver. This has nothing to do with spam. Certain combinations of SPF results and other stuff may typically indicate a spam or ham, but in general you just get a validation if that server was allowed to send. That is, by definition, whitelisting. If SPF was adapted 99% (and always strict with no allowance of not-listed servers), then you could also do blacklisting based on this. Still, this doesn't mean that you can use it for bland-and -white spam-filtering. You could just reject *some* spam (that is now rejected by RBLs and access lists, anyway). The only problem here is that a loose SPF definition can include all servers. To allow this was a big mistake. If someone doesn't want to restrict themselves to a certain range of servers, then they shouldn't use SPF. Kai I disagree. SPF is just one of the tools - among other tools (e.g. DKIM, domain keys, not accepting email from servers with no RDNS, etc) - developed to help reduce spam. -- Get your web at Conactive Internet Services: http://www.conactive.com Best Regards, Jeff Koch, Intersessions
Re: Off Topic - SPF - What a Disaster
Marc Perkel wrote: > I can see some theoretical benefits that if you have a list of banks > with SPF and you receive an email from an address that the bank lists > then you can safely pass it. But I find that an easier way to do that > is to use FCrDNS to do the same thing. Not a theoretical benefit, whitelist_from_spf works very well, I just don't get to use it very often. IMO it also requires a little less effort than whitelist_from_rcvd. /Per Jessen, Zürich
Re: Off Topic - SPF - What a Disaster
Marc Perkel wrote on Thu, 25 Feb 2010 09:29:48 -0800: > The anti-SPF bandwagon is not ego driven but results driven. Than you > for admitting that SPF in not a spam filtering solution. However it is > also not a white listing solution because as many people have said here > - spammers are the ones who are using SPF correctly. You make the same mistake again. SPF is for assuring that mail with a certain sender domain was sent from a mailserver that is allowed to send mail for that domain. Nothing more, nothing less. It's for instance often used to have mail bypass greylisting as it doesn't make sense to greylist mail from an apparent mailserver. This has nothing to do with spam. Certain combinations of SPF results and other stuff may typically indicate a spam or ham, but in general you just get a validation if that server was allowed to send. That is, by definition, whitelisting. If SPF was adapted 99% (and always strict with no allowance of not-listed servers), then you could also do blacklisting based on this. Still, this doesn't mean that you can use it for bland-and -white spam-filtering. You could just reject *some* spam (that is now rejected by RBLs and access lists, anyway). The only problem here is that a loose SPF definition can include all servers. To allow this was a big mistake. If someone doesn't want to restrict themselves to a certain range of servers, then they shouldn't use SPF. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
RE: Off Topic - SPF - What a Disaster
>>> From: Marc Perkel [mailto:m...@perkel.com] Sent: Thursday, February >>> 25, 2010 12:30 PM To: ram Cc: users@spamassassin.apache.org Subject: >>> Re: Off Topic - SPF - What a Disaster >>> ram wrote: >>> On Tue, 2010-02-23 at 18:33 -0800, Marc Perkel wrote: >> Jeff Koch wrote: >> >> >> In an effort to reduce spam further we tried implementing SPF >> enforcement. Within three days we turned it off. What we found was >> that: >> >> - domain owners are allowing SPF records to be added to their zone >> files without understanding the implications or that are just not >> correct - domain owners and their employees regularly send email from >> mailservers that violate their SPF. - our customers were unable to >> receive email from important business contacts - our customers were >> unable to understand why we would be enforcing a system that >> prevented them from getting important email. - our customers couldn't >> understand what SPF does. - our customers could not explain SPF to >> their business contacts who would have had to contact their IT people >> to correct the SPF records. >> >> Our assessment is that SPF is a good idea but pretty much unworkable >> for an ISP/host without a major education program which we neither >> have the time or money to do. Since we like our customers and they >> pay the bills it is now a dead issue. >> >> Any other experiences? I love to hear. >> Best Regards, >> Jeff Koch, Intersessions >>> I agree. I've been in the spam filtering business for many years and >>> have yetto find any use for SPF at all. It's disturbing this useless >>> technology is getting the false positive support we are seeing. >>> Marc, This is just to repeat the cliche. SPF was not designed to help >>> *you* in *spam filtering*. This was designed to help legitimate >>> senders send mails. >>> However as much as you, unreasonably , dislike it .. SPF adoption is >>> on the rise.Two years ago most banks in India had no SPF records. >>> Today almost every bank here publishes a SPF record. And that helps. >>> For eg I use SPF checks to whitelist all local banks mail. >>> Conversely, I have a custom rule that says if the header-from >>> contains $popularbank.com and mail did not SPF pass add a score of >>> 3.0. Phishers can use whatever envelope from they want. But if they >>> put the banks domain in the header-from the mail will be caught as >>> spam. I know there are ways to get around this rule too but in >>> practical life this has been real effective against phishing. >>> IMHO most of the anti-SPF bandwagon is more due ego issues than >>> technical. >>> The anti-SPF bandwagon is not ego driven but results driven. Than you >>> for admitting that SPF in not a spam filtering solution. However it >>> is also not a white listing solution because as many people have said >>> here - spammers are the ones who are using SPF correctly. I can see >>> some theoretical benefits that if you have a list of banks with SPF >>> and you receive an email from an address that the bank lists then you >>> can safely pass it. But I find that an easier way to do that is to >>> use FCrDNS to do the same thing. >>> On the down site SPF breaks email forwarding and it creates a false >>> sense that people are doing something to fight spam or protect ham >>> that is not supported by reality. SPF has received intellectual >>> welfare because stuff that doesn't work tends to be culled out of >>> spam assassin and other than backscatter most people here are telling >>> the SPF supporters that it doesn't work. If SPF is becoming more >>> popular it just means that more people are misled. So then SRS Doesn't work for forwarding systems? I ask because I am not a forwarding service and, as I only handle corporate mail systems, do not give access to arbitrary forwarding to the mail users so we do not have tons of (external) forwarding going on. Since SPF and SRS are like legs on the same body I will assume trying to walk with one leg produces results similar to a forwarding service using
Re: Off Topic - SPF - What a Disaster
On Thu, 25 Feb 2010 12:55:50 +0530 ram wrote: > On Tue, 2010-02-23 at 18:33 -0800, Marc Perkel wrote: > > > I agree. I've been in the spam filtering business for many years > > and have yetto find any use for SPF at all. It's disturbing this > > useless technology is getting the false positive support we are > > seeing. > > > Marc, > This is just to repeat the cliche. SPF was not designed to help *you* > in *spam filtering*. This was designed to help legitimate senders send > mails. Just because it's a cliche doesn't mean it's true: From the SPF FAQ: " What is SPF and why is it complicating my life? Sender Policy Framework (SPF) is an attempt to control forged e-mail. SPF is not directly about stopping spam – junk email. It is about giving domain owners a way to say which mail sources are legitimate for their domain and which ones aren't. While not all spam is forged, virtually all forgeries are spam. SPF is not anti-spam in the same way that flour is not food: it is part of the solution. SPF was created in 2003 to help close loopholes in email delivery systems that allow spammers to “spoof” or steal your email address to send hundreds, thousands or even millions of emails illicitly."
Re: Off Topic - SPF - What a Disaster
On Tue, 2010-02-23 at 18:33 -0800, Marc Perkel wrote: > > Jeff Koch wrote: > > > > In an effort to reduce spam further we tried implementing SPF > > enforcement. Within three days we turned it off. What we found was that: > > > > - domain owners are allowing SPF records to be added to their zone > > files without understanding the implications or that are just not correct > > - domain owners and their employees regularly send email from > > mailservers that violate their SPF. > > - our customers were unable to receive email from important business > > contacts > > - our customers were unable to understand why we would be enforcing a > > system that prevented > > them from getting important email. > > - our customers couldn't understand what SPF does. > > - our customers could not explain SPF to their business contacts who > > would have had to contact their IT people to correct the SPF records. > > > > Our assessment is that SPF is a good idea but pretty much unworkable > > for an ISP/host without a major education program which we neither > > have the time or money to do. Since we like our customers and they pay > > the bills it is now a dead issue. > > > > Any other experiences? I love to hear. > > > > > > > > Best Regards, > > > > Jeff Koch, Intersessions > > > > I agree. I've been in the spam filtering business for many years and > have yetto find any use for SPF at all. It's disturbing this useless > technology is getting the false positive support we are seeing. > Marc, This is just to repeat the cliche. SPF was not designed to help *you* in *spam filtering*. This was designed to help legitimate senders send mails. However as much as you, unreasonably , dislike it .. SPF adoption is on the rise.Two years ago most banks in India had no SPF records. Today almost every bank here publishes a SPF record. And that helps. For eg I use SPF checks to whitelist all local banks mail. Conversely, I have a custom rule that says if the header-from contains $popularbank.com and mail did not SPF pass add a score of 3.0. Phishers can use whatever envelope from they want. But if they put the banks domain in the header-from the mail will be caught as spam. I know there are ways to get around this rule too but in practical life this has been real effective against phishing. IMHO most of the anti-SPF bandwagon is more due ego issues than technical. Thanks Ram
Re: Off Topic - SPF - What a Disaster
On Wed 24 Feb 2010 05:58:02 PM CET, Kelson wrote And as people on this list have pointed out 5,000 times, including myself yesterday: whitelist_from_spf *...@example.com def_whitelist_auth *...@example.com whitelist_auth u...@example.com freemail_whitelist u...@example.com this way its more secure for recipient the def is managed by me as a hoster, and the non def is dumped from address book -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
RE: Off Topic - SPF - What a Disaster
> > SPF works great as a selective whitelist in SpamAssassin. (And I don't > > mean whitelisting all SPF passes. That would be stupid. I mean > > whitelisting mail coming from domain X, but only when it passes SPF > > and demonstrates that yes, it really came from domain X.) > > > > I'd say that what you found is *not* that SPF itself is a disaster, > > but that enforcing SPF by rejecting failures is a disaster. > > +1 +1. I implement SPF records on all my hosted domains, it's trivial, but to this date I haven't found any real use for it filtering on it. I think the only reason that I put it in place to begin with is to be in compliance with yahoo (or some other provider) some years ago after they bounced some mail. I feel that if it were enforced but several of the larger email companies then it would cause everyone to implement it and then it might have value at limiting zombies, but that's about it. Since they haven't enforced it, there isn't much more that can be done. If we enforce it, it makes us look like idiots when our clients can't get email, and then we look like idiots and they turn to the larger (or should I say more popular) companies.
Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster
On Wed, February 24, 2010 2:28 am, Per Jessen wrote: > Christian Brel wrote: > >> On Wed, 24 Feb 2010 09:18:38 +0100 >> Per Jessen wrote: >> >>> LuKreme wrote: >>> >>> > On 23-Feb-10 14:17, Bowie Bailey wrote: >>> >> SPF enforcement at the MTA is useless for the reasons you >>> >> specified. The only exception is if you have a strict SPF policy >>> >> for your own domain, you can use it to reject spam pretending to >>> >> be from your users. >>> > >>> > And that makes it worthwhile all by itself. >>> > >>> >>> Well, I guess it depends on your point of view - how difficult is it >>> to set up an MTA to reject mails pretending to be from >>> that didn't originate on your MTA? >>> >>> >>> /Per Jessen, Zürich >>> >> >> Good question - how would you do it? > > Postfix: I would have two different smtpd daemons - one for the local > network, one for the external. The external smtpd would have a > check_sender_access along these lines (thinking out loud here): ... which is why I use sendmail. It now comes standard with 2 different daemons, built into one so the setup isn't so complicated: one for external access and one for internal access. Already doing what you suggest out of the box, and it works quite well, if configured securely. One activity rejects attempts to send email pretending to be 'on the inside' and the other rejects to send email pretending to be 'on the outside' thus preventing much of what has been discussed ... > > check_sender_access = hash:/etc/postfix/reject_from_my_domain > > etc/postfix/reject_from_my_domain would have: > > example.com 5xx > > > /Per Jessen, Zürich > --- Karl Pearson ka...@ourldsfamily.com Owner/Administrator of the sites at http://ourldsfamily.com --- "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." --- Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote. --Benjamin Franklin --- Prayer for Obama, et al: http://scriptures.lds.org/en/ps/109/8#8 (~) ---
Re: Off Topic - SPF - What a Disaster
On 2/23/2010 6:33 PM, Marc Perkel wrote: I agree. I've been in the spam filtering business for many years and have yetto find any use for SPF at all. It's disturbing this useless technology is getting the false positive support we are seeing. And as people on this list have pointed out 5,000 times, including myself yesterday: whitelist_from_spf *...@example.com This applies a whitelist rule to messages from example.com if and only if they also pass example.com's SPF policy. So there's one use case right there, unless you're going to claim that functionality is useless. -- Kelson Vibber SpeedGate Communications
Re: Off Topic - SPF - What a Disaster
On Wed, 24 Feb 2010 17:09:31 +0100 Per Jessen wrote: > > Tell you what, wouldn't it be a great idea to save all the messing > > around and use something universal and simple for the job? Something > > lightweight and easy to deploy. I know! What about using SPF! > > Christian, I suspect we don't have quite the same understanding of > what 'easy' means. I guess that is so. Personally I find the multiple use of Postfixens trivial easy and have it deployed that way to get over it's inability to whitelist body and header checks {at all}. In general terms your fix may not suit common MTA's like Exchange (I feel quite disgusted to have described Exchange as an MTA and will now go and wash my typing fingers.) I did find a bad place to use SPF - and that is on a well known spam filter made by an American company. Enable it there and watch the machine grind to a halt. 'it's a feature - not a bug' LOL could'nt resist it... I'll get my coat.. > > > /Per Jessen, Zürich >
Re: Off Topic - SPF - What a Disaster
> > On 23.02.10 16:17, Bowie Bailey wrote: > >> SPF enforcement at the MTA is useless for the reasons you specified. > >> The only exception is if you have a strict SPF policy for your own > >> domain, you can use it to reject spam pretending to be from your users. > Matus UHLAR - fantomas wrote: > > And what is this, if not enforcing SPF at MTA level? On 24.02.10 09:03, Bowie Bailey wrote: > This is selective enforcement of a domain (or list of domains) that are > known to have working SPF records. so, it's enabling/disabling of SPF usage for some domains. > > Also, this can be solved at MTA level without SPF enforcement. Afaik some > > servers are already rejecting mail from "their users" without proper > > authentification. > True, but then you need to keep track of which mail servers are allowed > to send mail for each domain. Which, coincidentally, is exactly what > SPF does. that's why I'd keep it on SPF, probably with listing of domains that should/shoult not be checked. It's much easier to do it with SPF than maintaining list of domains/servers. And you can even tell which domains (or their users) have broken setup and optionally notify them. For some domains/senders (e.g. freemails), we could argument that it's the freemail provider who wishes it this way and the sender is breaking the domain policy... > (This is assuming a more complex configuration than just rejecting > everything that does not originate locally.) otoh, it does much more for you. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "One World. One Web. One Program." - Microsoft promotional advertisement "Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
Re: Off Topic - SPF - What a Disaster
Matus UHLAR - fantomas wrote: > On 23.02.10 16:17, Bowie Bailey wrote: > >> SPF enforcement at the MTA is useless for the reasons you specified. >> The only exception is if you have a strict SPF policy for your own >> domain, you can use it to reject spam pretending to be from your users. >> > > And what is this, if not enforcing SPF at MTA level? > This is selective enforcement of a domain (or list of domains) that are known to have working SPF records. > Also, this can be solved at MTA level without SPF enforcement. Afaik some > servers are already rejecting mail from "their users" without proper > authentification. > True, but then you need to keep track of which mail servers are allowed to send mail for each domain. Which, coincidentally, is exactly what SPF does. (This is assuming a more complex configuration than just rejecting everything that does not originate locally.) -- Bowie
Re: Off Topic - SPF - What a Disaster
On 23.02.10 16:17, Bowie Bailey wrote: > SPF enforcement at the MTA is useless for the reasons you specified. > The only exception is if you have a strict SPF policy for your own > domain, you can use it to reject spam pretending to be from your users. And what is this, if not enforcing SPF at MTA level? Also, this can be solved at MTA level without SPF enforcement. Afaik some servers are already rejecting mail from "their users" without proper authentification. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. WinError #98652: Operation completed successfully.
Re: Off Topic - SPF - What a Disaster
On 23.02.10 15:38, Jeff Koch wrote: > In an effort to reduce spam further we tried implementing SPF > enforcement. You should implement SPF in order to prevent mail forgery, not spam. SPF is a tool to reduce forgery, not spam. The fact that most of spam has forged address only helps you. > Within three days we turned it off. What we found was that: You have turned it on where? In your MTA at SMTP level? In your domain(s)? In both? And in your domain(s), hard or soft fail? > - domain owners are allowing SPF records to be added to their zone files > without understanding the implications or that are just not correct domain owners can do anything with their domains, wheter it's correct or not. > - domain owners and their employees regularly send email from mailservers > that violate their SPF. This is a main problem we all should try to avoid. Many domains' owners e.g. ESPs are already trying to avoid this by putting SPF and DKIM records to their domains. So you have turned it off? They won't be glad. > - our customers were unable to receive email from important business contacts > - our customers were unable to understand why we would be enforcing a > system that prevented > them from getting important email. Well, because senders' admins wish to do so. > - our customers couldn't understand what SPF does. > - our customers could not explain SPF to their business contacts who > would have had to contact their IT people to correct the SPF records. their business contacts are apparently doing something against themselves. > Our assessment is that SPF is a good idea but pretty much unworkable for > an ISP/host without a major education program which we neither have the > time or money to do. Since we like our customers and they pay the bills > it is now a dead issue. Well, many people are admitting "SPF is broken", just because others are doing stuff (use incorrect SMTP servers, resending the mail using others' sender addresses) which are in fact broken, not SPF. What I understand, there should be some kind of local SPF whitelists, allowing known broken forwarders, decreasing FAIL from hard to soft for some domains... I don't think that not implementing techniques because some people tend to break things is a way to go. Forcing them to fix broken things is. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. WinError #9: Out of error messages.
Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster
On Wed, 24 Feb 2010 10:28:24 +0100 Per Jessen wrote: > Christian Brel wrote: > > > On Wed, 24 Feb 2010 09:18:38 +0100 > > Per Jessen wrote: > > > >> LuKreme wrote: > >> > >> > On 23-Feb-10 14:17, Bowie Bailey wrote: > >> >> SPF enforcement at the MTA is useless for the reasons you > >> >> specified. The only exception is if you have a strict SPF policy > >> >> for your own domain, you can use it to reject spam pretending to > >> >> be from your users. > >> > > >> > And that makes it worthwhile all by itself. > >> > > >> > >> Well, I guess it depends on your point of view - how difficult is > >> it to set up an MTA to reject mails pretending to be from > >> that didn't originate on your MTA? > >> > >> > >> /Per Jessen, Zürich > >> > > > > Good question - how would you do it? > > Postfix: I would have two different smtpd daemons - one for the local > network, one for the external. The external smtpd would have a > check_sender_access along these lines (thinking out loud here): > > check_sender_access = hash:/etc/postfix/reject_from_my_domain > > etc/postfix/reject_from_my_domain would have: > > example.com 5xx > > > /Per Jessen, Zürich > So you would reject outbound mail from your domain? I'm sure that's a typo. The agrovation of multi-instancing Postfix onto a different port or IP, seeking help from their aggressive and abusive user list when it fails to work -v- SPF. Ummm such a choice.
Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster
Mariusz Kruk wrote: > On Wednesday, 24 of February 2010, Per Jessen wrote: >> >> Well, I guess it depends on your point of view - how difficult is >> >> it to set up an MTA to reject mails pretending to be from >> >> that didn't originate on your MTA? >> > Good question - how would you do it? >> >> Postfix: I would have two different smtpd daemons - one for the >> local network, one for the external. The external smtpd would have a >> check_sender_access along these lines (thinking out loud here): >> >> check_sender_access = hash:/etc/postfix/reject_from_my_domain >> >> etc/postfix/reject_from_my_domain would have: >> >> example.com 5xx > > How's it different from the "standard" approach - permitting > mynetworks and then rejecting mails "from self"? Two instances of > postfix only make the setup more complicated. Barely, but I think you're right, that approach works equally well. /Per Jessen, Zürich
Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster
On Wednesday, 24 of February 2010, Per Jessen wrote: > >> Well, I guess it depends on your point of view - how difficult is it > >> to set up an MTA to reject mails pretending to be from > >> that didn't originate on your MTA? > > Good question - how would you do it? > > Postfix: I would have two different smtpd daemons - one for the local > network, one for the external. The external smtpd would have a > check_sender_access along these lines (thinking out loud here): > > check_sender_access = hash:/etc/postfix/reject_from_my_domain > > etc/postfix/reject_from_my_domain would have: > > example.com 5xx How's it different from the "standard" approach - permitting mynetworks and then rejecting mails "from self"? Two instances of postfix only make the setup more complicated. -- /\-\/\-\/\-\/\-\/\-\/\-\/\ \ k...@epsilon.eu.org / / http://epsilon.eu.org/ \ \/-/\/-/\/-/\/-/\/-/\/-/\/
Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster
Christian Brel wrote: > On Wed, 24 Feb 2010 09:18:38 +0100 > Per Jessen wrote: > >> LuKreme wrote: >> >> > On 23-Feb-10 14:17, Bowie Bailey wrote: >> >> SPF enforcement at the MTA is useless for the reasons you >> >> specified. The only exception is if you have a strict SPF policy >> >> for your own domain, you can use it to reject spam pretending to >> >> be from your users. >> > >> > And that makes it worthwhile all by itself. >> > >> >> Well, I guess it depends on your point of view - how difficult is it >> to set up an MTA to reject mails pretending to be from >> that didn't originate on your MTA? >> >> >> /Per Jessen, Zürich >> > > Good question - how would you do it? Postfix: I would have two different smtpd daemons - one for the local network, one for the external. The external smtpd would have a check_sender_access along these lines (thinking out loud here): check_sender_access = hash:/etc/postfix/reject_from_my_domain etc/postfix/reject_from_my_domain would have: example.com 5xx /Per Jessen, Zürich
Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster
On Wed, 24 Feb 2010 09:18:38 +0100 Per Jessen wrote: > LuKreme wrote: > > > On 23-Feb-10 14:17, Bowie Bailey wrote: > >> SPF enforcement at the MTA is useless for the reasons you > >> specified. The only exception is if you have a strict SPF policy > >> for your own domain, you can use it to reject spam pretending to > >> be from your users. > > > > And that makes it worthwhile all by itself. > > > > Well, I guess it depends on your point of view - how difficult is it > to set up an MTA to reject mails pretending to be from > that didn't originate on your MTA? > > > /Per Jessen, Zürich > Good question - how would you do it?
Re: Off Topic - SPF - What a Disaster
LuKreme wrote: > On 23-Feb-10 14:17, Bowie Bailey wrote: >> SPF enforcement at the MTA is useless for the reasons you specified. >> The only exception is if you have a strict SPF policy for your own >> domain, you can use it to reject spam pretending to be from your >> users. > > And that makes it worthwhile all by itself. > Well, I guess it depends on your point of view - how difficult is it to set up an MTA to reject mails pretending to be from that didn't originate on your MTA? /Per Jessen, Zürich
Re: Off Topic - SPF - What a Disaster
Kelson wrote: > SPF works great as a selective whitelist in SpamAssassin. (And I don't > mean whitelisting all SPF passes. That would be stupid. I mean > whitelisting mail coming from domain X, but only when it passes SPF > and demonstrates that yes, it really came from domain X.) > > I'd say that what you found is *not* that SPF itself is a disaster, > but that enforcing SPF by rejecting failures is a disaster. +1 /Per Jessen, Zürich
Re: Off Topic - SPF - What a Disaster
Jeff Koch wrote: In an effort to reduce spam further we tried implementing SPF enforcement. Within three days we turned it off. What we found was that: - domain owners are allowing SPF records to be added to their zone files without understanding the implications or that are just not correct - domain owners and their employees regularly send email from mailservers that violate their SPF. - our customers were unable to receive email from important business contacts - our customers were unable to understand why we would be enforcing a system that prevented them from getting important email. - our customers couldn't understand what SPF does. - our customers could not explain SPF to their business contacts who would have had to contact their IT people to correct the SPF records. Our assessment is that SPF is a good idea but pretty much unworkable for an ISP/host without a major education program which we neither have the time or money to do. Since we like our customers and they pay the bills it is now a dead issue. Any other experiences? I love to hear. Best Regards, Jeff Koch, Intersessions I agree. I've been in the spam filtering business for many years and have yetto find any use for SPF at all. It's disturbing this useless technology is getting the false positive support we are seeing.
Re: Off Topic - SPF - What a Disaster
On 23-Feb-10 14:17, Bowie Bailey wrote: SPF enforcement at the MTA is useless for the reasons you specified. The only exception is if you have a strict SPF policy for your own domain, you can use it to reject spam pretending to be from your users. And that makes it worthwhile all by itself. -- Is this planter made of lead?
Re: Off Topic - SPF - What a Disaster
On 23/02/2010 7:51 PM, Dave Pooser wrote: > 2) whitelist_auth is worth its weight in platinum Damn! I knew that should have been a subscription only feature! ;)
Re: Off Topic - SPF - What a Disaster
> Any other experiences? I love to hear. 1) Publishing SPF records at $DAYJOB coincided with a significant drop in backscatter seen. I don't know whether it's a matter of spammers forging fewer spam runs from SPFed domains, or other hosts being smart bout bounces, or 2) whitelist_auth is worth its weight in platinum -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com "...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!!" -- Bill McKenna
Re: Off Topic - SPF - What a Disaster
From: Martin Gregorie Date: Tue, 23 Feb 2010 22:04:07 + On Tue, 2010-02-23 at 16:17 -0500, Bowie Bailey wrote: > The only exception is if you have a strict SPF policy for your own > domain, you can use it to reject spam pretending to be from your users. Agreed. That's all I use it for. The SPF checks in SpamAssassin will score SPF_FAIL without adding enough points to block the email by itself. I'm not ready to outright block email that fail SPF. I installed SPF during a backscatter storm, which immediately decreased in volume. Since then the periodic backscatter showers have got steadily smaller, so it looks as though mailservers configured check SPF before bouncing undeliverable mail have been getting steadily more common. Either that or spammers tend to avoid forging domains that have SPF. -jeff
Re: Off Topic - SPF - What a Disaster
On Tue, 2010-02-23 at 16:17 -0500, Bowie Bailey wrote: > The only exception is if you have a strict SPF policy for your own > domain, you can use it to reject spam pretending to be from your users. > Agreed. That's all I use it for. I installed SPF during a backscatter storm, which immediately decreased in volume. Since then the periodic backscatter showers have got steadily smaller, so it looks as though mailservers configured check SPF before bouncing undeliverable mail have been getting steadily more common. Martin
Re: Off Topic - SPF - What a Disaster
On 2/23/2010 12:38 PM, Jeff Koch wrote: In an effort to reduce spam further we tried implementing SPF enforcement. Within three days we turned it off. What we found was that: Our assessment is that SPF is a good idea but pretty much unworkable for an ISP/host without a major education program which we neither have the time or money to do. Since we like our customers and they pay the bills it is now a dead issue. Any other experiences? I love to hear. SPF works great as a selective whitelist in SpamAssassin. (And I don't mean whitelisting all SPF passes. That would be stupid. I mean whitelisting mail coming from domain X, but only when it passes SPF and demonstrates that yes, it really came from domain X.) I'd say that what you found is *not* that SPF itself is a disaster, but that enforcing SPF by rejecting failures is a disaster. It's a data point. It all depends on how you use it. -- Kelson Vibber SpeedGate Communications
Re: Off Topic - SPF - What a Disaster
On 2/23/10 3:38 PM, Jeff Koch wrote: since SpamAssassin doesn't block email (and actually, the scoring for spf failures is pretty low), you must have munged something else up. if you tried to do pre-queue SPF blocking, yep, go to wsj, yahoo, 'send link to a friend' and you don't get email, its because your pre-queue filter messed things up. Can't get email from important business contacts? what has that go to do with your clients SPF records? nothing. maybe the SENDERS had it messed up. you are right, if you don't know what SPF is, don't use it. If I send email to someone and they FWD it (.forward) without proper forwarding, then maybe I didn't want that important email forwarded to hell and back. Its all about the RFC's. and (80%?) of the mail servers out there violated the RFC's (and SPF is just one of the misused RFC's). How many don't even have valid FQDN's in EHLO? try to explain to a client that we don't allow inbound email from 'domain.com'. When the sender decided that a good internal microsoft 'domain' was domain? and the default FQDN on their MessServer is mail.domain.com? or (simi) static dsl or business cable, where the provider is too stupid or too lazy to set up a proper RDNS (PTR record)? or someone who's lawyer insists on using the freebie aol account for their business email address and wonders why it takes 6 hours to send a simple email to 100 of their clients? No, there are a lot stupider things you can do than set up SPF records. The best thing to do is publish them, but don't block if you have mismatches. (yes, the FAQ on our web site still says don't use SPF records) -- Michael Scheidell, CTO Phone: 561-999-5000, x 1259 > *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best Anti-Spam Product 2008, Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __
Re: Off Topic - SPF - What a Disaster
Jeff Koch wrote: > > In an effort to reduce spam further we tried implementing SPF > enforcement. Within three days we turned it off. What we found was that: > > - domain owners are allowing SPF records to be added to their zone > files without understanding the implications or that are just not correct > - domain owners and their employees regularly send email from > mailservers that violate their SPF. > - our customers were unable to receive email from important business > contacts > - our customers were unable to understand why we would be enforcing a > system that prevented > them from getting important email. > - our customers couldn't understand what SPF does. > - our customers could not explain SPF to their business contacts who > would have had to contact their IT people to correct the SPF records. > > Our assessment is that SPF is a good idea but pretty much unworkable > for an ISP/host without a major education program which we neither > have the time or money to do. Since we like our customers and they pay > the bills it is now a dead issue. > > Any other experiences? I love to hear. SPF enforcement at the MTA is useless for the reasons you specified. The only exception is if you have a strict SPF policy for your own domain, you can use it to reject spam pretending to be from your users. -- Bowie
Re: Off Topic - SPF - What a Disaster
On Tue, Feb 23, 2010 at 4:11 PM, Mike Hutchinson wrote: > Hello, > > My company attempted to adopt SPF before I started working here. I recall it > was a recent event when I joined, and I looked into what went wrong (as I > became the mail administrator not long after). Basically the exact same > experience was encountered. Customers could not understand the system, which > is basically what killed it. Some Admin's of remote systems sending our > customers important E-Mail did not understand the system, or even want to > deal with it - leaving us without the resources to fix all SPF related > problems. > > Adoption of SPF was dropped after 3 days, and we're never going back. > > Same result, SPF is a good idea, but we certainly cannot afford to train > other site's administrators, nor all of our customers, on SPF. ditto here. the only folks that seem capable of implementing SPF properly are the spammers > > Cheers, > Mike, > > > -Original Message- > From: Jeff Koch [mailto:jeffk...@intersessions.com] > Sent: Wednesday, 24 February 2010 9:38 a.m. > To: users@spamassassin.apache.org > Subject: Off Topic - SPF - What a Disaster > > > In an effort to reduce spam further we tried implementing SPF enforcement. > Within three days we turned it off. What we found was that: > > - domain owners are allowing SPF records to be added to their zone files > without understanding the implications or that are just not correct > - domain owners and their employees regularly send email from mailservers > that violate their SPF. > - our customers were unable to receive email from important business > contacts > - our customers were unable to understand why we would be enforcing a > system that prevented > them from getting important email. > - our customers couldn't understand what SPF does. > - our customers could not explain SPF to their business contacts who would > have had to contact their IT people to correct the SPF records. > > Our assessment is that SPF is a good idea but pretty much unworkable for an > ISP/host without a major education program which we neither have the time > or money to do. Since we like our customers and they pay the bills it is > now a dead issue. > > Any other experiences? I love to hear. > > > > Best Regards, > > Jeff Koch, Intersessions > >
RE: Off Topic - SPF - What a Disaster
Hello, My company attempted to adopt SPF before I started working here. I recall it was a recent event when I joined, and I looked into what went wrong (as I became the mail administrator not long after). Basically the exact same experience was encountered. Customers could not understand the system, which is basically what killed it. Some Admin's of remote systems sending our customers important E-Mail did not understand the system, or even want to deal with it - leaving us without the resources to fix all SPF related problems. Adoption of SPF was dropped after 3 days, and we're never going back. Same result, SPF is a good idea, but we certainly cannot afford to train other site's administrators, nor all of our customers, on SPF. Cheers, Mike, -Original Message- From: Jeff Koch [mailto:jeffk...@intersessions.com] Sent: Wednesday, 24 February 2010 9:38 a.m. To: users@spamassassin.apache.org Subject: Off Topic - SPF - What a Disaster In an effort to reduce spam further we tried implementing SPF enforcement. Within three days we turned it off. What we found was that: - domain owners are allowing SPF records to be added to their zone files without understanding the implications or that are just not correct - domain owners and their employees regularly send email from mailservers that violate their SPF. - our customers were unable to receive email from important business contacts - our customers were unable to understand why we would be enforcing a system that prevented them from getting important email. - our customers couldn't understand what SPF does. - our customers could not explain SPF to their business contacts who would have had to contact their IT people to correct the SPF records. Our assessment is that SPF is a good idea but pretty much unworkable for an ISP/host without a major education program which we neither have the time or money to do. Since we like our customers and they pay the bills it is now a dead issue. Any other experiences? I love to hear. Best Regards, Jeff Koch, Intersessions