Re: Bogus Dollar Amounts
On Wed, Feb 24, 2010 at 8:44 PM, Dennis B. Hopp dh...@coreps.com wrote: I have been seeing a few spam mails slip past that talk about being able to get bogus dollar amounts. What I mean by that is it will give a large value in the e-mail but where there should be a comma it puts a period. I put an example of one of these messages at: http://pastebin.com/SXuGELUS Are there any rules that can detect this? The only rules this hit on mine are: 1.900 DCC_CHECK 1.449 RCVD_IN_BRBL_LASTEXT 1.000 RCVD_IN_BRBL -0.001 SPF_PASS -0.010 T_RP_MATCHES_RCVD -1.900 BAYES_00 http://pastebin.com/6c9sEEn9 even recently i installed new qmail server i still see lot of junk mail coming with different charecters, i do not even read them clearly how can i stop those kind of emails Ram
Re: Bogus Dollar Amounts
On 25/02/2010 12:01, ram wrote: I have been seeing a few spam mails slip past that talk about being able to get bogus dollar amounts. What I mean by that is it will give a large value in the e-mail but where there should be a comma it puts a period. I put an example of one of these messages at: http://pastebin.com/SXuGELUS Are there any rules that can detect this? The only rules this hit on mine are: 1.900 DCC_CHECK 1.449 RCVD_IN_BRBL_LASTEXT 1.000 RCVD_IN_BRBL -0.001 SPF_PASS -0.010 T_RP_MATCHES_RCVD -1.900 BAYES_00 http://pastebin.com/6c9sEEn9 even recently i installed new qmail server i still see lot of junk mail coming with different charecters, i do not even read them clearly how can i stop those kind of emails Ram I repasted that at http://spamalyser.com/v/gcrvcnbm/mime in order to get the benefit of mime parsing and decoding. You could score on the koi8-r charset. You could score on the fact the email came from South Korea. You could use the TextCat language plugin. -- 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: Bogus Dollar Amounts
On Thu, 2010-02-25 at 17:31 +0530, ram wrote: http://pastebin.com/SXuGELUS Are there any rules that can detect this? The only rules this hit on mine are: 1.900 DCC_CHECK 1.449 RCVD_IN_BRBL_LASTEXT 1.000 RCVD_IN_BRBL -0.001 SPF_PASS -0.010 T_RP_MATCHES_RCVD -1.900 BAYES_00 Two of my private rules hit too: MG_MONEYrecognises monetary amounts in message bodies MG_SPAMREF recognised the live.com URI - IME thats pretty much a sure-fire spam flag. Martin
Re: Bogus Dollar Amounts
Ram wrote on Thu, 25 Feb 2010 17:31:04 +0530: how can i stop those kind of emails 11.Received: from unknown (HELO NANQRZBVJZ) (121.100.119.197) If you allow such a thing to deliver to you you actively ask for spam. I don't waste SA cycles on such stuff. Apart from that it seems your SA is outdated and your Bayes is not trained well. I don't use any RBL tests and get 20. X-Spam-Status: Yes, score=20.2 required=5.0 tests=BAYES_50,BODY_8BITS, CHARSET_FARAWAY_HEADER,FH_FAKE_RCVD_LINE_B,FSL_HELO_NON_FQDN_1,HK_BADNAME, HK_BADSUBJECT,KB_RATWARE_OUTLOOK_MID,MIME_CHARSET_FARAWAY,MIME_QP_LONG_LIN E, RDNS_NONE,UNWANTED_LANGUAGE_BODY autolearn=spam version=3.3.0 Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: Bogus Dollar Amounts
Dennis B. Hopp wrote on Wed, 24 Feb 2010 09:14:58 -0600: Obviously I have something going on with my bayes, but that's a separate issue Indeed. But it's an important issue. If it is that biased for other spam as well youa re better off to not use it in this state. X-Spam-Status: No, score=2.8 required=5.0 tests=BAYES_50,HK_MUCHMONEY, T_LOTS_OF_MONEY,UNPARSEABLE_RELAY autolearn=no version=3.3.0 add your RBL score and it's way over 5. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: Off Topic - SPF - What a Disaster
On Thu, 25 Feb 2010 12:55:50 +0530 ram r...@netcore.co.in 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: Bogus Dollar Amounts
On Thu, 25 Feb 2010, ram wrote: http://pastebin.com/6c9sEEn9 i still see lot of junk mail coming with different charecters, i do not even read them clearly how can i stop those kind of emails Reject languages you can't read at SMTP time? -- 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 --- You do not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harms it would cause if improperly administered. -- Lyndon B. Johnson --- 139 days since President Obama won the Nobel Not George W. Bush prize
Re: [sa] Re: Bogus Dollar Amounts
On Thu, 25 Feb 2010, John Hardin wrote: i still see lot of junk mail coming with different charecters, i do not even read them clearly how can i stop those kind of emails Reject languages you can't read at SMTP time? I've been noticing more 'foreign language' spams that do not use a 'foreign' character set and therefore do not trigger the 'faraway' rules I don't suppose anyone has developed a generic rule that would spot 'foreign language usage in non-foreign charset'? - C
Re: Bogus Dollar Amounts
Quoting Kai Schaetzl mailli...@conactive.com: Dennis B. Hopp wrote on Wed, 24 Feb 2010 09:14:58 -0600: Obviously I have something going on with my bayes, but that's a separate issue Indeed. But it's an important issue. If it is that biased for other spam as well youa re better off to not use it in this state. X-Spam-Status: No, score=2.8 required=5.0 tests=BAYES_50,HK_MUCHMONEY, T_LOTS_OF_MONEY,UNPARSEABLE_RELAY autolearn=no version=3.3.0 add your RBL score and it's way over 5. I agree it's an important issue. I had turned off bayes autoexpire in local.cf and at some point taken the cron job out that did a manual force-expire. Once I did a force expire BAYES_60 triggered rather then BAYES_00. What is the HK_MUCHMONEY rule that you have? Is that part of the base SA installation? Thanks, --Dennis
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: Block Spammers Spoofing My Domain
schmo_j wrote: Greetings! I'm running SpamAssassin 3.2.5 on Gentoo Linux, and I'm looking to block messages from @mydomain.com that originate from outside my network. That is best/most easily done at MTA level - see the recent thread Off Topic - SPF - What a Disaster. /Per Jessen, Zürich
Re: Bogus Dollar Amounts
On 25-Feb-2010, at 05:36, Mike Cardwell wrote: I repasted that at http://spamalyser.com/v/gcrvcnbm/mime in order to get the benefit of mime parsing and decoding. running it through spamassassin -Lt I get a score of 16.6 (13.2) Content analysis details: (16.6 points, 5.0 required) pts rule name description -- -- 4.0 BAYES_99 BODY: Bayesian spam probability is 99 to 100% [score: 1.] 0.1 KB_RATWARE_OUTLOOK_16 KB_RATWARE_OUTLOOK_16 0.1 KB_RATWARE_OUTLOOK_12 KB_RATWARE_OUTLOOK_12 3.8 KB_RATWARE_BOUNDARYKB_RATWARE_BOUNDARY 0.7 SARE_RECV_IP_FROMIP3 Received line is IP address from IP address 0.7 SARE_SUB_ENC_KOI8R Subject specifies display in non-English lang 0.0 HTML_MESSAGE BODY: HTML included in message 2.2 MISSING_MIME_HB_SEPBODY: Missing blank line between MIME header and body 1.5 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS 3.4 AWLAWL: From: address is in the auto white-list -- 'There's Mr Dibbler.' 'What's he selling this time?' 'I don't think he's trying to sell anything, Mr Poons.' 'It's that bad? Then we're probably in lots of trouble.' --Reaper Man
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 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) I am open to and interested in
Block Spammers Spoofing My Domain
Greetings! I'm running SpamAssassin 3.2.5 on Gentoo Linux, and I'm looking to block messages from @mydomain.com that originate from outside my network. I already have a whitelist_from_rcvd *...@mydomain.com mydomain.com rule in place, can I simply add a blacklist_from *...@mydomain.com rule right below it to accomplish my goal? All of my mail-producing servers are inside my internal network (also defined in internal_networks), so I'm positive that nothing from @mydomain.com should come from the outside. Thanks! -- View this message in context: http://old.nabble.com/Block-Spammers-Spoofing-My-Domain-tp27714499p27714499.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Bogus Dollar Amounts
On Thu, 25 Feb 2010, Dennis B. Hopp wrote: What is the HK_MUCHMONEY rule that you have? Is that part of the base SA installation? It's a sandbox rule that got promoted. I'm working on a set of money rules that will supercede it. -- 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 --- Health Care _is_ a right - the government has no business keeping you from getting it. But forcing somebody else to pay for your health care at gunpoint (i.e. through taxation) is _not_ a right. --- 139 days since President Obama won the Nobel Not George W. Bush prize
RE: Block Spammers Spoofing My Domain
Original Message From: schmo_j [mailto:schm...@yahoo.com] Sent: Thursday, February 25, 2010 1:40 PM To: users@spamassassin.apache.org Subject: Block Spammers Spoofing My Domain Greetings! I'm running SpamAssassin 3.2.5 on Gentoo Linux, and I'm looking to block messages from @mydomain.com that originate from outside my network. I already have a whitelist_from_rcvd *...@mydomain.com mydomain.com rule in place, can I simply add a blacklist_from *...@mydomain.com rule right below it to accomplish my goal? All of my mail-producing servers are inside my internal network (also defined in internal_networks), so I'm positive that nothing from @mydomain.com should come from the outside. Thanks! -- View this message in context: http://old.nabble.com/Block-Spammers-Spoofing-My-Domain-tp27714499p27714499. html Sent from the SpamAssassin - Users mailing list archive at Nabble.com. That should really be blocked at smtp not with SA. I do it (via exim) with a list of Ips that are allowed to helo with my domain(s) and I require authentication from Any user to send mail, period. In my case if you break the helo with my name rule You are instantly added to the firewall for a week. 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
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: Block Spammers Spoofing My Domain
On Thu, Feb 25, 2010 at 1:39 PM, schmo_j schm...@yahoo.com wrote: Greetings! I'm running SpamAssassin 3.2.5 on Gentoo Linux, and I'm looking to block messages from @mydomain.com that originate from outside my network. I already have a whitelist_from_rcvd *...@mydomain.com mydomain.com rule in place, can I simply add a blacklist_from *...@mydomain.com rule right below it to accomplish my goal? All of my mail-producing servers are inside my internal network (also defined in internal_networks), so I'm positive that nothing from @mydomain.com should come from the outside. I do the following but from my MTA. I don't know if you're using Postfix or Sendmail but I have the following 'helo_checks.pcre' in my Postfix directory: /^localhost$/ 550 Don't use my own domain (localhost)! /^ideorlando.\org$/ 550 Don't use my own domain! /^216\.242\.104\.130$/ 550 Your spam was rejected because you're forging my IP. /^\[216\.242\.104\.130\]$/ 550 Your spam was rejected because you're forging my IP. /^mail\.ideorlando.\org$/ 550 Don't use my own hostname! /^[0-9.-]+$/550 Your software is not RFC 2821 compliant: EHLO/HELO must be a domain or an address-literal (IP enclosed in []) - not a naked IP. What MTA are you using?
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
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: [sa] Re: Bogus Dollar Amounts
Le 25/02/2010 17:06, Charles Gregory a écrit : On Thu, 25 Feb 2010, John Hardin wrote: i still see lot of junk mail coming with different charecters, i do not even read them clearly how can i stop those kind of emails Reject languages you can't read at SMTP time? I've been noticing more 'foreign language' spams that do not use a 'foreign' character set and therefore do not trigger the 'faraway' rules I don't suppose anyone has developed a generic rule that would spot 'foreign language usage in non-foreign charset'? Perhaps more useful - and less prone to FPs in internationally-oriented organisations - a rule that spots *mismatched* charsets, e.g. a Cyrillic charset from a Chinese IP, a Korean charset via an Italian freemail host, and so on. I guess such a rule would be possible as a meta, though an eval function might be more effective and allow more combinations. -- John
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
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
.pn TLDs not recognized for util_rb_2tld?
config: SpamAssassin failed to parse line, co.at.pn is not valid for util_rb_2tld, skipping: util_rb_2tld co.at.pn config: SpamAssassin failed to parse line, co.uk.pn is not valid for util_rb_2tld, skipping: util_rb_2tld co.uk.pn config: SpamAssassin failed to parse line, com.au.pn is not valid for util_rb_2tld, skipping: util_rb_2tld com.au.pn channel: lint check of update failed, channel failed $ dig +short 5.2.3.90_2tld.cf.sare.sa-update.dostech.net txt 201002251100 Shouldn¹t those have util_rb_3tld? -- Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: .pn TLDs not recognized for util_rb_2tld?
On 2/25/2010 11:41 PM, Daniel McDonald wrote: config: SpamAssassin failed to parse line, co.at.pn is not valid for util_rb_2tld, skipping: util_rb_2tld co.at.pn config: SpamAssassin failed to parse line, co.uk.pn is not valid for util_rb_2tld, skipping: util_rb_2tld co.uk.pn config: SpamAssassin failed to parse line, com.au.pn is not valid for util_rb_2tld, skipping: util_rb_2tld com.au.pn channel: lint check of update failed, channel failed $ dig +short 5.2.3.90_2tld.cf.sare.sa-update.dostech.net txt 201002251100 Shouldn¹t those have util_rb_3tld? thx for spotting - fixed copy/paste goof Pls allow some time for updates to be spread
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
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
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.
Off-topic? Off-list!
Sometimes I wonder, at which point in a lengthy *off-topic* discussion I
should start so slap people on the wrist, and tell 'em to go play
somewhere else and find a list where it is bloody on-topic.
A short digression every now an then of course is OK. Why not. But a
lengthy, tiresome and eventually heated off-topic discussion -- is not.
I know I'm tired from repeatedly deleting clearly off-topic posts
without even caring to open them. Wonder how the majority of subscribers
feels about it.
Please, guys, let it go. If you *know* this ain't the right place, stop
it.
guenther -- one the still-friendly list admins you all love to yell
for, when there's a mis-behaving subscriber
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
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
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
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? Off-list!
On 2/25/2010 6:26 PM, Karsten Bräckelmann wrote: Please, guys, let it go. If you *know* this ain't the right place, stop it. +1 /Jason
Re: Off-topic? Off-list!
On Thu, 25 Feb 2010, Jason Bertoch wrote: On 2/25/2010 6:26 PM, Karsten Bräckelmann wrote: Please, guys, let it go. If you *know* this ain't the right place, stop it. +1 +1 Please take it to alt.advocacy.spf.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 --- You know things are bad when Pravda says we [the USA] have gone too far to the left. -- Joe Huffman --- 139 days since President Obama won the Nobel Not George W. Bush prize
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 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
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 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
Bayes and Time of Day
Although I grasp the concept of Bayes in the SA system, I don't fully understand how and which tokens it grabs from mails passed through SA. Although many servers deal with 24-hour customers, mine is 98% business only 8AM to 5PM. Does the SA Bayes system even look at time of day for tokens? I wonder if I'd be able to more strongly scrutinize mails outside of normal business hours. Thoughts? /Jason
Re: .qmail
On Thu, Feb 25, 2010 at 2:57 AM, Toni Mueller support-spamassas...@oeko.net wrote: Hi, On Wed, 24.02.2010 at 22:18:04 -0500, alexus ale...@gmail.com wrote: On Wed, Feb 24, 2010 at 4:49 AM, Toni Mueller support-spamassas...@oeko.net wrote: On Tue, 23.02.2010 at 14:08:30 -0500, alexus ale...@gmail.com wrote: is there a way to put sa-learn --spam inside of .qmail? -bash-3.2# man preline No manual entry for preline -bash-3.2# look for the man pages included with your qmail* package. $ cat .qmail | /var/qmail/bin/preline /usr/bin/procmail Kind regards, --Toni++ -bash-3.2# man -M /var/qmail/man/ preline okay, i found man for preline... -- http://alexus.org/
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
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? Off-list!
* Jason Bertoch ja...@i6ix.com: On 2/25/2010 6:26 PM, Karsten Bräckelmann wrote: Please, guys, let it go. If you *know* this ain't the right place, stop it. +1 +1 -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563
