Re: rule for repeated tracking numbers

On 08/07/2014 07:01 AM, Philip Prindeville wrote: On Aug 6, 2014, at 1:23 PM, Paul Stead wrote: On 06/08/14 20:00, John Hardin wrote: Can some fresh samples be posted to pastebin? http://pastebin.com/yHiT2s3t http://pastebin.com/DpxpJhtA http://pastebin.com/DYx1ap31 :) Uh… the hostnam

Re: Missing rules

On Aug 6, 2014, at 3:24 PM, James B. Byrne wrote: > > On Wed, August 6, 2014 16:27, Kevin A. McGrail wrote: >> >>> >> >> MSPIKE = MailSpike RBL. >> >> Without checking, you are running an old version of SA and the rules are >> not valid on your installation so it's skipping them. It's inno

Re: rule for repeated tracking numbers

On Aug 6, 2014, at 1:23 PM, Paul Stead wrote: > > On 06/08/14 20:00, John Hardin wrote: >> Can some fresh samples be posted to pastebin? >> > http://pastebin.com/yHiT2s3t > http://pastebin.com/DpxpJhtA > http://pastebin.com/DYx1ap31 > > :) Uh… the hostname in all of these URL’s always resol

Re: Missing rules

James B. Byrne wrote: > I am constrained to run the version provided by the upstream distro packager > (RedHat). When they update SA then, and only then, will I get the upgrade. If Red Hat is like other packagers then they are depending upon sa-update to populate /var/lib/spamassassin/ with updat

Re: events log - how to view

Kevin A. McGrail wrote > On 8/6/2014 8:24 PM, RobertGrimes wrote: >> I have a script and am trying to debug it. A file in the log folder has >> been >> created called hmailserver_events.log. However it is a binary file. How >> am I >> supposed to read it? > > That would really be a question for hm

Re: Missing rules

On 8/6/2014 5:24 PM, James B. Byrne wrote: On Wed, August 6, 2014 16:27, Kevin A. McGrail wrote: MSPIKE = MailSpike RBL. Without checking, you are running an old version of SA and the rules are not valid on your installation so it's skipping them. It's innocuous and by design that you are skip

Re: events log - how to view

On 8/6/2014 8:24 PM, RobertGrimes wrote: I have a script and am trying to debug it. A file in the log folder has been created called hmailserver_events.log. However it is a binary file. How am I supposed to read it? That would really be a question for hmailserver support. Perhaps it's in Micr

events log - how to view

I have a script and am trying to debug it. A file in the log folder has been created called hmailserver_events.log. However it is a binary file. How am I supposed to read it? -- View this message in context: http://spamassassin.1065346.n5.nabble.com/events-log-how-to-view-tp110800.html Sent fro

Re: rule for repeated tracking numbers

On Wed, 6 Aug 2014, Paul Stead wrote: On 06/08/14 20:00, John Hardin wrote: Can some fresh samples be posted to pastebin? http: //pastebin.com/yHiT2s3t http: //pastebin.com/DpxpJhtA http: //pastebin.com/DYx1ap31 :) Thanks. They've substantially reduced the number of repetitions since fi

Re: rule for repeated tracking numbers

On Aug 6, 2014, at 2:00 PM, Axb wrote: > Suggest you use a local DNS resolver instead of some third party which is > getting in your way. Good idea. I installed unbound, and configured it to not use Google’s nameservers (which were the ones that were blocked). Now uribl seems to be working.

Re: Missing rules

On 08/06/2014 11:24 PM, James B. Byrne wrote: I am constrained to run the version provided by the upstream distro packager (RedHat). When they update SA then, and only then, will I get the upgrade. as a wise man named Benny Pedersen once said: "you live in a precompiled problem" SCR

Re: Missing rules

--On Wednesday, August 06, 2014 6:24 PM -0400 "James B. Byrne" wrote: I am constrained to run the version provided by the upstream distro packager (RedHat). When they update SA then, and only then, will I get the upgrade. Policies such as this show a complete lack of understanding on how to

Re: Missing rules

On Wed, August 6, 2014 16:27, Kevin A. McGrail wrote: > >> > > MSPIKE = MailSpike RBL. > > Without checking, you are running an old version of SA and the rules are > not valid on your installation so it's skipping them. It's innocuous > and by design that you are skipping those rules. Upgrading t

Re: rule for repeated tracking numbers

On 08/06/2014 10:32 PM, Andy Balholm wrote: On Aug 6, 2014, at 12:00 PM, John Hardin wrote: Can some fresh samples be posted to pastebin? http://pastebin.com/DWiTYmPN is my complete collection of 24 spams with this pattern received this week. Collect them all! You're getting X-Spam-Re

Re: rule for repeated tracking numbers

On 08/06/2014 10:34 PM, Paul Stead wrote: On 06/08/14 21:03, Axb wrote: the unmunged Msg-ID and the num code in the From: (which is also a nice trait) .-) How would you test for such a trait? Where the same num code appears throughout the email in specific places? I guess this is plugin terri

Re: rule for repeated tracking numbers

On 06/08/14 21:03, Axb wrote: the unmunged Msg-ID and the num code in the From: (which is also a nice trait) .-) How would you test for such a trait? Where the same num code appears throughout the email in specific places? I guess this is plugin territory? -- Paul Stead Systems Engineer Zen

Re: rule for repeated tracking numbers

On Aug 6, 2014, at 12:00 PM, John Hardin wrote: > Can some fresh samples be posted to pastebin? http://pastebin.com/DWiTYmPN is my complete collection of 24 spams with this pattern received this week. Collect them all!

Re: rule for repeated tracking numbers

On 08/06/2014 10:17 PM, Paul Stead wrote: Assuming I didn't change those too :) Guess what the MD5 of redac...@example.com is? On 06/08/14 21:03, Axb wrote: btw.. you munged rcpt, but the spammer confirmed or listwashed you using the unmunged Msg-ID and the num code

Re: Missing rules

On 8/6/2014 4:19 PM, James B. Byrne wrote: OS=CentOS-6.5 SA=3.3.1 I ran spamassassin -D -llint and see this in the output: Aug 6 15:59:03.983 [4533] dbg: config: warning: score set for non-existent rule RCVD_IN_MSPIKE_H4 Aug 6 15:59:03.983 [4533] dbg: config: warning: score set for non-existe

Missing rules

OS=CentOS-6.5 SA=3.3.1 I ran spamassassin -D -llint and see this in the output: Aug 6 15:59:03.983 [4533] dbg: config: warning: score set for non-existent rule RCVD_IN_MSPIKE_H4 Aug 6 15:59:03.983 [4533] dbg: config: warning: score set for non-existent rule RCVD_IN_MSPIKE_WL Aug 6 15:59:03.983

Re: rule for repeated tracking numbers

Assuming I didn't change those too :) Guess what the MD5 of redac...@example.com is? On 06/08/14 21:03, Axb wrote: btw.. you munged rcpt, but the spammer confirmed or listwashed you using the unmunged Msg-ID and the num code in the From: (which is also a nice trait)

Re: rule for repeated tracking numbers

On 08/06/2014 09:23 PM, Paul Stead wrote: On 06/08/14 20:00, John Hardin wrote: Can some fresh samples be posted to pastebin? http://pastebin.com/yHiT2s3t http://pastebin.com/DpxpJhtA http://pastebin.com/DYx1ap31 btw.. you munged rcpt, but the spammer confirmed or listwashed you using the

Re: rule for repeated tracking numbers

On 08/06/2014 09:23 PM, Paul Stead wrote: On 06/08/14 20:00, John Hardin wrote: Can some fresh samples be posted to pastebin? http://pastebin.com/yHiT2s3t http://pastebin.com/DpxpJhtA http://pastebin.com/DYx1ap31 a simple URI rule gets rid of this type without headbanging RE

Re: rule for repeated tracking numbers

On 06/08/14 20:00, John Hardin wrote: Can some fresh samples be posted to pastebin? http://pastebin.com/yHiT2s3t http://pastebin.com/DpxpJhtA http://pastebin.com/DYx1ap31 :) -- Paul Stead Systems Engineer Zen Internet

Re: rule for repeated tracking numbers

On Tue, 5 Aug 2014, Andy Balholm wrote: On Aug 5, 2014, at 11:16 AM, John Hardin wrote: It can hit on embedded phone numbers, which are, strictly speaking, valid hexadecimal strings... I suspect it's hitting on all those dates as well, and needs some more tightening. In the spams I’m loo

Re: rule for repeated tracking numbers

On 06/08/14 19:50, Paul Stead wrote: body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32}) .{1,250}[\g1].{1,250}\g2/ Hmmm.. line breakage... \s instead of spaces? body __LOC_DIGITS_CONFUSER /\s(\d{7,8})\s.{1,250}\s([0-9a-f]{32})\s.{1,250}\g1.{1,250}\g2/ Note that \g denotes a previous

Re: rule for repeated tracking numbers

On 06/08/14 19:39, Alex wrote: body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32}) .{1,250}[\g1|\g2] .{1,250}[\g1|\g2]/ This doesn't pass lint: Oops! copy/pasta fail to the max - I noticed this didn't work previously - the following is correct body __LOC_DIGITS_CONFUSER / (\d{7,8})

Re: rule for repeated tracking numbers

On 8/6/2014 2:39 PM, Alex wrote: On Wed, Aug 6, 2014 at 1:32 PM, Paul Stead mailto:paul.st...@zeninternet.co.uk>> wrote: 06/08/14 16:28, Quanah Gibson-Mount wrote: Would you be willing to share your full finalized ruleset? This spam is really obnoxious. Sure... A lit

Re: rule for repeated tracking numbers

On Wed, Aug 6, 2014 at 1:32 PM, Paul Stead wrote: > 06/08/14 16:28, Quanah Gibson-Mount wrote: > > Would you be willing to share your full finalized ruleset? This spam is > really obnoxious. > > Sure... > > A little adjustment as I noticed the brackets around the first number > match was wrong

Re: rule for repeated tracking numbers

--On Wednesday, August 06, 2014 7:32 PM +0100 Paul Stead wrote: 06/08/14 16:28, Quanah Gibson-Mount wrote: Would you be willing to share your full finalized ruleset? This spam is really obnoxious. Sure... A little adjustment as I noticed the brackets around the first number match was wron

Re: rule for repeated tracking numbers

I must put a disclaimer that this is possibly not the most efficient regex in the world either - though I'm not sure what else could be done to refine it so it still matches in the way we want. 250 character limit should help though? Paul On 06/08/14 18:32, Paul Stead wrote: 06/08/14 16:28, Qu

Re: rule for repeated tracking numbers

06/08/14 16:28, Quanah Gibson-Mount wrote: Would you be willing to share your full finalized ruleset? This spam is really obnoxious. Sure... A little adjustment as I noticed the brackets around the first number match was wrong: header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/ body __LOC_DIG

Re: rule for repeated tracking numbers

--On Wednesday, August 06, 2014 4:37 PM +0100 Paul Stead wrote: I've been having a play with the two rules mentioned, this seems to work for me: header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/ body __LOC_DIGITS_CONFUSER / (\d){7,8} .{1,250} ([0-9a-f]{32}) .{1,250}[\g1|\g2].{1,250}[\g1|\g2

Re: New at SpamAssassin - how to not get headers

Axb wrote > On 08/05/2014 06:06 PM, Bowie Bailey wrote: >> On 8/5/2014 11:50 AM, RobertGrimes wrote: >>> >>> I don't know if this is fair to ask, but would you (or anyone) care to >>> see >>> if the message I am posting should be rated higher than 1.9? I >>> appologize if >>> this is not appropriat

Re: rule for repeated tracking numbers

I've been having a play with the two rules mentioned, this seems to work for me: header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/ body __LOC_DIGITS_CONFUSER / (\d){7,8} .{1,250} ([0-9a-f]{32}) .{1,250}[\g1|\g2].{1,250}[\g1|\g2]/ Joining these together in a meta rule seems to be picking up the