Re: Yahoo single link spam
On Thu, 2013-02-28 at 20:34 -0500, Steve Prior wrote: I'm really starting to suspect that these spammers are scraping your public posts on Facebook and grabbing the names of people that commented on those posts, then using a Yahoo account and setting that name on the account before sending the spam. The only issue is how do they find the legitimate email addresses of the person to send the spam to. I wouldn't be at all surprised to hear that this had something to do with a Facebook app people let have access to their account info. Thats not the only mechanism they're using. I don't use any social networking sites yet I get a small amount of spam sent via Yahoo too. In my case the forged sender has usually been presented as a member of a mailing list I subscribe to, though the last example had got my address via a virus or trojan on a friend's Windows box and somehow knew that he sends sport-related multiply addressed e-mails from time to time: the spam's subject line looked as if it was one of them and the only real giveaway was that the single line payload pushed a Romanian site when the genuine e-mails are exclusively about British topics. Martin
RE: Yahoo single link spam
Would someone put some samples of Yahoo single link spam on PasteBin. I am trying to test my rules and I seem to be missing some of the variations. Thanks, Scott -Original Message- From: Marc Perkel [mailto:supp...@junkemailfilter.com] Sent: Friday, February 22, 2013 12:20 PM To: users@spamassassin.apache.org Subject: Yahoo single link spam We need a rule to catch this. It looks like more data than it is but it's really little more than a single link. Like to see a rule that identifies it. ---262101065-1882747875-1361559395=:62570 Content-Type: text/plain; charset=us-ascii nbsp;http://www.eisingen.de/kb/m6ods3ohyayq.r34xx5y7k8rn1ycnemh Lisa Tostado, ND ---262101065-1882747875-1361559395=:62570 Content-Type: text/html; charset=us-ascii htmlbodydiv style=color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:14ptspan style=font-family: bookman old style,new york,times,serif;span style=font-size: 16px;nbsp;/span/spana href=http://www.eisingen.de/kb/m6ods3ohyayq.r34xx5y7k8rn1ycnemh;http://www.eisingen.de/kb/m6ods3ohyayq.r34xx5y7k8rn1ycnemh/abrbrLisa Tostado, NDbrdivbr/div/div/body/html ---262101065-1882747875-1361559395=:62570-- -- Marc Perkel - Sales/Support supp...@junkemailfilter.com http://www.junkemailfilter.com Junk Email Filter dot com 415-992-3400
Re: Yahoo single link spam
On Fri, 2013-03-01 at 15:38 +, Scott Ostrander wrote: Would someone put some samples of Yahoo single link spam on PasteBin. I am trying to test my rules and I seem to be missing some of the variations. Here's an example: it is the message I developed the following rule against: http://pastebin.com/VRvtDfER I've obfuscated all e-mail addresses in it and verified that my rule catches the obfuscated version. The rule is this: describe MG_YAHOO_FS Yahoo message-ID but not From: yahoo header __MG_YAHFS1 Message-id =~ /yahoo\.com$/ header __MG_YAHFS2 From =~ /yahoo\.(com|co\.uk)/ meta MG_YAHOO_FS (__MG_YAHFS1 ! __MG_YAHFS2) scoreMG_YAHOO_FS 50 as I said previously, the apparently excessive score is needed to override the score that my auto-whitelister applies to sender addresses I've previously sent mail to: so far all messages I've had of this type have had forged senders that I've previously corresponded with. Martin
Re: Yahoo single link spam
Somewhat OT... are people still seeing these Yahoo single-link spams? They seem to have stopped abruptly as far as I can tell. Regards, David.
Re: Yahoo single link spam
We don't see them as much as we used to, but they still make an appearance every once and a while. ~ Anthony - Original Message - From: David F. Skoll d...@roaringpenguin.com To: users@spamassassin.apache.org Sent: Friday, March 1, 2013 9:33:55 AM Subject: Re: Yahoo single link spam Somewhat OT... are people still seeing these Yahoo single-link spams? They seem to have stopped abruptly as far as I can tell. Regards, David.
Re: Yahoo single link spam
I saw 3 yesterday, yes. Scored 6.4 but I use a high threshold so I can view the fringe spam. On 3/1/2013 12:33 PM, David F. Skoll wrote: Somewhat OT... are people still seeing these Yahoo single-link spams? They seem to have stopped abruptly as far as I can tell. Regards, David. -- Kevin A. McGrail President Peregrine Computer Consultants Corporation 3927 Old Lee Highway, Suite 102-C Fairfax, VA 22030-2422 http://www.pccc.com/ 703-359-9700 x50 / 800-823-8402 (Toll-Free) 703-359-8451 (fax) kmcgr...@pccc.com
Yahoo single-link spam common elements
Hi,
These are the common elements as far as I can see in the text/plain part
of the spam:
1) The URL always matches this regex:
http://\S+/\S+\.\s+\?
In other words, there's always a dot in the URL (not counting the dots
in the domain name itself) and a question mark.
2) The URL is then followed by possible whitespace and the name or address
of the sender.
3) This is followed by more possible whitespace and then the date and
time in a format that matches this regex:
\d{1,2}/\d{1,2}/\d{4} \d{1,2}:\d{1,2}:\d{1,2} [AP]M
Can others confirm this pattern?
Regards,
David.
Re: Yahoo single-link spam common elements
On 3/1/2013 12:43 PM, David F. Skoll wrote:
These are the common elements as far as I can see in the text/plain part
of the spam:
1) The URL always matches this regex:
http://\S+/\S+\.\s+\?
In other words, there's always a dot in the URL (not counting the dots
in the domain name itself) and a question mark.
2) The URL is then followed by possible whitespace and the name or address
of the sender.
3) This is followed by more possible whitespace and then the date and
time in a format that matches this regex:
\d{1,2}/\d{1,2}/\d{4} \d{1,2}:\d{1,2}:\d{1,2} [AP]M
Can others confirm this pattern?
I can confirm this is ONE of the patterns we've seen but we have seen
other variations.
For example, here's one from yesterday that you'll note forges my
brother as the sender:
Return-Path: rasiel_mongad...@yahoo.com
Received: from nm7.bullet.mail.gq1.yahoo.com (nm7.bullet.mail.gq1.yahoo.com
[98.136.218.72])
by intel1.peregrinehw.com (8.14.5/8.14.5) with SMTP id r1SI2WHg008621
for kmcgr...@peregrinehw.com; Thu, 28 Feb 2013 13:02:33 -0500
Received: from [98.137.12.61] by nm7.bullet.mail.gq1.yahoo.com with NNFMP; 28
Feb 2013 18:02:31 -
Received: from [208.71.42.212] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 28
Feb 2013 18:02:31 -
Received: from [127.0.0.1] by smtp223.mail.gq1.yahoo.com with NNFMP; 28 Feb
2013 18:02:31 -
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
t=1362074551; bh=O2aFzcTOvDvCQALZoONOlZmCJiqlFu6WnhUAJG1clGI=;
h=X-Yahoo-Newman-Id:Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:Reply-To:Subject:Date:To;
b=5sIC6wpAChfKFdhlWmr4OhjWCpNoMhTdxsbWPAIXYyD3f+O4QKMatwXxL7uvHeFc5TD//q4hW0HQDVJ+f/XJq71XHuBeWLySuYceP9ZP5gMRMnAR8uM9o9rWw0vnwSd7+3H3ff1rCd2FunGswYwlNAG5yz79uYE7xe+sXw5qs3c=
X-Yahoo-Newman-Id: 533489.47072...@smtp223.mail.gq1.yahoo.com
Message-ID: 533489.47072...@smtp223.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: jRlM9PUVM1m1fvPhWPzSnQEReLcFyK.eiCoVEK16XkMJTsp
FUuOvETyd8ee4KmT2FuoE1n9krae3pEbGP2MbvtNXR6sdYnhJIxvfdiuEtob
wr1ipSssPLDugG_B3KfoWpLJZs0YjG5TMqqVzDGih3D11pGQfAY6w.mgoOWY
Vemeo4DqHYY8XYokWdUpIh65s1dDZlNaYvlqfF1MZudo2pV6wlPm_rMDWHvP
DNawGoHaZr3qyELnp7ElYqt8BCCs0hushH3dTtn.mVpUMrTv3GzPnkMMGCvR
O9U8mO_UIFwTMrWvkkzLcMKqdKdukq8.cPSh8VY5TRg_Xih7mDsVxksEIVcE
OCOEMbBw9uApP4oRpc.pBlu9eDntaPpiUUPhpb9xxkQw4lcLJkx0RTt0GYD3
uAMLNtukwnvce54PkLZl3JrIDGhvQuhKnZxYyRsne49aNjP11_3wZUo8wlvg
guHiLuHcqkFb6lusTYz41fCHrSJ6VTYxwqlQcA0DioWPWPDZmkjLtrc2aER1
MbKjYki6ceeLXQT21DGdb9Gui.eE43RA2Ix6qqTYRddM-
X-Yahoo-SMTP: bHYtILuswBDzs9L.FhYpFEHr7NQ0kndD9GjKbx8-
Received: from localhost (rasiel_mongado29@200.121.59.161 with login)
by smtp223.mail.gq1.yahoo.com with SMTP; 28 Feb 2013 10:02:31 -0800 PST
From: TOBY MCGRAIL rasiel_mongad...@yahoo.com
Reply-To: TOBY MCGRAIL tvfdkmn...@yahoo.com
Subject: KEVIN
Date: Thu, 28 Feb 2013 10:05:47 -0800 (PST)
To: Kevin kmcgr...@peregrinehw.com
kevin, hey. look what I found!
http://www.deguciumd-munged.lt/answerbabykevingreen/
regards,
KAM
Re: Yahoo single link spam
On Fri, 2013-03-01 at 12:33 -0500, David F. Skoll wrote: Somewhat OT... are people still seeing these Yahoo single-link spams? They seem to have stopped abruptly as far as I can tell. I haven't seen one for a few days either, but think its still a useful rule because it can't cost a lot to run and, in the past anyway, Yahoo has been quite a common spam vector. Martin
Rule to check To and/or CC headers
Hey All, I'm just starting to dive into advanced custom SA rules, so forgive me if this is a silly question. Is it possible to construct a rule that looks at the To and/or CC field and compares it to the recipient? I know this can be dangerous as legitimate email can be BCCed, but I think being able to use this to add just a teeny bit to the spam score will help complement some of our current rules. Thanks! ~ Anthony Anthony Hoppe IS Support Technician II Menlo Park City School District (650) 321-7140 ext. 5272 aho...@mpcsd.org
Re: Yahoo single link spam
On 01/03/13 17:33, David F. Skoll wrote: Somewhat OT... are people still seeing these Yahoo single-link spams? They seem to have stopped abruptly as far as I can tell. Regards, David. Here's one from this morning: http://pastebin.com/cuk595z6 that matches the pattern being discussed.
Re: Rule to check To and/or CC headers
Hello, There is no silly question. Just noobs. FYI: most of the time, I'm a noob. I do not understand your question: To or Cc headers are recipients. Do you want to compare the name portion to the address portion? eg: To: Alex Boyer a...@example.com If Alex matches the local part in the address, then it's OK? else it's not? This would be a bad idea. Whatever... the important thing is : if you want to compare with SA, you have to write a plugin. There is no way one can compare, say, a signature in the body and the ToCc headers without a module. Or if there is a way, I am willing to learn it! Alex, from prypiat. Yes, I recycle. On 13-03-01 01:48 PM, Anthony Hoppe wrote: Hey All, I'm just starting to dive into advanced custom SA rules, so forgive me if this is a silly question. Is it possible to construct a rule that looks at the To and/or CC field and compares it to the recipient? I know this can be dangerous as legitimate email can be BCCed, but I think being able to use this to add just a teeny bit to the spam score will help complement some of our current rules. Thanks! ~ Anthony Anthony Hoppe IS Support Technician II Menlo Park City School District (650) 321-7140 ext. 5272 aho...@mpcsd.org signature.asc Description: OpenPGP digital signature
Re: Rule to check To and/or CC headers
On 3/1/2013 11:26, Alexandre Boyer wrote: There is no silly question. Just noobs. FYI: most of the time, I'm a noob. I do not understand your question: To or Cc headers are recipients. Do you want to compare the name portion to the address portion? eg: To: Alex Boyer a...@example.com If Alex matches the local part in the address, then it's OK? else it's not? This would be a bad idea. Whatever... the important thing is : if you want to compare with SA, you have to write a plugin. There is no way one can compare, say, a signature in the body and the ToCc headers without a module. Or if there is a way, I am willing to learn it! I suspect he wants to check to see if the RCPT TO (the actual recipient) is named in the TO or CC headers, and score based on this decision. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
Re: Yahoo single-link spam common elements
Right: the suggested pattern is working great, but there are some
variants as KAM says.
However I sense that these are not the same bots. The one with the date
in body is always the same (the spammer only changed the date format).
I heard about a cross site botnet exploit on Yahoo! and third party
website, but did not digged into that.
Here is what is working fine for me:
body __AJB_DATE_IN_BODY
m'\d{1,2}/\d{1,2}/\d{4}\s(\d{1,2}:){2}\d{2} [AP]M'
uri __AJB_RANDOMURI
m'/[a-z]{2,10}/[a-z1-9]{1,30}(\.[a-z1-9]{1,10}\?[a-z1-9]{1,30}|[\=\][a-z1-9]{1,30})'
metaAJB_YAHOO_BOT AJB_REALYAHOO HTML_MESSAGE
__AJB_DATE_IN_BODY __AJB_RANDOMURI
score AJB_YAHOO_BOT 10.0
meta AJB_REALYAHOO __AJB_FROM_YAHOO __RCVD_YAHOO
header __AJB_FROM_YAHOO From:addr =~ /\@yahoo\.c(a|om)/i
header __RCVD_YAHOO Received =~ m'\.yahoo\.c(a|om) .+ by
\S+\.zerospam\.ca'm
Pretty the same as what David suggests :-)
Also noticed that the To:, Reply-To: headers and the name in the
signature in the body matches. Wanted to code a plugin but the previous
rules are doing the job so...
Alex, from prypiat.
Yes, I recycle.
On 13-03-01 12:49 PM, Kevin A. McGrail wrote:
On 3/1/2013 12:43 PM, David F. Skoll wrote:
These are the common elements as far as I can see in the text/plain part
of the spam:
1) The URL always matches this regex:
http://\S+/\S+\.\s+\?
In other words, there's always a dot in the URL (not counting the dots
in the domain name itself) and a question mark.
2) The URL is then followed by possible whitespace and the name or
address
of the sender.
3) This is followed by more possible whitespace and then the date and
time in a format that matches this regex:
\d{1,2}/\d{1,2}/\d{4} \d{1,2}:\d{1,2}:\d{1,2} [AP]M
Can others confirm this pattern?
I can confirm this is ONE of the patterns we've seen but we have seen
other variations.
For example, here's one from yesterday that you'll note forges my
brother as the sender:
Return-Path: rasiel_mongad...@yahoo.com
Received: from nm7.bullet.mail.gq1.yahoo.com
(nm7.bullet.mail.gq1.yahoo.com [98.136.218.72])
by intel1.peregrinehw.com (8.14.5/8.14.5) with SMTP id r1SI2WHg008621
for kmcgr...@peregrinehw.com; Thu, 28 Feb 2013 13:02:33 -0500
Received: from [98.137.12.61] by nm7.bullet.mail.gq1.yahoo.com with
NNFMP; 28 Feb 2013 18:02:31 -
Received: from [208.71.42.212] by tm6.bullet.mail.gq1.yahoo.com with
NNFMP; 28 Feb 2013 18:02:31 -
Received: from [127.0.0.1] by smtp223.mail.gq1.yahoo.com with NNFMP;
28 Feb 2013 18:02:31 -
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com;
s=s1024; t=1362074551;
bh=O2aFzcTOvDvCQALZoONOlZmCJiqlFu6WnhUAJG1clGI=;
h=X-Yahoo-Newman-Id:Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:Reply-To:Subject:Date:To;
b=5sIC6wpAChfKFdhlWmr4OhjWCpNoMhTdxsbWPAIXYyD3f+O4QKMatwXxL7uvHeFc5TD//q4hW0HQDVJ+f/XJq71XHuBeWLySuYceP9ZP5gMRMnAR8uM9o9rWw0vnwSd7+3H3ff1rCd2FunGswYwlNAG5yz79uYE7xe+sXw5qs3c=
X-Yahoo-Newman-Id: 533489.47072...@smtp223.mail.gq1.yahoo.com
Message-ID: 533489.47072...@smtp223.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: jRlM9PUVM1m1fvPhWPzSnQEReLcFyK.eiCoVEK16XkMJTsp
FUuOvETyd8ee4KmT2FuoE1n9krae3pEbGP2MbvtNXR6sdYnhJIxvfdiuEtob
wr1ipSssPLDugG_B3KfoWpLJZs0YjG5TMqqVzDGih3D11pGQfAY6w.mgoOWY
Vemeo4DqHYY8XYokWdUpIh65s1dDZlNaYvlqfF1MZudo2pV6wlPm_rMDWHvP
DNawGoHaZr3qyELnp7ElYqt8BCCs0hushH3dTtn.mVpUMrTv3GzPnkMMGCvR
O9U8mO_UIFwTMrWvkkzLcMKqdKdukq8.cPSh8VY5TRg_Xih7mDsVxksEIVcE
OCOEMbBw9uApP4oRpc.pBlu9eDntaPpiUUPhpb9xxkQw4lcLJkx0RTt0GYD3
uAMLNtukwnvce54PkLZl3JrIDGhvQuhKnZxYyRsne49aNjP11_3wZUo8wlvg
guHiLuHcqkFb6lusTYz41fCHrSJ6VTYxwqlQcA0DioWPWPDZmkjLtrc2aER1
MbKjYki6ceeLXQT21DGdb9Gui.eE43RA2Ix6qqTYRddM-
X-Yahoo-SMTP: bHYtILuswBDzs9L.FhYpFEHr7NQ0kndD9GjKbx8-
Received: from localhost (rasiel_mongado29@200.121.59.161 with login)
by smtp223.mail.gq1.yahoo.com with SMTP; 28 Feb 2013 10:02:31
-0800 PST
From: TOBY MCGRAIL rasiel_mongad...@yahoo.com
Reply-To: TOBY MCGRAIL tvfdkmn...@yahoo.com
Subject: KEVIN
Date: Thu, 28 Feb 2013 10:05:47 -0800 (PST)
To: Kevin kmcgr...@peregrinehw.com
kevin, hey. look what I found!
http://www.deguciumd-munged.lt/answerbabykevingreen/
regards,
KAM
signature.asc
Description: OpenPGP digital signature
Re: Yahoo single-link spam common elements
On Fri, 01 Mar 2013 14:39:09 -0500
Alexandre Boyer bigg...@gmail.com wrote:
Pretty the same as what David suggests :-)
My latest attempt is this:
header __RP_D_00040_1 From:addr =~ /yahoo/i
header __RP_D_00040_2 To =~ /(:?@.*?){5}/
body __RP_D_00040_3 /http.{0,200}\d{1,2}:\d{1,2}:\d{1,2}/
meta RP_D_00040 __RP_D_00040_1 __RP_D_00040_2 __RP_D_00040_3
describe RP_D_00040 Yahoo single-line URL spam
I'm a little worried about potential FPs, but we'll see how it goes.
Regards,
David.
Re: Rule to check To and/or CC headers
Yes! That's exactly it. Another thing I'd like to do, if possible, is check to see if the From address matches the return path and add to the spam score if they do not match. I know they won't match completely in some cases, but a way to check if the same pattern, u...@domain.com exists both in the Return Path AND the From field. Anthony Hoppe IS Support Technician II Menlo Park City School District (650) 321-7140 ext. 5272 aho...@mpcsd.org - Original Message - From: Dave Warren li...@hireahit.com To: users@spamassassin.apache.org Sent: Friday, March 1, 2013 11:38:30 AM Subject: Re: Rule to check To and/or CC headers On 3/1/2013 11:26, Alexandre Boyer wrote: There is no silly question. Just noobs. FYI: most of the time, I'm a noob. I do not understand your question: To or Cc headers are recipients. Do you want to compare the name portion to the address portion? eg: To: Alex Boyer a...@example.com If Alex matches the local part in the address, then it's OK? else it's not? This would be a bad idea. Whatever... the important thing is : if you want to compare with SA, you have to write a plugin. There is no way one can compare, say, a signature in the body and the ToCc headers without a module. Or if there is a way, I am willing to learn it! I suspect he wants to check to see if the RCPT TO (the actual recipient) is named in the TO or CC headers, and score based on this decision. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
Re: Rule to check To and/or CC headers
Okey... Didn't catch that. Not a bad idea but cannot be a decision making thing. And need a plugin. I thought about that already but didn't had time to code this. And I don't remember who on this list brang objections that it would not be such a good idea. Plus: SA do not have access to SMTP infos. That a pitty, but you can't have the real thing, you rely on headers. Alex, from prypiat. Yes, I recycle. On 13-03-01 02:38 PM, Dave Warren wrote: On 3/1/2013 11:26, Alexandre Boyer wrote: There is no silly question. Just noobs. FYI: most of the time, I'm a noob. I do not understand your question: To or Cc headers are recipients. Do you want to compare the name portion to the address portion? eg: To: Alex Boyer a...@example.com If Alex matches the local part in the address, then it's OK? else it's not? This would be a bad idea. Whatever... the important thing is : if you want to compare with SA, you have to write a plugin. There is no way one can compare, say, a signature in the body and the ToCc headers without a module. Or if there is a way, I am willing to learn it! I suspect he wants to check to see if the RCPT TO (the actual recipient) is named in the TO or CC headers, and score based on this decision. signature.asc Description: OpenPGP digital signature
Re: Yahoo single-link spam common elements
The famous 5 recipients...
I had a (very) few exceptions while having the very same pattern in
body. With 4 recipients instead of 5, and sometimes one among the 5 with
no To:address, just To:name, wich was harder to count...
I removed the similar rule as your __RP_D_00040 from my systems to avoid
false negatives.
And no FP for a long time on this rule (this is an old bot, first saw
last summer, but probably older but unnoticed).
Alex, from prypiat.
Yes, I recycle.
On 13-03-01 02:45 PM, David F. Skoll wrote:
On Fri, 01 Mar 2013 14:39:09 -0500
Alexandre Boyer bigg...@gmail.com wrote:
Pretty the same as what David suggests :-)
My latest attempt is this:
header __RP_D_00040_1 From:addr =~ /yahoo/i
header __RP_D_00040_2 To =~ /(:?@.*?){5}/
body __RP_D_00040_3 /http.{0,200}\d{1,2}:\d{1,2}:\d{1,2}/
meta RP_D_00040 __RP_D_00040_1 __RP_D_00040_2 __RP_D_00040_3
describe RP_D_00040 Yahoo single-line URL spam
I'm a little worried about potential FPs, but we'll see how it goes.
Regards,
David.
signature.asc
Description: OpenPGP digital signature
Re: Rule to check To and/or CC headers
Another thing I'd like to do, if possible, is check to see if the From address matches the return path and add to the spam score if they do not match. The inverse rule is already there (just use a meta rule negation of it): header RP_MATCHES_RCVD eval:check_mailfrom_matches_rcvd() describe RP_MATCHES_RCVD Envelope sender domain matches handover relay domain tflags RP_MATCHES_RCVD nice scoreRP_MATCHES_RCVD -0.551 -0.703 -0.551 -0.703 I know they won't match completely in some cases, The From and envelope sender address do not match in many cases - like in almost all mailing list traffic. A mismatch is not worth more than a small fraction of a score point. Same applies to a mismatch between To/Cc and the envelope recipient address: these never match in mail from mailing lists. Mark
NJABL is history
As per: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6913 Just got the bad news: Please spread the word. NJABL has to be shut down effective immediately. I just emptied the dnsbl zone files. My expectation is that the servers will be allowed to run for some time so the shutdown can be graceful, but I probably won't have control over that and can make no guarantees. Rules will be disabled/updated asap. IMPOrTANT: Please make sure to remove njabl.org entries from your MTA's configuration if you have it. Sorry for the bad news. Axb
Re: NJABL is history
On 3/1/2013 6:14 PM, Kevin A. McGrail wrote: score RCVD_IN_NJABL_CGI 0 score RCVD_IN_NJABL_MULTI 0 score RCVD_IN_NJABL_PROXY 0 score RCVD_IN_NJABL_RELAY 0 score RCVD_IN_NJABL_SPAM 0 And score __RCVD_IN_NJABL 0 just in case...
Re: NJABL is history
On 03/02/2013 12:25 AM, Kevin A. McGrail wrote: On 3/1/2013 6:14 PM, Kevin A. McGrail wrote: score RCVD_IN_NJABL_CGI 0 score RCVD_IN_NJABL_MULTI 0 score RCVD_IN_NJABL_PROXY 0 score RCVD_IN_NJABL_RELAY 0 score RCVD_IN_NJABL_SPAM 0 And score __RCVD_IN_NJABL 0 just in case... If you're using SA 3.4 trunk: as temporary entry in local.cf # ONLY FOR SA 3.4 or higher!! dns_query_restriction deny njabl.org
Re: NJABL is history
On 03/01/2013 11:52 PM, Axb wrote: As per: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6913 Just got the bad news: Please spread the word. NJABL has to be shut down effective immediately. I just emptied the dnsbl zone files. My expectation is that the servers will be allowed to run for some time so the shutdown can be graceful, but I probably won't have control over that and can make no guarantees. Rules will be disabled/updated asap. IMPORTANT: Please make sure to remove njabl.org entries from your MTA's configuration if you have it. Sorry for the bad news. Njabl.org rules should be disabled by sa-update on 2013-03-03. To avoid suprises, please check your systems after next update. Axb
Re: NJABL is history
Axb wrote: If you're using SA 3.4 trunk: as temporary entry in local.cf # ONLY FOR SA 3.4 or higher!! dns_query_restriction deny njabl.org Thanks for reminding us of the new feature! Wrapped up in a conditional, for those wishing to switch between versions while keeping the same .cf file: # Bug 6913, 2013-03-01, NJABL has to be shut down effective immediately if can(Mail::SpamAssassin::Conf::feature_dns_query_restriction) dns_query_restriction deny njabl.org endif Mark
Re: Yahoo single-link spam common elements
On 01/03/13 19:55, Alexandre Boyer wrote:
The famous 5 recipients...
I had a (very) few exceptions while having the very same pattern in
body. With 4 recipients instead of 5, and sometimes one among the 5 with
no To:address, just To:name, wich was harder to count...
I removed the similar rule as your __RP_D_00040 from my systems to avoid
false negatives.
And no FP for a long time on this rule (this is an old bot, first saw
last summer, but probably older but unnoticed).
The example I posted earlier today had 7 recipients listed in To:
(sorry, I redacted them).
Rather than using a rule specifically for 5 recipients, I would use the
existing __MANY_RECIPS rule in the meta rule.
That said, I just checked my example, and __MANY_RECIPS failed to fire.
Here's the current rule:
header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
Can someone explain the regex and why it fails to fire for 7 recipients?
Re: Yahoo single-link spam common elements
Ned Slider skrev den 2013-03-02 02:11:
header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
Can someone explain the regex and why it fails to fire for 7
recipients?
as i read it, it fires if there is more then 4 domains, not only 5
recipients, just a wild guess from me since i am not good at perl yet
Re: Yahoo single-link spam common elements
In an older episode, on 2013-03-02 02:19, Benny Pedersen wrote:
Ned Slider skrev den 2013-03-02 02:11:
header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
Can someone explain the regex and why it fails to fire for 7 recipients?
as i read it, it fires if there is more then 4 domains, not only 5
recipients, just a wild guess from me since i am not good at perl yet
At least 3 domains rather. IMHO, the regexp means:
{3} repetitions of (@ followed by 5 to 30 characters that are _not_ @)
Hope this helps.
Cheers,
wolfgang
Re: NJABL is history
On 3/1/2013 5:52 PM, Axb wrote: Please spread the word. NJABL has to be shut down effective immediately. I just emptied the dnsbl zone files. I'm assuming this means their feed into Zen and XBL has shut down, too? If I'm wrong and that feed still exists, (anyone who knows...) please reply to this post with that clarification. (would be interesting to know) (actually, while NJABL was a great list, I found their listings that didn't feed into SpamHaus to be the most valuable CBL was already doing the heavy lifting for XBL. Many of us will especially miss NJABL's OTHER non-XBL-related listings!!) -- Rob McEwen http://dnsbl.invaluement.com/ r...@invaluement.com +1 (478) 475-9032
Re: Yahoo single-link spam common elements
On Sat, 2 Mar 2013, Ned Slider wrote:
On 01/03/13 19:55, Alexandre Boyer wrote:
The famous 5 recipients...
I had a (very) few exceptions while having the very same pattern in
body. With 4 recipients instead of 5, and sometimes one among the 5 with
no To:address, just To:name, wich was harder to count...
I removed the similar rule as your __RP_D_00040 from my systems to avoid
false negatives.
And no FP for a long time on this rule (this is an old bot, first saw
last summer, but probably older but unnoticed).
The example I posted earlier today had 7 recipients listed in To: (sorry, I
redacted them).
Rather than using a rule specifically for 5 recipients, I would use the
existing __MANY_RECIPS rule in the meta rule.
That said, I just checked my example, and __MANY_RECIPS failed to fire.
Here's the current rule:
header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
Can someone explain the regex and why it fails to fire for 7 recipients?
(@, followed by 5-30 non-@ characters) repeated three times.
If the username + domain name + inter-address punctuation is longer than
30 chars it won't work.
I don't see a good reason for the upper limit, or at least for one that
restrictive. The To and Cc headers aren't going to be unboundedly long.
--
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
---
USMC Rules of Gunfighting #6: If you can choose what to bring to a
gunfight, bring a long gun and a friend with a long gun.
---
12 days until Albert Einstein's 134th Birthday
Re: Yahoo single-link spam common elements
On Sat, 2013-03-02 at 01:11 +, Ned Slider wrote:
That said, I just checked my example, and __MANY_RECIPS failed to fire.
Here's the current rule:
header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
Can someone explain the regex and why it fails to fire for 7 recipients?
Is the limit of 30 ^@ characters enough?
Martin
Re: Yahoo single-link spam common elements
On 02/03/13 01:40, John Hardin wrote:
On Sat, 2 Mar 2013, Ned Slider wrote:
On 01/03/13 19:55, Alexandre Boyer wrote:
The famous 5 recipients...
I had a (very) few exceptions while having the very same pattern in
body. With 4 recipients instead of 5, and sometimes one among the 5
with
no To:address, just To:name, wich was harder to count...
I removed the similar rule as your __RP_D_00040 from my systems to
avoid
false negatives.
And no FP for a long time on this rule (this is an old bot, first saw
last summer, but probably older but unnoticed).
The example I posted earlier today had 7 recipients listed in To:
(sorry, I redacted them).
Rather than using a rule specifically for 5 recipients, I would use
the existing __MANY_RECIPS rule in the meta rule.
That said, I just checked my example, and __MANY_RECIPS failed to
fire. Here's the current rule:
header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
Can someone explain the regex and why it fails to fire for 7 recipients?
(@, followed by 5-30 non-@ characters) repeated three times.
If the username + domain name + inter-address punctuation is longer than
30 chars it won't work.
I don't see a good reason for the upper limit, or at least for one that
restrictive. The To and Cc headers aren't going to be unboundedly long.
Thanks John (and others).
Yes, the limit of 30 looks too small. I just created a local rule upping
the limit to 100 and it now fires as expected.
John - can we increase the limit?
Re: Yahoo single-link spam common elements
In an older episode, on 2013-03-02 02:40, John Hardin wrote:
header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
Can someone explain the regex and why it fails to fire for 7 recipients?
(@, followed by 5-30 non-@ characters) repeated three times.
Does that mean the same sequence of (@, followed by 5-30 non-@
characters), repeated 3 times?
I wasn't sure about that earlier.
Regards,
wolfgang
Re: Yahoo single-link spam common elements
On Sat, 2 Mar 2013, Wolfgang Zeikat wrote:
In an older episode, on 2013-03-02 02:40, John Hardin wrote:
header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
Can someone explain the regex and why it fails to fire for 7 recipients?
(@, followed by 5-30 non-@ characters) repeated three times.
Does that mean the same sequence of (@, followed by 5-30 non-@ characters),
repeated 3 times?
The *same* sequence, no. Matching a repeating specific sequence would
involve capturing the match (using parens without the ?:) and
backreferences to refer to the capruted match later in the RE; it would
look something like:
/(\@[^@]{5,30})\1{2}/
--
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
---
So Microsoft's invented the ASCII equivalent to ugly ink spots that
appear on your letter when your pen is malfunctioning.
-- Greg Andrews, about Microsoft's way to encode apostrophes
---
12 days until Albert Einstein's 134th Birthday
Re: Yahoo single-link spam common elements
On Sat, 2 Mar 2013, Ned Slider wrote:
On 02/03/13 01:40, John Hardin wrote:
On Sat, 2 Mar 2013, Ned Slider wrote:
header __MANY_RECIPS ToCc =~ /(?:\@[^@]{5,30}){3}/
Can someone explain the regex and why it fails to fire for 7 recipients?
If the username + domain name + inter-address punctuation is longer than
30 chars it won't work.
I don't see a good reason for the upper limit, or at least for one that
restrictive. The To and Cc headers aren't going to be unboundedly long.
Thanks John (and others).
Yes, the limit of 30 looks too small. I just created a local rule upping the
limit to 100 and it now fires as expected.
John - can we increase the limit?
Upped to 100. I was going to suggest something smaller, but realized that
includes the user-visible-name part. 100 may not be enough given things
like encoded UTF-8 display names, but this will improve things.
--
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
---
So Microsoft's invented the ASCII equivalent to ugly ink spots that
appear on your letter when your pen is malfunctioning.
-- Greg Andrews, about Microsoft's way to encode apostrophes
---
12 days until Albert Einstein's 134th Birthday
Re: NJABL is history
I'm assuming this means their feed into Zen and XBL has shut down, too? If I'm wrong and that feed still exists, (anyone who knows...) please reply to this post with that clarification. (would be interesting to know) The whole thing is kaput. The guy who was running it has a new job, there was nobody left to run it.
