Re: Sa-update and proxy servers

[Daniel Lemke]

Michael Scheidell wrote:
> 
> [...]
> I now need to set a proxy server to do sa-updates through, but could not
> find any information on settings for a proxy server.
> 
> [...]
> Added cmd options:
>  -x --proxy
>  -U --proxy-user
>  -P --proxy-password
>  -t --connect-timeout.
> 
>  [...]
> 

Hi, 

just found this old thread regarding the proxy capabilities of sa-update. I
wonder why Michael's patch hasn't been included to the official source.

We've got a customer that wants to use sa-update through a proxy but using a
custom patch to provide such a feature is kind of weird. Would it be
possible to make the patch official? At least it'd be great if one could
specify username and password in addition to the proxy url by using
environment variables for LWP::Agent.

Any comments on this?

Daniel
-- 
View this message in context: 
http://old.nabble.com/Sa-update-and-proxy-servers-tp5026430p30957142.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Sa-update and proxy servers

[Warren Togami Jr.]

On 2/17/2011 11:44 PM, Daniel Lemke wrote:



Michael Scheidell wrote:


[...]
I now need to set a proxy server to do sa-updates through, but could not
find any information on settings for a proxy server.

[...]
Added cmd options:
  -x --proxy
  -U --proxy-user
  -P --proxy-password
  -t --connect-timeout.

  [...]



Hi,

just found this old thread regarding the proxy capabilities of sa-update. I
wonder why Michael's patch hasn't been included to the official source.

We've got a customer that wants to use sa-update through a proxy but using a
custom patch to provide such a feature is kind of weird. Would it be
possible to make the patch official? At least it'd be great if one could
specify username and password in addition to the proxy url by using
environment variables for LWP::Agent.

Any comments on this?

Daniel


Was this ever filed as a bug with the suggested patch attached?  Nothing 
gets in the code without a bug filed.


Warren

Re: date_received for previous hop

[Bowie Bailey]

On 2/17/2011 8:27 PM, Frank Reppin wrote:
> Hi list,
>
> for some weird reasons...
> ... I need to know the date where a mail was sent
> by the previous host (in the mail header chain) to
> our MTA.
>
> From checking HeaderEval.pm I conclude that:
> (if I'm correct)
>
>   date_received -> gives me the date where my MTA
>did accept/take the mail
>   date_header_time -> date where mail was written
>   by some user (MUA)
>   date_diff -> delta of above mentioned values
>
> date_diff is (unfortunately) not enough for our
> specific requirement here...
>
> Is there an 'easy' way to get this very specific date
> of the host one hop back away in the mail headers?

You want the date the mail was sent to your MTA?  How is that different
than the date it was received by your MTA?

-- 
Bowie

Re: Freemail problem

[Mark Martinec]

Jeremy, Noel,

> I'm using SpamAssassin 3.2.5, and the "FreeMail.pm" plugin v2.001 from 
> http://sa.hege.li, along with the rules from the 20_freemail.cf file at the 
> same location.
>
> My first question is why does (mr.anthonywalter2010[at]gmail.com) appear 
> twice within the FREEMAIL_FROM entry inside the X-Spam-Report header? Is it 
> there twice because this address was used for both the Return-Path and the 
> From headers? In other words, should I expect the FREEMAIL_FROM entry to 
> list any freemail address which is used as the envelope sender, as well as 
> any freemail address used in the From header of the message? I had assumed 
> the FREEMAIL_FROM rule only looked at the From header but maybe that's 
> incorrect.
> 
> My second question is regarding the reference to 
> (financediamond[at]gmail.com) in the FREEMAIL_FROM results. That email 
> address does not appear anywhere in the entire message! Not in any of the 
> headers, nor in any part of the body. I've opened up the raw email file from 
> my mail server and searched the entire thing in a plain text editor, and 
> there is no reference anywhere to 'financediamond' at all. So why is the 
> FREEMAIL_FROM rule referring to that address? Is it a bug maybe? Could it 
> perhaps be crossing wires with another email which my SpamAssassin was 
> scanning at the same time, or something like that??
> 
> I am seeing this occasionally myself, including just now, except with
> 3.3.1 ( hence my search of the mailbox and found this, but only this
> post) somehow its mixing with addresses from separate emails altogether,
> this is postfix and SA is called from amavisd-new
> Was any suggestions given?

> I didn't receive any suggestions. I had hoped that when I would eventually
> upgrade to 3.3.x (haven't done that yet), that the problem would go away.
> So I'm sad to hear that it still exists.

It's a bug in the FreeMail.pm plugin. It forgets to reset the rule description
text with every message, to the addresses listed in a rule description
just accumulate from one message to the next. I think this only affects
text in a report, the rules probably hit correctly.

  Mark 

Re: using spamhaus droplist with sa ?

[Ken A]

On 2/17/2011 6:52 PM, Warren Togami Jr. wrote:

On 2/17/2011 5:40 AM, RW wrote:


The suggestion is that it be scored higher for that reason.


Or just outright block all MTA connections from anything listed in
zen.spamhaus.org, which seems to be safe. Large sites I know have been
doing that for years without any complaints.


But, Zen contains some infected hosts, not just known spam orgs. That 
would make it a bit hard for a small sender with an infection problem to 
discover the problem, right? Not very polite to block them at the 
firewall, imo. Maybe we need a new type of ICMP response for infected 
hosts?


Ken


Warren



--
Ken Anderson
Pacific Internet - http://www.pacific.net

Re: using spamhaus droplist with sa ?

[Bowie Bailey]

On 2/18/2011 9:30 AM, Ken A wrote:
>
>
> On 2/17/2011 6:52 PM, Warren Togami Jr. wrote:
>> On 2/17/2011 5:40 AM, RW wrote:
>>>
>>> The suggestion is that it be scored higher for that reason.
>>
>> Or just outright block all MTA connections from anything listed in
>> zen.spamhaus.org, which seems to be safe. Large sites I know have been
>> doing that for years without any complaints.
>
> But, Zen contains some infected hosts, not just known spam orgs. That
> would make it a bit hard for a small sender with an infection problem
> to discover the problem, right? Not very polite to block them at the
> firewall, imo. Maybe we need a new type of ICMP response for infected
> hosts?

Block them at the MTA, not the firewall.  This way they get a rejection
message telling them that they are listed on Zen.

-- 
Bowie

Re: date_received for previous hop

[Frank Reppin]

Hi Bowie,

On 18.02.2011 15:10, Bowie Bailey wrote:
[...]

You want the date the mail was sent to your MTA?  How is that different
than the date it was received by your MTA?

No - this would be really the same then. :)

But let me clarify...

... each received header contains the date where a mail
was taken from the previous host.

I'll try to illustrate which date I'm after, so let's assume:

SENDER -> RELAY X -> RELAY Y -> RELAY Z -> OUR MTA -> RECEIVER

When I'm on |OUR MTA| then 'date_received' would point to
the date where |OUR MTA| took the mail from |RELAY Z|.

But my intention is to know the date when a mail was received
by |RELAY Z| ( coming in from |RELAY Y| on |RELAY Z|).
This is what I meant by 'previous hop' in my initial post.

Thanks,
frank\

--
43rd Law of Computing:
Anything that can go wr
fortune: Segmentation violation -- Core dumped

Re: Freemail problem

[Henrik K]

On Fri, Feb 18, 2011 at 03:20:32PM +0100, Mark Martinec wrote:
> Jeremy, Noel,
> 
> > I'm using SpamAssassin 3.2.5, and the "FreeMail.pm" plugin v2.001 from 
> > http://sa.hege.li, along with the rules from the 20_freemail.cf file at the 
> > same location.
> >
> > My first question is why does (mr.anthonywalter2010[at]gmail.com) appear 
> > twice within the FREEMAIL_FROM entry inside the X-Spam-Report header? Is it 
> > there twice because this address was used for both the Return-Path and the 
> > From headers? In other words, should I expect the FREEMAIL_FROM entry to 
> > list any freemail address which is used as the envelope sender, as well as 
> > any freemail address used in the From header of the message? I had assumed 
> > the FREEMAIL_FROM rule only looked at the From header but maybe that's 
> > incorrect.
> > 
> > My second question is regarding the reference to 
> > (financediamond[at]gmail.com) in the FREEMAIL_FROM results. That email 
> > address does not appear anywhere in the entire message! Not in any of the 
> > headers, nor in any part of the body. I've opened up the raw email file 
> > from 
> > my mail server and searched the entire thing in a plain text editor, and 
> > there is no reference anywhere to 'financediamond' at all. So why is the 
> > FREEMAIL_FROM rule referring to that address? Is it a bug maybe? Could it 
> > perhaps be crossing wires with another email which my SpamAssassin was 
> > scanning at the same time, or something like that??
> > 
> > I am seeing this occasionally myself, including just now, except with
> > 3.3.1 ( hence my search of the mailbox and found this, but only this
> > post) somehow its mixing with addresses from separate emails altogether,
> > this is postfix and SA is called from amavisd-new
> > Was any suggestions given?
> 
> > I didn't receive any suggestions. I had hoped that when I would eventually
> > upgrade to 3.3.x (haven't done that yet), that the problem would go away.
> > So I'm sad to hear that it still exists.
> 
> It's a bug in the FreeMail.pm plugin. It forgets to reset the rule description
> text with every message, to the addresses listed in a rule description
> just accumulate from one message to the next. I think this only affects
> text in a report, the rules probably hit correctly.

Hmm yes I was wondering about this... so $pms->{conf} isn't actually "per
message" then?  Too busy to dive into that right now..

Re: date_received for previous hop

[Bowie Bailey]

On 2/18/2011 9:38 AM, Frank Reppin wrote:
> Hi Bowie,
>
> On 18.02.2011 15:10, Bowie Bailey wrote:
> [...]
>> You want the date the mail was sent to your MTA?  How is that different
>> than the date it was received by your MTA?
> No - this would be really the same then. :)
>
> But let me clarify...
>
> ... each received header contains the date where a mail
> was taken from the previous host.
>
> I'll try to illustrate which date I'm after, so let's assume:
>
> SENDER -> RELAY X -> RELAY Y -> RELAY Z -> OUR MTA -> RECEIVER
>
> When I'm on |OUR MTA| then 'date_received' would point to
> the date where |OUR MTA| took the mail from |RELAY Z|.
>
> But my intention is to know the date when a mail was received
> by |RELAY Z| ( coming in from |RELAY Y| on |RELAY Z|).
> This is what I meant by 'previous hop' in my initial post.

That information should be in the headers.  For example, from your email:

Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
  by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Feb 2011 14:39:31 +

It is up to the receiving MTA to write the timestamp in the header.  If
it does not do so, or if the time is not set correctly on the server,
you are out of luck.

-- 
Bowie

Re: date_received for previous hop

[Frank Reppin]

Hi Bowie,
hi list,

On 18.02.2011 16:25, Bowie Bailey wrote:
[...]

That information should be in the headers.  For example, from your email:

Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
   by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Feb 2011 14:39:31 +

It is up to the receiving MTA to write the timestamp in the header.  If
it does not do so, or if the time is not set correctly on the server,
you are out of luck.

Yes - I know that this is shown up in the header.

But coming back to my initial question
... is there an _easy_ way (like it is with 'date_received' for the
receiving MTA where spamassassin runs on) to query this date for
the receiving line the previous hop inserted?

Something like:

my $date_received_here = $msg->{ date_received }; # <- current hop

but just (for what I want):

my $date_received_prev = $msg->{ date_received_previous }; # <- prev hop

(I know that 'date_received_previous' doesn't exist - acts just as
example) without reinventing the wheel or reparsing all headers again.

Not sure if maybe all found received dates are just pushed into an array
in order of appearance and 'date_received' is just the last element
in an already known variable...  which I then use to make something up.

frank\


--
43rd Law of Computing:
Anything that can go wr
fortune: Segmentation violation -- Core dumped

Re: Freemail problem

[Mark Martinec]

Henrik,
 
> Hmm yes I was wondering about this... so $pms->{conf} isn't actually "per
> message" then?  Too busy to dive into that right now..

No, the $pms->{conf} is just another ref or shortcut to $main->{conf}.
Changes there affect the global configuration.

The calls to $pms->clear_test_state and $pms->test_log may be
more appropriate to add auxilliary information to rule hits.

Also, the $pms->got_hit can now accept a 'description' attribute
(if needed) with more recent versions of SpamAssassin.

  Mark

Re: date_received for previous hop

[Bowie Bailey]

On 2/18/2011 10:58 AM, Frank Reppin wrote:
>
> On 18.02.2011 16:25, Bowie Bailey wrote:
> [...]
>> That information should be in the headers.  For example, from your
>> email:
>>
>> Received: from athena.apache.org (HELO athena.apache.org)
>> (140.211.11.136)
>>by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Feb 2011 14:39:31
>> +
>>
>> It is up to the receiving MTA to write the timestamp in the header.  If
>> it does not do so, or if the time is not set correctly on the server,
>> you are out of luck.
> Yes - I know that this is shown up in the header.
>
> But coming back to my initial question
> ... is there an _easy_ way (like it is with 'date_received' for the
> receiving MTA where spamassassin runs on) to query this date for
> the receiving line the previous hop inserted?
>
> Something like:
>
> my $date_received_here = $msg->{ date_received }; # <- current hop
>
> but just (for what I want):
>
> my $date_received_prev = $msg->{ date_received_previous }; # <- prev hop
>
> (I know that 'date_received_previous' doesn't exist - acts just as
> example) without reinventing the wheel or reparsing all headers again.
>
> Not sure if maybe all found received dates are just pushed into an array
> in order of appearance and 'date_received' is just the last element
> in an already known variable...  which I then use to make something up.

Ah.  I see what you are looking for now.  Unfortunately, I don't know
much about the internals of SA.  Maybe someone else will be able to help.

-- 
Bowie

TVD_SPACED_SUBJECT_WORD3

[Leonard den Ottolander]

Hi,

I was wondering what the rationale behind the rule
TVD_SPACED_SUBJECT_WORD3 is.
http://spamassassin.apache.org/tests_3_2_x.html does not give a
description. This rule bit me when sending a mail with the subject "Re:
MySQL".

Regards,
Leonard.

Re: TVD_SPACED_SUBJECT_WORD3

[Raymond Dijkxhoorn]

Hi!


TVD_SPACED_SUBJECT_WORD3 is.
http://spamassassin.apache.org/tests_3_2_x.html does not give a
description. This rule bit me when sending a mail with the subject "Re:
MySQL".


This rule can hit about anything.

72_active.cf:##{ TVD_SPACED_SUBJECT_WORD3
72_active.cf:header TVD_SPACED_SUBJECT_WORD3Subject =~ 
/^(?:(?:Re|Fw)[^:]{0,5}: )?[A-Z]+[a-z]+[A-Z]+$/
72_active.cf:##} TVD_SPACED_SUBJECT_WORD3

Bye,
Raymond.

Re: TVD_SPACED_SUBJECT_WORD3

[Leonard den Ottolander]

Hello Raymond,

On Fri, 2011-02-18 at 19:27 +0100, Raymond Dijkxhoorn wrote:
> > TVD_SPACED_SUBJECT_WORD3 is.
> > http://spamassassin.apache.org/tests_3_2_x.html does not give a
> 
> This rule can hit about anything.

As per the link I included I did see *what* the rule looks like.
However, I would like to understand why it is there and what it is
supposed to filter.

Regards,
Leonard.

Re: TVD_SPACED_SUBJECT_WORD3

[Raymond Dijkxhoorn]

Hi!


TVD_SPACED_SUBJECT_WORD3 is.
http://spamassassin.apache.org/tests_3_2_x.html does not give a



This rule can hit about anything.



As per the link I included I did see *what* the rule looks like.
However, I would like to understand why it is there and what it is
supposed to filter.


Thats why i put the rule inside the mail.

72_active.cf:##{ TVD_SPACED_SUBJECT_WORD3
72_active.cf:header TVD_SPACED_SUBJECT_WORD3Subject =~ 
/^(?:(?:Re|Fw)[^:]{0,5}: )?[A-Z]+[a-z]+[A-Z]+$/
72_active.cf:##} TVD_SPACED_SUBJECT_WORD3

Bye,
Raymond.

Re: TVD_SPACED_SUBJECT_WORD3

[John Hardin]

On Fri, 18 Feb 2011, Raymond Dijkxhoorn wrote:


Hi!


> >  TVD_SPACED_SUBJECT_WORD3 is.
> >  http://spamassassin.apache.org/tests_3_2_x.html does not give a



>  This rule can hit about anything.



 As per the link I included I did see *what* the rule looks like.
 However, I would like to understand why it is there and what it is
 supposed to filter.


Thats why i put the rule inside the mail.

72_active.cf:##{ TVD_SPACED_SUBJECT_WORD3
72_active.cf:header TVD_SPACED_SUBJECT_WORD3Subject =~ 
/^(?:(?:Re|Fw)[^:]{0,5}: )?[A-Z]+[a-z]+[A-Z]+$/

72_active.cf:##} TVD_SPACED_SUBJECT_WORD3


I'd expect because someone saw a bunch of spam with a single-word 
mixed-case subject line.


{digs a bit}

Looking in 
http://svn.apache.org/viewvc/spamassassin/trunk/rulesrc/sandbox/felicity/70_other.cf?r1=393262&r2=393263&;


we see:

# Re: VI w AGRA
# Re: XANAboX

--
 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
---
  A sword is never a killer, it is but a tool in the killer's hands.
  -- Lucius Annaeus Seneca (Martial) 4BC-65AD
---
 4 days until George Washington's 279th Birthday

Re: TVD_SPACED_SUBJECT_WORD3

[Bowie Bailey]

On 2/18/2011 1:59 PM, Raymond Dijkxhoorn wrote:
> Hi!
>
 TVD_SPACED_SUBJECT_WORD3 is.
 http://spamassassin.apache.org/tests_3_2_x.html does not give a
>
>>> This rule can hit about anything.
>
>> As per the link I included I did see *what* the rule looks like.
>> However, I would like to understand why it is there and what it is
>> supposed to filter.
>
> Thats why i put the rule inside the mail.
>
> 72_active.cf:##{ TVD_SPACED_SUBJECT_WORD3
> 72_active.cf:header TVD_SPACED_SUBJECT_WORD3Subject =~
> /^(?:(?:Re|Fw)[^:]{0,5}: )?[A-Z]+[a-z]+[A-Z]+$/
> 72_active.cf:##} TVD_SPACED_SUBJECT_WORD3

For the regexp challenged:

This rule hits a subject with an optional "Re:" or "Fw:" followed by one
word starting with at least one uppercase letter followed by at least
one lowercase letter followed by at least one uppercase letter.  It will
not match if there are multiple words or any non-alphabetic characters
in the subject.

Your subject "Re: MySQL" happened to hit that pattern, but I would
expect ham hits to be pretty rare.

-- 
Bowie

Re: TVD_SPACED_SUBJECT_WORD3

[Raymond Dijkxhoorn]

Hi!


For the regexp challenged:

This rule hits a subject with an optional "Re:" or "Fw:" followed by one
word starting with at least one uppercase letter followed by at least
one lowercase letter followed by at least one uppercase letter.  It will
not match if there are multiple words or any non-alphabetic characters
in the subject.

Your subject "Re: MySQL" happened to hit that pattern, but I would
expect ham hits to be pretty rare.


Its a rule i disabled a long time ago and no its not rare. Rules should be 
more specific then this imho.


Bye,
Raymond.

Re: TVD_SPACED_SUBJECT_WORD3

[Bowie Bailey]

On 2/18/2011 4:09 PM, Raymond Dijkxhoorn wrote:
> Hi!
>
>> For the regexp challenged:
>>
>> This rule hits a subject with an optional "Re:" or "Fw:" followed by one
>> word starting with at least one uppercase letter followed by at least
>> one lowercase letter followed by at least one uppercase letter.  It will
>> not match if there are multiple words or any non-alphabetic characters
>> in the subject.
>>
>> Your subject "Re: MySQL" happened to hit that pattern, but I would
>> expect ham hits to be pretty rare.
>
> Its a rule i disabled a long time ago and no its not rare. Rules
> should be more specific then this imho.

Do you really see many single word subjects that both begin and end with
capitols, but are not all caps?

In any case, this appears to be a moot point as the default score on SA
3.3.1 is 0.

-- 
Bowie

Tonns of russian DOT info spam

[Michelle Konzack]

Hello *,

Since three weeks the Debian Mailinglist are hit be several 1000 russian
DOTinfo spams and spamassassin score this crap with -4

Does someone have a working rule for this crap?

I tried :

describe TD_INFO   dot info spam
body __TD_INFO /http:\/\/.*\.info/i
scoreTD_INFO   4.0

but it does not work.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet France EURL   itsystems@tdnet UG (limited liability)
Owner Michelle KonzackOwner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France   77694 Kehl/Germany
Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil
Tel: +33-9-52705884 fix

  
 

Jabber linux4miche...@jabber.ccc.de

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature

Re: Tonns of russian DOT info spam

[Adam Katz]

On 02/18/2011 01:46 PM, Michelle Konzack wrote:
> Since three weeks the Debian Mailinglist are hit be several 1000 russian
> DOTinfo spams and spamassassin score this crap with -4
> 
> Does someone have a working rule for this crap?
> 
> I tried :
> 
> describe TD_INFO   dot info spam
> body __TD_INFO /http:\/\/.*\.info/i
> scoreTD_INFO   4.0
> 
> but it does not work.

And thank goodness for that, your rule is WAY too broad to be useful
as it blocks the ENTIRE .info top-level domain (a very bad idea).

If you really want to do something that bold, at least limit it to the
debian list (note, that list-id is a guess, check your headers):

header __TD_DEB_LISTList-Id =~ //
uri__TD_DOT_INFOm'^http://[^/]*\.info[/:?#]'i
meta   TD_DEB_INFO  __TD_DEB_LIST && __TD_DOT_INFO
score  TD_DEB_INFO  1.0

Check the SA rules it hits and add them as dependencies to that meta if
you want to increase the score; if it previously got a -4 score, it had
to hit some rule to do that.

Again, even this safer rule seems to be the wrong approach.  I suspect
you have a custom rule that is the source of the problem.  Can you post
the offending message to a pastebin?  The scoring breakdown would also
be useful (re-run the message with `spamassassin -t 

signature.asc
Description: OpenPGP digital signature

My messages never got to this list, even though I'm subscribed etc.

[jidanni]

My recent messages never got to this list, even though I'm subscribed etc.
Could it be it thinks they are ... spam?
-- 
View this message in context: 
http://old.nabble.com/My-messages-never-got-to-this-list%2C-even-though-I%27m-subscribed-etc.-tp30962942p30962942.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Tonns of russian DOT info spam

[John Hardin]

On Fri, 18 Feb 2011, Adam Katz wrote:


On 02/18/2011 01:46 PM, Michelle Konzack wrote:

Since three weeks the Debian Mailinglist are hit be several 1000 russian
DOTinfo spams and spamassassin score this crap with -4


Can you post the offending message to a pastebin?


+1 on the samples.

I only see one on the debian-user list archive, and the archive interface 
doesn't give an obvious way to see the raw message.


--
 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
---
  Bipartisanship (n): Shut up about your principles and vote the way
  the President tells you to!
---
 4 days until George Washington's 279th Birthday

Re: My messages never got to this list, even though I'm subscribed etc.

[John Hardin]

On Fri, 18 Feb 2011, jidanni wrote:

My recent messages never got to this list, even though I'm subscribed 
etc. Could it be it thinks they are ... spam?


Or maybe the Nabble -> SA glue was temporarily broken for some reason.

We aren't going to troubleshoot Nabble for you. Post directly to the list.

--
 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
---
  Bipartisanship (n): Shut up about your principles and vote the way
  the President tells you to!
---
 4 days until George Washington's 279th Birthday

Re: Tonns of russian DOT info spam

[Karsten Bräckelmann]

On Fri, 2011-02-18 at 14:04 -0800, Adam Katz wrote:
> On 02/18/2011 01:46 PM, Michelle Konzack wrote:
> > Since three weeks the Debian Mailinglist are hit be several 1000 russian
> > DOTinfo spams and spamassassin score this crap with -4

Spam scoring -4. The .info URI is not your problem, neither the full
solution. It might help in the end, but for now I'd bark up the other
tree...

> > Does someone have a working rule for this crap?

At the very least, you should provide the rules hit. There's something
wrong with that already.

> > I tried :
> > 
> > describe TD_INFO   dot info spam
> > body __TD_INFO /http:\/\/.*\.info/i
> > scoreTD_INFO   4.0
> > 
> > but it does not work.
> 
> And thank goodness for that, your rule is WAY too broad to be useful
> as it blocks the ENTIRE .info top-level domain (a very bad idea).

It is even a lot worse than that. *boggle*

The reason that blob doesn't work is simple. The actual rule is not even
defined -- but at least you documented your code by giving it a
description. ;) The non-scoring (double underscore) sub-rule is defined,
but essentially useless. Unless you actually meta it somewhere outside
the blob you pasted.

Anyway, there are some fundamental problems with that rule, which
seriously needs to be fixed first.

It is a *body* rule, not limited to URIs. And there's a runaway wildcard
that happily makes the rule accept any 'http://' with the string '.info'
following in the same paragraph. It accepts *anything* between these two
strings, including whitespace. Not even mentioning the missing bounds at
the beginning and end of the RE.


> If you really want to do something that bold, at least limit it to the
> debian list (note, that list-id is a guess, check your headers):
> 
> header __TD_DEB_LIST  List-Id =~ //
> uri__TD_DOT_INFO  m'^http://[^/]*\.info[/:?#]'i

Way better. And actually a uri rule. :)  It's missing a bare domain URI,
though. The "end of the domain part" sub-RE alternatively should accept
the end of the string.

  / ... \.info(?:[/:?#]|$)/


> meta   TD_DEB_INFO__TD_DEB_LIST && __TD_DOT_INFO
> score  TD_DEB_INFO1.0
> 
> Check the SA rules it hits and add them as dependencies to that meta if
> you want to increase the score; if it previously got a -4 score, it had
> to hit some rule to do that.
> 
> Again, even this safer rule seems to be the wrong approach.  I suspect
> you have a custom rule that is the source of the problem.  Can you post
> the offending message to a pastebin?  The scoring breakdown would also
> be useful (re-run the message with `spamassassin -t >=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: Tonns of russian DOT info spam

[Adam Katz]

>> If you really want to do something that bold, at least limit it to the
>> debian list (note, that list-id is a guess, check your headers):
>>
>> header __TD_DEB_LIST List-Id =~ //
>> uri__TD_DOT_INFO m'^http://[^/]*\.info[/:?#]'i

On 02/18/2011 02:55 PM, Karsten Bräckelmann wrote:
> Way better. And actually a uri rule. :)  It's missing a bare domain URI,
> though. The "end of the domain part" sub-RE alternatively should accept
> the end of the string.
> 
>   / ... \.info(?:[/:?#]|$)/

If you're going to nit-pick, I'll correct its other minor bugs too:

header __TD_DEB_LISTList-Id =~ //
uri__TD_DOT_INFOm'^http://[^/:?#]*\.info(?:[/:?#]|$)'i

:-p



signature.asc
Description: OpenPGP digital signature

Re: My messages never got to this list, even though I'm subscribed etc.

[Karsten Bräckelmann]

On Fri, 2011-02-18 at 14:49 -0800, John Hardin wrote:
> On Fri, 18 Feb 2011, jidanni wrote:
> 
> > My recent messages never got to this list, even though I'm subscribed 
> > etc. Could it be it thinks they are ... spam?

Possible -- did you by chance include URIs in your recent attempts to
post, that happen to be black listed by URI DNSBLs?

I believe mail never is silently discarded by the list server, but SMTP
rejected if it exceeds a certain SA threshold. You should check if you
missed the reject message generated by your own MTA.

(If you actually put content like the above in your post, like black
listed URIs -- what would *your* MTA do with that mail, if it finds the
same content!?)


> Or maybe the Nabble -> SA glue was temporarily broken for some reason.
> 
> We aren't going to troubleshoot Nabble for you. Post directly to the list.

He didn't use Nabble in the past, so I'd assume he used it this time, to
actually ask the very question he did ask -- given the question, sending
a mail directly is not an option. :)


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: Freemail problem

[Noel Butler]

Mark,
On Fri, 2011-02-18 at 15:20 +0100, Mark Martinec wrote:

> Jeremy, Noel,



> It's a bug in the FreeMail.pm plugin. It forgets to reset the rule description
> text with every message, to the addresses listed in a rule description
> just accumulate from one message to the next. I think this only affects
> text in a report, the rules probably hit correctly.


Thanks for this, strange how it does not happen all the time, but at
least we know its mostly harmless.
Cheers
Noel




signature.asc
Description: This is a digitally signed message part

Re: My messages never got to this list, even though I'm subscribed etc.

[jidanni]

Well let's see if at least this reply gets through without needing to
resort to Nabble.

Re: My messages never got to this list, even though I'm subscribed etc.

[jidanni]

> "j" == jidanni   writes:

j> Well let's see if at least this reply gets through without needing to
j> resort to Nabble.

OK, it got through. ANOTHER_JIDANNI_STUPID_POST did not fire ☺

Re: Tonns of russian DOT info spam

[Karsten Bräckelmann]

On Fri, 2011-02-18 at 15:01 -0800, Adam Katz wrote:
> > > uri__TD_DOT_INFO  m'^http://[^/]*\.info[/:?#]'i
> 
> On 02/18/2011 02:55 PM, Karsten Bräckelmann wrote:
> > Way better. And actually a uri rule. :)  It's missing a bare domain URI,
> > though. The "end of the domain part" sub-RE alternatively should accept
> > the end of the string.
> > 
> >   / ... \.info(?:[/:?#]|$)/
> 
> If you're going to nit-pick, I'll correct its other minor bugs too:

Hey, I was not nit-picking! Merely increasing the expected performance
of that uri rule substantially. ;)

> header __TD_DEB_LIST  List-Id =~ //
> uri__TD_DOT_INFO  m'^http://[^/:?#]*\.info(?:[/:?#]|$)'i
> 
> :-p

Ah, good one. Though unfortunately, and I hate to admit that, both our
rules will never match. The # hash needs to be escaped... *sigh*

  [/:?\#]

Or just ignore it by leaving it out. It's pretty rare, anyway.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: Tonns of russian DOT info spam

[Adam Katz]

> Ah, good one. Though unfortunately, and I hate to admit that, both our
> rules will never match. The # hash needs to be escaped... *sigh*
> 
>   [/:?\#]
> 
> Or just ignore it by leaving it out. It's pretty rare, anyway.

Hash (#), like At (@) and sometimes Dollar ($), has an inconsistent
behavior of the SA parser.  When in doubt, escape it, but I believe it
is correctly parsed when delimited with m''

The issue with $ is moot in m//, but m'foo$' and several other
punctuation-based delimiters trigger various obscure perl variables,
which I believe include  $'  $&  $`  $+   ... A workaround is to use \Z
(which is usually the same thing) or (?:$) or a different delimiter.



signature.asc
Description: OpenPGP digital signature

Re: Tonns of russian DOT info spam

[Karsten Bräckelmann]

On Fri, 2011-02-18 at 15:53 -0800, Adam Katz wrote:
> > Ah, good one. Though unfortunately, and I hate to admit that, both our
> > rules will never match. The # hash needs to be escaped... *sigh*
> > 
> >   [/:?\#]
> > 
> > Or just ignore it by leaving it out. It's pretty rare, anyway.
> 
> Hash (#), like At (@) and sometimes Dollar ($), has an inconsistent
> behavior of the SA parser.  When in doubt, escape it, but I believe it
> is correctly parsed when delimited with m''

Not on this machine. I used tilde as RE delimiter, but just checked with
a single tick, too. Hash needs to escaped in both cases.

There definitely is inconsistent behavior with @, IIRC due to Perl
treating it as a variable in some cases. I believe with @, it is safe to
"always be in doubt" and just escape it regardless. The hash, though, I
believe consistently will be treated as a comment.

  $ spamassassin --lint --cf="uri FOO m'\.tld(?:[/:?#]|$)'"
  [28717] warn: config: invalid regexp for rule FOO:
m'\.tld(?:[/:?: missing or invalid delimiters

Almost every rule definition in the docs repeats the following statement
like a mantra. That's what makes it so embarrassing. ;)

 "Note: as per the header tests, # must be escaped (\#) or else it is
  considered the beginning of a comment."


> The issue with $ is moot in m//, but m'foo$' and several other
> punctuation-based delimiters trigger various obscure perl variables,
> which I believe include  $'  $&  $`  $+   ... A workaround is to use \Z
> (which is usually the same thing) or (?:$) or a different delimiter.

Oh, really? That would be news to me, I figured the Perl parser would be
smarter than to mix RE delimiters like that. Are you positive about
this?

And btw, there also is a $/ variable in Perl.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

[SOLVED] Re: date_received for previous hop

[Frank Reppin]

Hi list,

Ok - think of it as beeing solved.
I could make something 'useful' after
digging more in HeaderEval.pm.

But later then... this raises another issue.
I'll open a separate thread on this one.

Thanks.
frank\


--
43rd Law of Computing:
Anything that can go wr
fortune: Segmentation violation -- Core dumped

recent sa-update rules (for 3.3.1) break plugin?

[Frank Reppin]

Hi list,

I've written a small plugin which will output some timing details
in order to check whether a mail comes in with severe delay...
... not 100% complete at this stage - but it gives some timing
clues in the log.

However...
... for some weird reason will this plugin only work by using
the rules from:

  Mail-SpamAssassin-rules-3.3.1.r923114.tgz

As soon as I run sa-update and restart amavisd-new... the vars
(I've attached the plugin code in order for you to check/test)

  36: my $date_received = $msg->{ date_received };
  51: my $recv_header_times_ref = $msg->{ received_header_times };
  52: my $count_recv_headers = @$recv_header_times_ref;

won't get initialized at all and stay undef forever - leading to
no useful output at all.
Reverting the rules back to r923114 and restarting amavisd-new
will fix this immediatly...

This is reproducable on FreeBSD 9.0-CURRENT (where I wrote this plugin)
and two Debian Lenny hosts (with spamassassin 3.3.1 from backports).
All hosts run spamassassin 3.3.1 and amavisd-new 2.6.4 - FreeBSD has
perl 5.10.1 whereas Lenny comes with perl 5.10.0.
All hosts do have the same ruleset now (r923114).

I've already diff'ed both rulesets - but I cannot spot anything useful.

Thanks for your kind attention - any help is appreciated!

cheers,
frank\


--
43rd Law of Computing:
Anything that can go wr
fortune: Segmentation violation -- Core dumped
##
# Frank Reppin 

## get delivery timings...
#loadplugin DeliveryTiming DeliveryTiming.pm
#header DELIVERY_TIMING eval:check_deliverytiming()
#score  DELIVERY_TIMING -0.001
#describe   DELIVERY_TIMING just a test for now...

package DeliveryTiming;

use strict;
use warnings;
use diagnostics;
use Mail::SpamAssassin;
use Mail::SpamAssassin::Plugin;
use Data::Dumper;
use Date::Format;
our @ISA = qw(Mail::SpamAssassin::Plugin);

sub new {
  my ($class, $mailsa) = @_;
  $class = ref($class) || $class;
  my $self = $class->SUPER::new($mailsa);
  bless ($self, $class);
  $self->register_eval_rule("check_deliverytiming");
  return $self;
}

#
sub check_deliverytiming {

  my ($self, $msg) = @_;

  my $date_now = time();
  my $date_received = $msg->{ date_received };

  if($date_received) {
info("DeliveryTiming: OK...");
  } else {
info("DeliveryTiming: not yet functional...");
return 1;
  }

  my @all_rcvd = $msg->get('Received');
  my $mail_from = lc $msg->get('From:addr');
  my $mail_to = lc $msg->get('To:addr');
  my $env_from = lc $msg->get('EnvelopeFrom:addr');
  my $msg_id = $msg->get('Message-Id:addr');
  my $msg_subject = $msg->get('Subject');
  my $recv_header_times_ref = $msg->{ received_header_times };
  my $count_recv_headers = @$recv_header_times_ref;
  # looks as if date_received is the first element in \$recv_header_times_ref 
(or at least should)
  # ... thus - previous hop should be the next element then
  # ( my setup calls spamassassin from within amavisd-new - chances are that 
using
  #   spamd adds another recv header - which in turn would require to use 
'@$recv_header_times_ref[2]' instead then? )
  my $our_mta_received = @$recv_header_times_ref[0];
  my $previous_hop_received = @$recv_header_times_ref[1];

  unless($our_mta_received) {
$our_mta_received = time();
  }
  unless($previous_hop_received) {
$previous_hop_received = time();
  }
  unless($msg_subject) {
$msg_subject = "n/a";
  }
  chomp $msg_subject;

  my $delta = ( $our_mta_received - $previous_hop_received );
  my $date_now_human = time2str("%Y-%m-%d %H:%M:%S", $date_now);
  my $date_received_human = time2str("%Y-%m-%d %H:%M:%S", $date_received);
  my $our_mta_received_human = time2str("%Y-%m-%d %H:%M:%S", $our_mta_received);
  my $previous_hop_received_human = time2str("%Y-%m-%d %H:%M:%S", 
$previous_hop_received);

  dbg( "DeliveryTiming: \$date_now = '$date_now' = '$date_now_human'" );
  dbg( "DeliveryTiming: \$date_received = '$date_received' = 
'$date_received_human' ");
  dbg( "DeliveryTiming: \$our_mta_received -> '$our_mta_received' = 
'$our_mta_received_human'" );
  dbg( "DeliveryTiming: \$previous_hop_received -> '$previous_hop_received' = 
'$previous_hop_received_human'" );
  dbg( "DeliveryTiming: \$delta -> '$delta'" );

  dbg( "DeliveryTiming: elements in \$recv_header_times_ref == 
'$count_recv_headers'" );
  my $i;
  for($i = 0; $i < $count_recv_headers; $i++) {
dbg("DeliveryTiming: recv_header no '$i' -> '@$recv_header_times_ref[$i]' 
== '" . time2str("%Y-%m-%d %H:%M:%S", @$recv_header_times_ref[$i]) . "'");
  }
  dbg( "DeliveryTiming: \$msg_subject -> '$msg_subject'" );
  dbg( "DeliveryTiming: \$msg_id -> '$msg_id'" );
  dbg( "DeliveryTiming: \$env_from -> '$env_from'" );
  dbg( "DeliveryTiming: \$mail_from -> '$mail_from'" );
  dbg( "DeliveryTiming: \$mail_to -> '$mail_to'" );

  info( "DeliveryTiming: 
$delta|$msg_id|$mail_from|$env_from|$mail_to|$msg_subject|$count_recv_headers|$our_mta_received_human|$previous_hop_received_human"
 );

  #foreach(@all_rcvd) {
  #  info( "DeliveryTiming: $_");