Fwd: Re: Rule: "1.0 R_DCD 90% of .com. is spam"

2024-05-10 Thread Benny Pedersen

oh dear, when do he stop ?

 Original besked 
Emne: Re: Rule: "1.0 R_DCD 90% of .com. is spam"
Dato: 2024-05-10 20:17
Afsender: "Reindl Harald (gmail)" 
Modtager: Benny Pedersen 

Am 10.05.24 um 20:14 schrieb Benny Pedersen:

Matus UHLAR - fantomas skrev den 2024-05-10 18:46:

On 10.05.24 15:36, Rupert Gallagher wrote:
The ikea mail was received through ... 
mta-numbers.ikea.com.sparkpostmail.com and is a request for feedback.


The SA rule says ...

header R_DCD Received =~ /\.com\./

I still do not know where the rule comes from, DCD may actually mean 
dot-com-dot, and perhaps it is true that they are mostly spam.


where is the rule stored? what file?


On May 10, 2024, 17:18, Rupert Gallagher wrote:
I only have stock and KAM, and it is definitely not a custom rule of 
mine.


grep -r '\.com./' /var/lib/spamassassin/4.00/

seems some good dot.com rules everwhere


and what has this to do with the other idiot?
go and eat shit you dumb list spammer


Re: Rule: "1.0 R_DCD 90% of .com. is spam"

2024-05-10 Thread Benny Pedersen

Matus UHLAR - fantomas skrev den 2024-05-10 18:46:

On 10.05.24 15:36, Rupert Gallagher wrote:
The ikea mail was received through ... 
mta-numbers.ikea.com.sparkpostmail.com and is a request for feedback.


The SA rule says ...

header R_DCD Received =~ /\.com\./

I still do not know where the rule comes from, DCD may actually mean 
dot-com-dot, and perhaps it is true that they are mostly spam.


where is the rule stored? what file?


On May 10, 2024, 17:18, Rupert Gallagher wrote:
I only have stock and KAM, and it is definitely not a custom rule of 
mine.


grep -r '\.com./' /var/lib/spamassassin/4.00/

seems some good dot.com rules everwhere




Re: Rule: "1.0 R_DCD 90% of .com. is spam"

2024-05-10 Thread Bill Cole
On 2024-05-10 at 11:08:53 UTC-0400 (Fri, 10 May 2024 15:08:53 +)
Rupert Gallagher 
is rumored to have said:

> R_DCD

That string does not occur anywhere in the SpamAssassin distribution, neither 
in the code nor in the rules, *including* the rules that are not currently 
performing well enough to in the active list.

If your system generated that hit, it is one of your own local rules. If it 
came from elsewhere, ask them.



-- 
Bill Cole


Re: Rule: "1.0 R_DCD 90% of .com. is spam"

2024-05-10 Thread Matus UHLAR - fantomas

On 10.05.24 15:36, Rupert Gallagher wrote:

The ikea mail was received through ... mta-numbers.ikea.com.sparkpostmail.com 
and is a request for feedback.

The SA rule says ...

header R_DCD Received =~ /\.com\./

I still do not know where the rule comes from, DCD may actually mean 
dot-com-dot, and perhaps it is true that they are mostly spam.


where is the rule stored? what file?


On May 10, 2024, 17:18, Rupert Gallagher wrote:

I only have stock and KAM, and it is definitely not a custom rule of mine.



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam is for losers who can't get business any other way.


Re: Rule: "1.0 R_DCD 90% of .com. is spam"

2024-05-10 Thread Rupert Gallagher
Ahhh

The ikea mail was received through ... mta-numbers.ikea.com.sparkpostmail.com 
and is a request for feedback.

The SA rule says ...

header R_DCD Received =~ /\.com\./

I still do not know where the rule comes from, DCD may actually mean 
dot-com-dot, and perhaps it is true that they are mostly spam.
 Original Message 
On May 10, 2024, 17:18, Rupert Gallagher wrote:

> I only have stock and KAM, and it is definitely not a custom rule of mine.
>
>  Original Message 
> On May 10, 2024, 17:11, Matus UHLAR - fantomas wrote:
>
>> On 10.05.24 15:08, Rupert Gallagher wrote: >My local evidence does not 
>> support the general claim that 90% of .com is spam. > >I just received a 
>> mail from informat...@info.email.ikea.com marked as spam, with positive 
>> R_DCD. The rule did not trigger on mail from other .com addresses. > >I do 
>> not know what R_DCD means, and search indexes do not help. Short of reading 
>> the source code, does anybody know what R_DCD means? I have no idea. where 
>> did you get this rule from? I don't see it in stock rules -- Matus UHLAR - 
>> fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to 
>> receive e-mail advertising to this address. Varovanie: na tuto adresu chcem 
>> NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to 
>> the x86 architecture that allows you to install Windows. -- Matthew D. Fuller

Re: Rule: "1.0 R_DCD 90% of .com. is spam"

2024-05-10 Thread Rupert Gallagher
I only have stock and KAM, and it is definitely not a custom rule of mine.

 Original Message 
On May 10, 2024, 17:11, Matus UHLAR - fantomas wrote:

> On 10.05.24 15:08, Rupert Gallagher wrote: >My local evidence does not 
> support the general claim that 90% of .com is spam. > >I just received a mail 
> from informat...@info.email.ikea.com marked as spam, with positive R_DCD. The 
> rule did not trigger on mail from other .com addresses. > >I do not know what 
> R_DCD means, and search indexes do not help. Short of reading the source 
> code, does anybody know what R_DCD means? I have no idea. where did you get 
> this rule from? I don't see it in stock rules -- Matus UHLAR - fantomas, 
> uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive 
> e-mail advertising to this address. Varovanie: na tuto adresu chcem 
> NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to 
> the x86 architecture that allows you to install Windows. -- Matthew D. Fuller

Re: Rule: "1.0 R_DCD 90% of .com. is spam"

2024-05-10 Thread Matus UHLAR - fantomas

On 10.05.24 15:08, Rupert Gallagher wrote:

My local evidence does not support the general claim that 90% of .com is spam.

I just received a mail from informat...@info.email.ikea.com marked as spam, 
with positive R_DCD. The rule did not trigger on mail from other .com addresses.

I do not know what R_DCD means, and search indexes do not help. Short of 
reading the source code, does anybody know what R_DCD means?


I have no idea. where did you get this rule from?
I don't see it in stock rules


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows.   -- Matthew D. Fuller


Re: Rule to identify quoted-printable text

2024-01-16 Thread Jimmy
Hello Laurent,

I wanted to express my gratitude for sharing the tip on rawbody matching.
Your assistance is greatly appreciated.

Thank you,
Jimmy


On Tue, Jan 16, 2024 at 4:01 PM Laurent S. <
110ef9e3086d8405c2929e34be5b4...@protonmail.ch> wrote:

> Hi Jimmy,
>
> If you want to get that exact version using rawbody, here's how it would
> need to look like:
> rawbody  __PASSWORD_IN_QP   /\bp\x{D0}\x{B0}ssword/i
>
> As a trick to know what to use in such a case, I added this rule on my
> debug/rule testing machine:
> rawbody   __ALLRAWBODY  /.+/
> tflags__ALLRAWBODY  multiple
>
> If you want to cover more variations of obfuscated ways to write
> password, I'd recommend using the replace tags.
>
> body  __OBFU_PASS  /\b(?!password)\b/i
> replace_rules __OBFU_PASS
>
> If you want more informations about it use perldoc:
> perldoc Mail::SpamAssassin::Plugin::ReplaceTags
>
> Best regards,
> Laurent
>
> On 16.01.24 05:15, Jimmy wrote:
> > --
> > Content-Transfer-Encoding: quoted-printable
> >
> > Login  p=D0=B0ssword is s=D0=B5t to =D0=B5xpir=D0=B5
> > --
> >
> > In the provided email snippet, I aim to match the text "p=D0=B0ssword"
> using the
> > following rule:
> >
> > rawbody  __PASSWORD_IN_QP   /\bp=D0=B0ssword/i
> >
> > Despite my efforts, the rule doesn't seem to correctly identify the
> specified
> > text. I'm uncertain whether there is an error in the rule, or if I've
> overlooked
> > something crucial.
> >
> > Thank you
> > Jimmy
> >
>
>


Re: Rule to identify quoted-printable text

2024-01-15 Thread Laurent S.
Hi Jimmy,

If you want to get that exact version using rawbody, here's how it would 
need to look like:
rawbody  __PASSWORD_IN_QP   /\bp\x{D0}\x{B0}ssword/i

As a trick to know what to use in such a case, I added this rule on my 
debug/rule testing machine:
rawbody   __ALLRAWBODY  /.+/
tflags__ALLRAWBODY  multiple

If you want to cover more variations of obfuscated ways to write 
password, I'd recommend using the replace tags.

body  __OBFU_PASS  /\b(?!password)\b/i
replace_rules __OBFU_PASS

If you want more informations about it use perldoc:
perldoc Mail::SpamAssassin::Plugin::ReplaceTags

Best regards,
Laurent

On 16.01.24 05:15, Jimmy wrote:
> --
> Content-Transfer-Encoding: quoted-printable
> 
> Login  p=D0=B0ssword is s=D0=B5t to =D0=B5xpir=D0=B5
> --
> 
> In the provided email snippet, I aim to match the text "p=D0=B0ssword" using 
> the
> following rule:
> 
> rawbody  __PASSWORD_IN_QP   /\bp=D0=B0ssword/i
> 
> Despite my efforts, the rule doesn't seem to correctly identify the specified
> text. I'm uncertain whether there is an error in the rule, or if I've 
> overlooked
> something crucial.
> 
> Thank you
> Jimmy
> 



RE: rule based on domain age

2023-05-10 Thread Marc

> 
> My apologies if that has been asked and or answered previously.
> 
> I would love to have a rule to score up messages from domains registered
> in the past X configurable days.
> 
> We rarely receive legit email from domains newer than 1 year old, but we
> get spoofs daily from domains that are less than 1 year old.
> 
> I would like to score all of the less than 1 year old domains up and
> quarantine them for review.
> 
> Does such a rule already exist?
> 
> Thanks in advance for any direction any of you may have.
> 

I don't think this is available. All this would be also specific per tld. So 
everyone needed to agree on participating in some system and then you also have 
different judicial areas.




Re: Rule Help - not sure what is wrong with my syntax

2023-01-14 Thread Loren Wilton
> header TO_SPECIFIC_DOMAIN To:addr =~ /\@(test\.com|test\.net)$/

That for efficiency really should use a non-capturing grouping:

header TO_SPECIFIC_DOMAIN To:addr =~ /\@(?:test\.com|test\.net)$/

Note the "?:" after the left parend.

Loren


Re: Rule Help - not sure what is wrong with my syntax

2023-01-13 Thread Benny Pedersen

David B Funk skrev den 2023-01-14 08:35:

On Sat, 14 Jan 2023, Benny Pedersen wrote:


Benny Pedersen skrev den 2023-01-14 03:59:

header TO_SPECIFIC_DOMAIN To:addr =~ /\@(test|junc)\.(com|net|eu)$/
describe TO_SPECIFIC_DOMAIN Mail sent to test.com or test.net email 
addresses

score TO_SPECIFIC_DOMAIN -0.5

tested works if i mail myself :=)


Benny,

Does it work if you mail To: 
Note that having an '>' character at the end of an address is valid if
it has a matching '<' but that should fail your "(com|net|eu)$/" test
because of the anchoring '$'


yes

To: Benny Pedersen 

roundcube does not use

To: "Benny Pedersen" 


Re: Rule Help - not sure what is wrong with my syntax

2023-01-13 Thread David B Funk

On Sat, 14 Jan 2023, Benny Pedersen wrote:


Benny Pedersen skrev den 2023-01-14 03:59:

header TO_SPECIFIC_DOMAIN To:addr =~ /\@(test|junc)\.(com|net|eu)$/
describe TO_SPECIFIC_DOMAIN Mail sent to test.com or test.net email addresses
score TO_SPECIFIC_DOMAIN -0.5

tested works if i mail myself :=)


Benny,

Does it work if you mail To: 
Note that having an '>' character at the end of an address is valid if it has a 
matching '<' but that should fail your "(com|net|eu)$/" test because of the 
anchoring '$'



--
Dave Funk   University of Iowa
 College of Engineering
319/335-5751   FAX: 319/384-05491256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{


Re: Rule Help - not sure what is wrong with my syntax

2023-01-13 Thread Benny Pedersen

Benny Pedersen skrev den 2023-01-14 03:59:

header TO_SPECIFIC_DOMAIN To:addr =~ /\@(test|junc)\.(com|net|eu)$/
describe TO_SPECIFIC_DOMAIN Mail sent to test.com or test.net email 
addresses

score TO_SPECIFIC_DOMAIN -0.5

tested works if i mail myself :=)


Re: Rule Help - not sure what is wrong with my syntax

2023-01-13 Thread Benny Pedersen

Joey J skrev den 2023-01-14 03:42:


header TO_SPECIFIC_DOMAIN To:addr =~ /\@(test\.com|test\.net)$/
describe TO_SPECIFIC_DOMAIN Mail sent to test.com or test.net email 
addresses

score TO_SPECIFIC_DOMAIN -2.0


header TO_SPECIFIC_DOMAIN To:addr ~= /\@test\.(com|net)$/

should work


Re: Rule Help - not sure what is wrong with my syntax

2023-01-13 Thread Joey J
Thanks to everyone's suggestions.

I will try to respond to everyone in this 1 message:

This was intended for people who get both filtering inbound and outbound
form the mail gateway.
At times certain legit content gets flagged on the way OUT, so this was to
try and add a little negative score, so it would say, OK we know we send
this guy, lets say the word million etc.
We didn't want to simply whitelist the TO address, because in theory if
computers get hacked, they could potentially send out malicios
attachments/links etc, so we want to allow something that scores a very
high score, we won't allow that to go out, but if its a moderate score,
make sure it doesn't get rejected.

In respect to Henrik K, i tried using the rule but SA with lint didn't like
the evaluation of the header you suggested.
I was able to try it a litte different and got this to work, should anyone
else want to use it:

header TO_SPECIFIC_DOMAIN To:addr =~ /\@(test\.com|test\.net)$/
describe TO_SPECIFIC_DOMAIN Mail sent to test.com or test.net email
addresses
score TO_SPECIFIC_DOMAIN -2.0

*As always, thank you to everyone who helps support this list!*

On Thu, Jan 12, 2023 at 9:57 PM John Hardin  wrote:

> On Thu, 12 Jan 2023, John Hardin wrote:
>
> > On Thu, 12 Jan 2023, Martin Gregorie wrote:
> >
> >>  On Wed, 2023-01-11 at 18:39 -0500, Joey J wrote:
> >>>  Hello All,
> >>>
> >>>  I created this rule to check for email addresses matching a list to
> >>>  get
> >>>  added some negative value.
> >>>  I also tried it with just domains so it would be more efficient, but I
> >>>  can't seem to get them to run.
> >>>  Any suggestions?
> >>
> >>  Use a database to store addresses you accept mail from. Apart from the
> >>  database, you'll need a Perl module to let SA look up addresses in the
> >>  database.
> >
> > Simpler as it involves no new coding: a local DNS server and a DNSBL
> lookup
> > rule with a negative score. There are instructions for setting such up
> for
> > local blacklists, that works equally well for a local whitelist.
>
> Ah, whoops. I had it in my head that emailBL had been implemented. Never
> mind!
>
>
> --
>   John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
>   jhar...@impsec.org pgpk -a jhar...@impsec.org
>   key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
> ---
>The difference is that Unix has had thirty years of technical
>types demanding basic functionality of it. And the Macintosh has
>had fifteen years of interface fascist users shaping its progress.
>Windows has the hairpin turns of the Microsoft marketing machine
>and that's all.-- Red Drag Diva
> ---
>   5 days until Benjamin Franklin's 317th Birthday
>


-- 
Thanks!
Joey


Re: Rule Help - not sure what is wrong with my syntax

2023-01-12 Thread John Hardin

On Thu, 12 Jan 2023, John Hardin wrote:


On Thu, 12 Jan 2023, Martin Gregorie wrote:


 On Wed, 2023-01-11 at 18:39 -0500, Joey J wrote:

 Hello All,

 I created this rule to check for email addresses matching a list to
 get
 added some negative value.
 I also tried it with just domains so it would be more efficient, but I
 can't seem to get them to run.
 Any suggestions?


 Use a database to store addresses you accept mail from. Apart from the
 database, you'll need a Perl module to let SA look up addresses in the
 database.


Simpler as it involves no new coding: a local DNS server and a DNSBL lookup 
rule with a negative score. There are instructions for setting such up for 
local blacklists, that works equally well for a local whitelist.


Ah, whoops. I had it in my head that emailBL had been implemented. Never 
mind!



--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.org pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  The difference is that Unix has had thirty years of technical
  types demanding basic functionality of it. And the Macintosh has
  had fifteen years of interface fascist users shaping its progress.
  Windows has the hairpin turns of the Microsoft marketing machine
  and that's all.-- Red Drag Diva
---
 5 days until Benjamin Franklin's 317th Birthday


Re: Rule Help - not sure what is wrong with my syntax

2023-01-12 Thread John Hardin

On Thu, 12 Jan 2023, Martin Gregorie wrote:


On Wed, 2023-01-11 at 18:39 -0500, Joey J wrote:

Hello All,

I created this rule to check for email addresses matching a list to
get
added some negative value.
I also tried it with just domains so it would be more efficient, but I
can't seem to get them to run.
Any suggestions?


Use a database to store addresses you accept mail from. Apart from the
database, you'll need a Perl module to let SA look up addresses in the
database.


Simpler as it involves no new coding: a local DNS server and a DNSBL 
lookup rule with a negative score. There are instructions for setting such 
up for local blacklists, that works equally well for a local whitelist.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.org pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  USMC Rules of Gunfighting #20: The faster you finish the fight,
  the less shot you will get.
---
 5 days until Benjamin Franklin's 317th Birthday


Re: Rule Help - not sure what is wrong with my syntax

2023-01-12 Thread Henrik K


There's no need for any rules:

whitelist_to us...@example.com
whitelist_to *@domain.com

And adjust USER_IN_WHITELIST_TO for score.

(welcomelist_to / USER_IN_WELCOMELIST_TO in 4.0)


On Wed, Jan 11, 2023 at 04:56:21PM -0800, Loren Wilton wrote:
> ?
> Why not do a simple rule rather than inventing some Perl code?
>  
> header TO_SPECIFIC_EMAIL To:addr ~= '(?:\b[1]us...@example.com|\b[2]
> us...@example.com|\b[3]us...@example.com)'
> describe TO_SPECIFIC_EMAIL Mail to a specific email address
> score TO_SPECIFIC_EMAIL -2
>  
> header TO_SPECIFIC_DOMAIN To:addr '(?:'\@example1\.com | \@example2\.com | \
> @example3\.com)'
> describe TO_SPECIFIC_DOMAIN Mail to specific email domain
> score TO_SPECIFIC_DOMAIN -2
>  
> or possibly
>  
> header TO_SPECIFIC_DOMAIN To:addr '\@(?:example1\.com | example2\.com |
> example3\.com)$'
>  
>  
> Loren
> 
> - Original Message -
> From: [4]Joey J
> To: [5]users@spamassassin.apache.org
> Sent: Wednesday, January 11, 2023 3:39 PM
> Subject: Rule Help - not sure what is wrong with my syntax
> 
> Hello All,
> 
> I created this rule to check for email addresses matching a list to get
> added some negative value.
> I also tried it with just domains so it would be more efficient, but I
> can't seem to get them to run.
> Any suggestions?
> 
> header TO_SPECIFIC_EMAIL eval:check_to_specific_email()
> describe TO_SPECIFIC_EMAIL Mail to a specific email address
> 
> score TO_SPECIFIC_EMAIL -2
> 
> sub check_to_specific_email {
> my ($self) = @_;
> my $to = lc($self->get('To:addr'));
> my $list_of_address = qr/[6]us...@example.com|[7]us...@example.com|[8]
> us...@example.com/;
> if ($to =~ $list_of_address) {
> return 1;
> }
> return 0;
> }
> 
> 
> 
> 
> This version was to simply check for the domain matches, but can't seem to
> get it to work
> 
> 
> header TO_SPECIFIC_DOMAIN eval:check_to_specific_domain()
> describe TO_SPECIFIC_DOMAIN Mail to specific email domain
> 
> score TO_SPECIFIC_DOMAIN -2
> 
> sub check_to_specific_domain {
> my ($self) = @_;
> my $to = lc($self->get('To:addr'));
> if ($to =~ /\@example1\.com$|\@example2\.com$|\@example3\.com$/) {
> return 1;
> }
> return 0;
> }
> 
> 
> 
> 
> 
> 
> --
> Thanks!
> Joey
> 
> 
> 
> References:
> 
> [1] mailto:bus...@example.com
> [2] mailto:bus...@example.com
> [3] mailto:bus...@example.com
> [4] mailto:jacklistm...@gmail.com
> [5] mailto:users@spamassassin.apache.org
> [6] mailto:us...@example.com
> [7] mailto:us...@example.com
> [8] http://us...@example.com/


Re: Rule Help - not sure what is wrong with my syntax

2023-01-12 Thread Martin Gregorie
On Wed, 2023-01-11 at 16:56 -0800, Loren Wilton wrote:
> Why not do a simple rule rather than inventing some Perl code?
> 
> header TO_SPECIFIC_EMAIL To:addr ~=
> '(?:\bus...@example.com|\bus...@example.com|\bus...@example.com)'
> describe TO_SPECIFIC_EMAIL Mail to a specific email address
> score TO_SPECIFIC_EMAIL -2
> 
> header TO_SPECIFIC_DOMAIN To:addr '(?:'\@example1\.com |
> \@example2\.com | \@example3\.com)'
> describe TO_SPECIFIC_DOMAIN Mail to specific email domain
> score TO_SPECIFIC_DOMAIN -2
> 
>     or possibly
> 
> header TO_SPECIFIC_DOMAIN To:addr '\@(?:example1\.com | example2\.com
> | example3\.com)$'
> 
> 
Agreed, though after a while the regex can get rather long and unwieldy,
but its easy enough to keep the address list as a simple text file (one
address per line) and write a simple program to create a syntactically
correct SA rule from the list. That is easily done with Perl or (better)
an awk script.


Martin





Re: Rule Help - not sure what is wrong with my syntax

2023-01-12 Thread Martin Gregorie
On Wed, 2023-01-11 at 18:39 -0500, Joey J wrote:
> Hello All,
> 
> I created this rule to check for email addresses matching a list to
> get
> added some negative value.
> I also tried it with just domains so it would be more efficient, but I
> can't seem to get them to run.
> Any suggestions?
> 
Use a database to store addresses you accept mail from. Apart from the
database, you'll need a Perl module to let SA look up addresses in the
database. How to populate the database is up to you: but adding
addresses you send mail to and having your SA interface mark these
addresses as not-spam is unlikely to cause false positives. 

My preferred way of populating the database depends on you running a
local copy of Postfix. Configure Postfix to BCC all mail to a mailbox
thats's scanned for outgoing mail and run an overnight process to add
destination addresses from outbound mail to the database and discard the
messages as they're processed.

That said, I use this mechanism to populate a mail archive and a view to
select the addresses I've sent mail to from the archive. 

This approach runs adequately fast and requires minimal maintenance
apart from a weekly backup. 

HTH, Martin
 



Re: Rule Help - not sure what is wrong with my syntax

2023-01-11 Thread Loren Wilton
Why not do a simple rule rather than inventing some Perl code?

header TO_SPECIFIC_EMAIL To:addr ~= 
'(?:\bus...@example.com|\bus...@example.com|\bus...@example.com)'
describe TO_SPECIFIC_EMAIL Mail to a specific email address
score TO_SPECIFIC_EMAIL -2

header TO_SPECIFIC_DOMAIN To:addr '(?:'\@example1\.com | \@example2\.com | 
\@example3\.com)'
describe TO_SPECIFIC_DOMAIN Mail to specific email domain
score TO_SPECIFIC_DOMAIN -2

or possibly

header TO_SPECIFIC_DOMAIN To:addr '\@(?:example1\.com | example2\.com | 
example3\.com)$'


Loren
  - Original Message - 
  From: Joey J 
  To: users@spamassassin.apache.org 
  Sent: Wednesday, January 11, 2023 3:39 PM
  Subject: Rule Help - not sure what is wrong with my syntax


  Hello All,


  I created this rule to check for email addresses matching a list to get added 
some negative value.
  I also tried it with just domains so it would be more efficient, but I can't 
seem to get them to run.
  Any suggestions?


  header TO_SPECIFIC_EMAIL eval:check_to_specific_email()
  describe TO_SPECIFIC_EMAIL Mail to a specific email address


  score TO_SPECIFIC_EMAIL -2


  sub check_to_specific_email {
  my ($self) = @_;
  my $to = lc($self->get('To:addr'));
  my $list_of_address = 
qr/us...@example.com|us...@example.com|us...@example.com/;
  if ($to =~ $list_of_address) {
  return 1;
  }
  return 0;
  }






  
  This version was to simply check for the domain matches, but can't seem to 
get it to work
  


  header TO_SPECIFIC_DOMAIN eval:check_to_specific_domain()
  describe TO_SPECIFIC_DOMAIN Mail to specific email domain


  score TO_SPECIFIC_DOMAIN -2


  sub check_to_specific_domain {
  my ($self) = @_;
  my $to = lc($self->get('To:addr'));
  if ($to =~ /\@example1\.com$|\@example2\.com$|\@example3\.com$/) {
  return 1;
  }
  return 0;
  }












  -- 

  Thanks!
  Joey



Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-23 Thread Henrik K
On Mon, May 23, 2022 at 10:48:51PM -0600, Philip Prindeville wrote:
> 
> 
> > On May 11, 2022, at 1:53 AM, Henrik K  wrote:
> > 
> > On Wed, May 11, 2022 at 10:49:32AM +0300, Henrik K wrote:
> >> On Wed, May 11, 2022 at 10:44:05AM +0300, Henrik K wrote:
> >>> On Tue, May 10, 2022 at 06:19:38PM -0600, Philip Prindeville wrote:
>  See my original message.
>  
>  I can't think of a single way to match each header, and then test for 
>  any of them not matching the pattern...
> >>> 
> >>> Simply use regex negative lookahead.
> >>> 
> >>> ALL =~ /^(?!Foo|Bar):/m
> >>> 
> >>> It will hit any line _not_ starting with Foo: or Bar:
> >> 
> >> Oops I think it was buggy.. more like:
> >> 
> >> ALL =~ /^(?!(?:Foo|Bar):)/m
> > 
> > And for debug logging to log the missing header (to easily inspect what was
> > matched) you need some additional string matching, lookahead itself doesn't
> > save any string
> > 
> > ALL =~ /^(?!(?:Foo|Bar):)[^:]+/m
> > 
> 
> 
> Ended up using .*$ instead of [^:]* but that worked too.
> 
> Is it possible to count how many times we didn't see matching headers and 
> then count those, setting some threshold, like 3 or more unknown headers?

tflags multiple should work

header UNKNOWN_HDR ALL ...
tflags UNKNOWN_HDR multiple maxhits=3
meta UNKNOWN_HDR_TOOMANY UNKNOWN_HDR >= 3



Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-23 Thread Philip Prindeville



> On May 11, 2022, at 1:53 AM, Henrik K  wrote:
> 
> On Wed, May 11, 2022 at 10:49:32AM +0300, Henrik K wrote:
>> On Wed, May 11, 2022 at 10:44:05AM +0300, Henrik K wrote:
>>> On Tue, May 10, 2022 at 06:19:38PM -0600, Philip Prindeville wrote:
 See my original message.
 
 I can't think of a single way to match each header, and then test for any 
 of them not matching the pattern...
>>> 
>>> Simply use regex negative lookahead.
>>> 
>>> ALL =~ /^(?!Foo|Bar):/m
>>> 
>>> It will hit any line _not_ starting with Foo: or Bar:
>> 
>> Oops I think it was buggy.. more like:
>> 
>> ALL =~ /^(?!(?:Foo|Bar):)/m
> 
> And for debug logging to log the missing header (to easily inspect what was
> matched) you need some additional string matching, lookahead itself doesn't
> save any string
> 
> ALL =~ /^(?!(?:Foo|Bar):)[^:]+/m
> 


Ended up using .*$ instead of [^:]* but that worked too.

Is it possible to count how many times we didn't see matching headers and then 
count those, setting some threshold, like 3 or more unknown headers?

Thanks,

-Philip



Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-13 Thread Philip Prindeville



> On May 11, 2022, at 9:24 AM, John Hardin  wrote:
> 
> On Tue, 10 May 2022, Philip Prindeville wrote:
> 
>> Anyone have a rule to detect the following nonsense headers seen in this 
>> message I got?
>> 
>> Return-Path: 
>> Received: from cp24.deluxehosting.com (cp24.deluxehosting.com 
>> [207.55.244.13])
>>  by mail (envelope-sender ) (MIMEDefang) with ESMTP 
>> id 23C2ch8H717309
>>  for ; Mon, 11 Apr 2022 20:38:50 -0600
>> To: "xy...@redfish-solutions.com" 
>> From: "Nabil, Home Depot" 
>> Message-ID: <35ee7c.8b8cf6.a...@uakron.edu>
>> Date: Mon, 11 Apr 2022 22:38:48 + (UTC)
>> Minicomputers-Exhume: sides
>> Subject: Nabil, 1 searches this week
>> Malthus-Films: 88976dea
>> List-Unsubscribe: 
>> 
>> Parasitic-Homogeneity: db5da28ba3e69a
>> MIME-Version: 1.0
>> Capitalizations-Grievously: oilers
>> Content-type: multipart/mixed; boundary="--=_1649731129-716331-86"
>> 
>> Obviously, the following bogus header names are present:
>> 
>> Minicomputers-Exhume
>> Malthus-Films
>> Parasitic-Homogeneity
>> Capitalizations-Grievously
> 
> Take a look at __RAND_HEADER and RAND_HEADER_MANY
> 
> 

For my test messages, __RAND_HEADER_MANY isn't firing.

Also, Return-Path: is listed in RFC-2822, and many delivering (terminal) MTA's 
add it, including Sendmail.

-Philip




Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-13 Thread Henrik K
On Fri, May 13, 2022 at 12:22:48PM -0600, Philip Prindeville wrote:
>
> How do you look at what a rule is matching?  I've never figured that out...

Debug output:
spamassassin -t -D rules < message.eml 2>&1 | grep 'got hit'



Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-13 Thread Philip Prindeville



> On May 11, 2022, at 1:53 AM, Henrik K  wrote:
> 
> On Wed, May 11, 2022 at 10:49:32AM +0300, Henrik K wrote:
>> On Wed, May 11, 2022 at 10:44:05AM +0300, Henrik K wrote:
>>> On Tue, May 10, 2022 at 06:19:38PM -0600, Philip Prindeville wrote:
 See my original message.
 
 I can't think of a single way to match each header, and then test for any 
 of them not matching the pattern...
>>> 
>>> Simply use regex negative lookahead.
>>> 
>>> ALL =~ /^(?!Foo|Bar):/m
>>> 
>>> It will hit any line _not_ starting with Foo: or Bar:
>> 
>> Oops I think it was buggy.. more like:
>> 
>> ALL =~ /^(?!(?:Foo|Bar):)/m
> 
> And for debug logging to log the missing header (to easily inspect what was
> matched) you need some additional string matching, lookahead itself doesn't
> save any string
> 
> ALL =~ /^(?!(?:Foo|Bar):)[^:]+/m
> 


How do you look at what a rule is matching?  I've never figured that out...

-Philip




Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-13 Thread Philip Prindeville



> On May 11, 2022, at 1:44 AM, Henrik K  wrote:
> 
> On Tue, May 10, 2022 at 06:19:38PM -0600, Philip Prindeville wrote:
>> See my original message.
>> 
>> I can't think of a single way to match each header, and then test for any of 
>> them not matching the pattern...
> 
> Simply use regex negative lookahead.
> 
> ALL =~ /^(?!Foo|Bar):/m
> 
> It will hit any line _not_ starting with Foo: or Bar:
> 


Ah, that did it.

Of course, if I get false positives, I'll have to search for the header names I 
forgot to include manually...




Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-11 Thread John Hardin

On Tue, 10 May 2022, Philip Prindeville wrote:


Anyone have a rule to detect the following nonsense headers seen in this 
message I got?

Return-Path: 
Received: from cp24.deluxehosting.com (cp24.deluxehosting.com [207.55.244.13])
by mail (envelope-sender ) (MIMEDefang) with ESMTP 
id 23C2ch8H717309
for ; Mon, 11 Apr 2022 20:38:50 -0600
To: "xy...@redfish-solutions.com" 
From: "Nabil, Home Depot" 
Message-ID: <35ee7c.8b8cf6.a...@uakron.edu>
Date: Mon, 11 Apr 2022 22:38:48 + (UTC)
Minicomputers-Exhume: sides
Subject: Nabil, 1 searches this week
Malthus-Films: 88976dea
List-Unsubscribe: 

Parasitic-Homogeneity: db5da28ba3e69a
MIME-Version: 1.0
Capitalizations-Grievously: oilers
Content-type: multipart/mixed; boundary="--=_1649731129-716331-86"

Obviously, the following bogus header names are present:

Minicomputers-Exhume
Malthus-Films
Parasitic-Homogeneity
Capitalizations-Grievously


Take a look at __RAND_HEADER and RAND_HEADER_MANY


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.org pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Of the twenty-two civilizations that have appeared in history,
  nineteen of them collapsed when they reached the moral state the
  United States is in now.  -- Arnold Toynbee
---
 3 days until the 74th anniversary of Israel's independence


Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-11 Thread Henrik K
On Wed, May 11, 2022 at 10:49:32AM +0300, Henrik K wrote:
> On Wed, May 11, 2022 at 10:44:05AM +0300, Henrik K wrote:
> > On Tue, May 10, 2022 at 06:19:38PM -0600, Philip Prindeville wrote:
> > > See my original message.
> > > 
> > > I can't think of a single way to match each header, and then test for any 
> > > of them not matching the pattern...
> > 
> > Simply use regex negative lookahead.
> > 
> > ALL =~ /^(?!Foo|Bar):/m
> > 
> > It will hit any line _not_ starting with Foo: or Bar:
> 
> Oops I think it was buggy.. more like:
> 
> ALL =~ /^(?!(?:Foo|Bar):)/m

And for debug logging to log the missing header (to easily inspect what was
matched) you need some additional string matching, lookahead itself doesn't
save any string

ALL =~ /^(?!(?:Foo|Bar):)[^:]+/m



Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-11 Thread Henrik K
On Wed, May 11, 2022 at 10:44:05AM +0300, Henrik K wrote:
> On Tue, May 10, 2022 at 06:19:38PM -0600, Philip Prindeville wrote:
> > See my original message.
> > 
> > I can't think of a single way to match each header, and then test for any 
> > of them not matching the pattern...
> 
> Simply use regex negative lookahead.
> 
> ALL =~ /^(?!Foo|Bar):/m
> 
> It will hit any line _not_ starting with Foo: or Bar:

Oops I think it was buggy.. more like:

ALL =~ /^(?!(?:Foo|Bar):)/m

Unless you want to write colon to all alternations

ALL =~ /^(?!Foo:|Bar:)/m



Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-11 Thread Henrik K
On Tue, May 10, 2022 at 06:19:38PM -0600, Philip Prindeville wrote:
> See my original message.
> 
> I can't think of a single way to match each header, and then test for any of 
> them not matching the pattern...

Simply use regex negative lookahead.

ALL =~ /^(?!Foo|Bar):/m

It will hit any line _not_ starting with Foo: or Bar:



Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-11 Thread Martin Gregorie
On Tue, 2022-05-10 at 18:19 -0600, Philip Prindeville wrote:
> I can't think of a single way to match each header, and then test for
> any of them not matching the pattern...
> 
> 
I had in mind a subrule that triggers on valid header names, combined
with a meta rule that inverts the subrule result. At least, that's what
I'd try as a starting point.

Martin




Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-10 Thread Bill Cole

On 2022-05-10 at 20:20:14 UTC-0400 (Tue, 10 May 2022 18:20:14 -0600)
Philip Prindeville 
is rumored to have said:

On May 10, 2022, at 5:57 PM, Martin Gregorie  
wrote:


On Tue, 2022-05-10 at 17:29 -0600, Philip Prindeville wrote:


You're correct that they're different in every message received.


So write a rule that fires on any header name that *doesn't* match
anything in the list of legit headers as defined in the relevant 
RFCs.



See my original message.

I can't think of a single way to match each header, and then test for 
any of them not matching the pattern...


As documented in the POD in Mail::SpamAssassin::Conf, a header rule 
checking "ALL:raw" actually matches against the pristine header section, 
in which you could check for lines that do not begin with the 'standard' 
headers.


Unfortunately, as noted elsewhere in the thread, this pattern uses 
one-time header names AND there is nothing wrong about using random 
words as header names without a leading 'X-' so it's likely a low-yield 
approach.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-10 Thread Bill Cole

On 2022-05-10 at 18:10:23 UTC-0400 (Tue, 10 May 2022 16:10:23 -0600)
Philip Prindeville 
is rumored to have said:

Anyone have a rule to detect the following nonsense headers seen in 
this message I got?


No, and complicating your circumstance: RFC6648

Here's the title & abstract:


   Deprecating the "X-" Prefix and Similar Constructs
in Application Protocols

Abstract

   Historically, designers and implementers of application protocols
   have often distinguished between standardized and unstandardized
   parameters by prefixing the names of unstandardized parameters with
   the string "X-" or similar constructs.  In practice, that convention
   causes more problems than it solves.  Therefore, this document
   deprecates the convention for newly defined parameters with textual
   (as opposed to numerical) names in application protocols.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-10 Thread Loren Wilton

Minicomputers-Exhume: sides
Malthus-Films: 88976dea
Parasitic-Homogeneity: db5da28ba3e69a
Capitalizations-Grievously: oilers


It looks like the pattern is
   /[A-Z][a-z]{1,20}-[A-Z][a-z]{1.20}\:\s{1,10}[\w\d]{3,20}/
or something close to that.
Obviously it can mutate, but generally these are made by a tool, and until a 
new version of the tool comes along, they will be stable.


Try someting like
   header  LW_BOGUS_HEADERS ALL =~ 
/[A-Z][a-z]{1,20}-[A-Z][a-z]{1.20}\:\s{1,10}[\w\d]{3,20}\n/is 



Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-10 Thread Philip Prindeville



> On May 10, 2022, at 5:57 PM, Martin Gregorie  wrote:
> 
> On Tue, 2022-05-10 at 17:29 -0600, Philip Prindeville wrote:
>> 
>> You're correct that they're different in every message received.
>> 
> So write a rule that fires on any header name that *doesn't* match
> anything in the list of legit headers as defined in the relevant RFCs.


See my original message.

I can't think of a single way to match each header, and then test for any of 
them not matching the pattern...


> 
> Of course you may need to extend that list to include some extras, such
> as headers injected by SA itself, as well as DMARC, DKIM, SPF etc.


That's the easy part.


> 
> Martin
> 
> 



Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-10 Thread Philip Prindeville



> On May 10, 2022, at 5:57 PM, Martin Gregorie  wrote:
> 
> On Tue, 2022-05-10 at 17:29 -0600, Philip Prindeville wrote:
>> 
>> You're correct that they're different in every message received.
>> 
> So write a rule that fires on any header name that *doesn't* match
> anything in the list of legit headers as defined in the relevant RFCs.


See my original message.

I can't think of a single way to match each header, and then test for any of 
them not matching the pattern...


> 
> Of course you may need to extend that list to include some extras, such
> as headers injected by SA itself, as well as DMARC, DKIM, SPF etc.


That's the easy part.


> 
> Martin
> 
> 



Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-10 Thread Martin Gregorie
On Tue, 2022-05-10 at 17:29 -0600, Philip Prindeville wrote:
> 
> You're correct that they're different in every message received.
> 
So write a rule that fires on any header name that *doesn't* match
anything in the list of legit headers as defined in the relevant RFCs.

Of course you may need to extend that list to include some extras, such
as headers injected by SA itself, as well as DMARC, DKIM, SPF etc.

Martin




Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-10 Thread Philip Prindeville



> On May 10, 2022, at 4:58 PM, Kevin A. McGrail  wrote:
> 
> On 5/10/2022 6:10 PM, Philip Prindeville wrote:
>> Anyone have a rule to detect the following nonsense headers seen in this 
>> message I got?
> 
> Interesting. Those look more like something that Bayesian learning would be 
> best to handle.
> 
> But, have you built a corpora of spam and ham?  Do a list of headers that 
> appear in ham and spam corpora and xor out the spam ones.  Then write a rule 
> if any of those exist.  They look like they might change a lot and they are 
> randomized to avoid these type of issues so I see your dilemma and a plugin 
> might be needed.
> 
> Regards,
> KAM


You're correct that they're different in every message received.




Re: Rule to detect non-standard headers that aren't X- prefixed

2022-05-10 Thread Kevin A. McGrail

On 5/10/2022 6:10 PM, Philip Prindeville wrote:

Anyone have a rule to detect the following nonsense headers seen in this 
message I got?


Interesting. Those look more like something that Bayesian learning would 
be best to handle.


But, have you built a corpora of spam and ham?  Do a list of headers 
that appear in ham and spam corpora and xor out the spam ones.  Then 
write a rule if any of those exist.  They look like they might change a 
lot and they are randomized to avoid these type of issues so I see your 
dilemma and a plugin might be needed.


Regards,
KAM

--
Kevin A. McGrail
kmcgr...@apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171



Re: Rule syntax in local.cf?

2022-05-06 Thread Thomas Cameron

On 5/6/22 11:31, Bill Cole wrote:

On 2022-05-06 at 10:58:15 UTC-0400 (Fri, 6 May 2022 09:58:15 -0500)
Thomas Cameron 
is rumored to have said:


Howdy, all -

As I mentioned in a previous email, I'm trying to bump up the score for 
BAYES_999. I have not messed with SA in years, but I'm trying to get back into 
it. Sorry if this is a silly question.

I tried to add the following line to /etc/mail/spamassassin/local.cf, but it's 
not firing:

[root@mail-east ~]# cat /etc/mail/spamassassin/local.cf
# These values can be overridden by editing ~/.spamassassin/user_prefs.cf
# (see spamassassin(1) for details)

# These should be safe assumptions and allow for simple visual sifting
# without risking lost emails.

score SPAM_999 3

Where are you getting that rule name???


If I'm reading it correctly, it is NOT bumping up the score for BAYES_999, it's 
only adding the default 0.2 to it.

SA is not clairvoyant or telepathic. It has no idea that you want to change the 
score on BAYES_999 by using the name of a non-existent rule SPAM_999.


I'm running this on Red Hat Enterprise Linux 8.5. The SA package is 
spamassassin-3.4.4-4.el8.x86_64.

What am I doing wrong?

Changing the score for a non-existent rule.


Ugh. I have no idea how I got it in my head that it was SPAM and not 
BAYES. Sorry for the noise.


Thomas



Re: Rule syntax in local.cf?

2022-05-06 Thread Bill Cole
On 2022-05-06 at 10:58:15 UTC-0400 (Fri, 6 May 2022 09:58:15 -0500)
Thomas Cameron 
is rumored to have said:

> Howdy, all -
>
> As I mentioned in a previous email, I'm trying to bump up the score for 
> BAYES_999. I have not messed with SA in years, but I'm trying to get back 
> into it. Sorry if this is a silly question.
>
> I tried to add the following line to /etc/mail/spamassassin/local.cf, but 
> it's not firing:
>
> [root@mail-east ~]# cat /etc/mail/spamassassin/local.cf
> # These values can be overridden by editing ~/.spamassassin/user_prefs.cf
> # (see spamassassin(1) for details)
>
> # These should be safe assumptions and allow for simple visual sifting
> # without risking lost emails.
>
> score SPAM_999 3

Where are you getting that rule name???

> If I'm reading it correctly, it is NOT bumping up the score for BAYES_999, 
> it's only adding the default 0.2 to it.

SA is not clairvoyant or telepathic. It has no idea that you want to change the 
score on BAYES_999 by using the name of a non-existent rule SPAM_999.

> I'm running this on Red Hat Enterprise Linux 8.5. The SA package is 
> spamassassin-3.4.4-4.el8.x86_64.
>
> What am I doing wrong?

Changing the score for a non-existent rule.


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


Re: Rule tag for _USERNAME_?

2021-03-15 Thread Kevin A. McGrail
Oooh, Intriguing.  Keep me in the loop!
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Mon, Mar 15, 2021 at 1:37 AM Dan Mahoney  wrote:

>
>
> On Mar 14, 2021, at 9:45 PM, Kevin A. McGrail  wrote:
>
> Well, SpamAssMilter *must* be capturing the data from spamc and creating
> that header.  If you look at the cpp, it's building it.  You could change
> the Milter to create a header called X-ImaMilter and use any data you want.
>
>
> No argument there.  My point was that it’s not just checking it for
> ’normal’ spamassassin output (i.e. sanitizing the header returned to see if
> it matches any standard.  I can put anything i want in that header and
> (modulo length) it will transit through to my MTA’s logs.
>
> But it looks like signal_user_changed sets self->{username} in spamd so if
> you want, try this small patch for PerMsgStatus and lmk.  I tested it
> locally and it works.  It would need more documentation and cleanup to add
> it but it's safe as a proof of concept:
>
> Index: lib/Mail/SpamAssassin/PerMsgStatus.pm
> ===
> --- lib/Mail/SpamAssassin/PerMsgStatus.pm   (revision 1884910)
> +++ lib/Mail/SpamAssassin/PerMsgStatus.pm   (working copy)
> @@ -257,6 +257,11 @@
>my $pms = shift;
>$pms->{main}->timer_report();
>  },
> +
> +USERNAME => sub {
> +  my $pms = shift;
> +  $pms->{main}->{username};
> +},
>
>  ADDEDHEADERHAM => sub {
>my $pms = shift;
>
>
> I’ll give that a try in the next day.  I’ve been down the rabbit hole on a
> different project.  People in this community will likely notice my efforts
> tho.
>
> Thanks Kevin
>
> -Dan
>
>
>
>
> On Sun, Mar 14, 2021 at 7:10 AM Dan Mahoney  wrote:
>
>>
>>
>> On Mar 13, 2021, at 7:51 PM, Kevin A. McGrail 
>> wrote:
>>
>> Hi Dan,
>>
>> Milters are the glue that change the email.  SpamAssassin is just giving
>> data back to the milter.
>>
>> I believe you will find that X-Spam-Status header is being built by
>> spamass-milter not by spamassasin.  You need to change the milter code to
>> keep track of the user and add it to the X-Spam-Status line in the
>> spamass-milter.cpp
>>
>>
>> That’s not true.
>>
>> While it’s true that we’ve had issues getting spamass-milter to allow
>> headers OTHER than the standard spamassassin ones through, I can pack the
>> info I want in to the X-Spam-Status header.  Here’s an example of a recent
>> mail:
>>
>> X-Spam-Status: No, score=2.5 required=5.0 tests=DCC_CHECK=1.1,
>>  DCC_REPUT_95_98=0.7,DKIM_INVALID=0.1,DKIM_SIGNED=0.1,
>>  HAS_UNSUBSCRIBE=0.01,HTML_IMAGE_RATIO_04=0.001,HTML_MESSAGE=0.001,
>>  ISC_UNDISCLOSED=0.01,KAM_DMARC_STATUS=0.01,KAM_EU=0.5,
>>  SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=disabled version=3.4.4
>>  Lang=fr ASN=AS3292 USER=_USERNAME_
>>
>> This comes from SA's local.cf:
>>
>> local.cf:add_header all Status _YESNO_, score=_SCORE_ required=_REQD_
>> tests=_TESTSSCORES_ autolearn=_AUTOLEARN_ version=_VERSION_
>> Lang=_LANGUAGES_ ASN=_ASN_ USER=_USERNAME_
>> local.cf:add_header all Language _LANGUAGES_ (this one doesn’t show up)
>>
>> See where I have _USERNAME_ being passed through as a bareword?  I would
>> like to have the LHS/RHS of whatever email address was used to pull up
>> userprefs in that field.
>>
>> -Dan
>>
>>
>> Regards,
>> KAM
>> --.
>> Kevin A. McGrail
>> Member, Apache Software Foundation
>> Chair Emeritus Apache SpamAssassin Project
>> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>>
>>
>> On Fri, Jan 15, 2021 at 5:31 PM Dan Mahoney (Gushi) 
>> wrote:
>>
>>> All,
>>>
>>> For dumb reasons, we at the day job are using spamass-milter, which
>>> doesn't seem to let SpamAssassin add any extra X-Spam-Foo:  message tags
>>> beyond stock (I have a github issue open on this, which seems to be
>>> where a fork is being maintained).
>>>
>>> However, in order to work around this, I've added more tags to the
>>> X-Spam-Status tag locally.  Which is useful because it also lets me grep
>>> my maillogs for those things.
>>>
>>> What I can't find, and it feels like it should be a thing, is the
>>> *username* for the tag.  That is to say, the username that's being used
>>> to
>>> find the user-prefs (in our case, with spamd, it's just %u, we don't
>>> have
>>> the user/domain stuff set up).
>>>
>>> This *feels* like something a quick .pm file should be able to add
>>> rather
>>> than having to modify spamassassin core (and in fact, the tokens for
>>> username, mailbox and domain *are* available for the bayes_sql_query,
>>> but
>>> for some reason aren't exposed as tags that can be used in the report
>>> header.  Which feels somehow deliberate.)
>>>
>>> Would this be easy to do?
>>>
>>> It would also mean I could easily glean per-user/per-rule-hit reporting
>>> from my maillogs with a simple grep, rather than having to
>>> cross-correlate
>>> the mta logs from the spamd 

Re: Rule tag for _USERNAME_?

2021-03-14 Thread Dan Mahoney


> On Mar 14, 2021, at 9:45 PM, Kevin A. McGrail  wrote:
> 
> Well, SpamAssMilter *must* be capturing the data from spamc and creating that 
> header.  If you look at the cpp, it's building it.  You could change the 
> Milter to create a header called X-ImaMilter and use any data you want.

No argument there.  My point was that it’s not just checking it for ’normal’ 
spamassassin output (i.e. sanitizing the header returned to see if it matches 
any standard.  I can put anything i want in that header and (modulo length) it 
will transit through to my MTA’s logs.

> But it looks like signal_user_changed sets self->{username} in spamd so if 
> you want, try this small patch for PerMsgStatus and lmk.  I tested it locally 
> and it works.  It would need more documentation and cleanup to add it but 
> it's safe as a proof of concept:
> 
> Index: lib/Mail/SpamAssassin/PerMsgStatus.pm
> ===
> --- lib/Mail/SpamAssassin/PerMsgStatus.pm   (revision 1884910)
> +++ lib/Mail/SpamAssassin/PerMsgStatus.pm   (working copy)
> @@ -257,6 +257,11 @@
>my $pms = shift;
>$pms->{main}->timer_report();
>  },
> + 
> +USERNAME => sub {
> +  my $pms = shift;
> +  $pms->{main}->{username};
> +},
>  
>  ADDEDHEADERHAM => sub {
>my $pms = shift;

I’ll give that a try in the next day.  I’ve been down the rabbit hole on a 
different project.  People in this community will likely notice my efforts tho.

Thanks Kevin

-Dan



> 
> On Sun, Mar 14, 2021 at 7:10 AM Dan Mahoney  > wrote:
> 
> 
>> On Mar 13, 2021, at 7:51 PM, Kevin A. McGrail > > wrote:
>> 
>> Hi Dan,
>> 
>> Milters are the glue that change the email.  SpamAssassin is just giving 
>> data back to the milter.  
>> 
>> I believe you will find that X-Spam-Status header is being built by 
>> spamass-milter not by spamassasin.  You need to change the milter code to 
>> keep track of the user and add it to the X-Spam-Status line in the 
>> spamass-milter.cpp
> 
> That’s not true.
> 
> While it’s true that we’ve had issues getting spamass-milter to allow headers 
> OTHER than the standard spamassassin ones through, I can pack the info I want 
> in to the X-Spam-Status header.  Here’s an example of a recent mail:
> 
> X-Spam-Status: No, score=2.5 required=5.0 tests=DCC_CHECK=1.1,
>  DCC_REPUT_95_98=0.7,DKIM_INVALID=0.1,DKIM_SIGNED=0.1,
>  HAS_UNSUBSCRIBE=0.01,HTML_IMAGE_RATIO_04=0.001,HTML_MESSAGE=0.001,
>  ISC_UNDISCLOSED=0.01,KAM_DMARC_STATUS=0.01,KAM_EU=0.5,
>  SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=disabled version=3.4.4
>  Lang=fr ASN=AS3292 USER=_USERNAME_
> 
> This comes from SA's local.cf : 
> 
> local.cf:add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ 
> tests=_TESTSSCORES_ autolearn=_AUTOLEARN_ version=_VERSION_ Lang=_LANGUAGES_ 
> ASN=_ASN_ USER=_USERNAME_
> local.cf:add_header all Language _LANGUAGES_ (this one doesn’t show up)
> 
> See where I have _USERNAME_ being passed through as a bareword?  I would like 
> to have the LHS/RHS of whatever email address was used to pull up userprefs 
> in that field.
> 
> -Dan
> 
>> 
>> Regards,
>> KAM
>> --.
>> Kevin A. McGrail
>> Member, Apache Software Foundation
>> Chair Emeritus Apache SpamAssassin Project
>> https://www.linkedin.com/in/kmcgrail  
>> - 703.798.0171
>> 
>> 
>> On Fri, Jan 15, 2021 at 5:31 PM Dan Mahoney (Gushi) > > wrote:
>> All,
>> 
>> For dumb reasons, we at the day job are using spamass-milter, which 
>> doesn't seem to let SpamAssassin add any extra X-Spam-Foo:  message tags 
>> beyond stock (I have a github issue open on this, which seems to be 
>> where a fork is being maintained).
>> 
>> However, in order to work around this, I've added more tags to the 
>> X-Spam-Status tag locally.  Which is useful because it also lets me grep 
>> my maillogs for those things.
>> 
>> What I can't find, and it feels like it should be a thing, is the 
>> *username* for the tag.  That is to say, the username that's being used to 
>> find the user-prefs (in our case, with spamd, it's just %u, we don't have 
>> the user/domain stuff set up).
>> 
>> This *feels* like something a quick .pm file should be able to add rather 
>> than having to modify spamassassin core (and in fact, the tokens for 
>> username, mailbox and domain *are* available for the bayes_sql_query, but 
>> for some reason aren't exposed as tags that can be used in the report 
>> header.  Which feels somehow deliberate.)
>> 
>> Would this be easy to do?
>> 
>> It would also mean I could easily glean per-user/per-rule-hit reporting 
>> from my maillogs with a simple grep, rather than having to cross-correlate 
>> the mta logs from the spamd ones.  This feels like a win.
>> 
>> -Dan
>> 
>> -- 
>> 
>> 
>> Dan Mahoney
>> Techie,  Sysadmin,  WebGeek
>> Gushi on efnet/undernet 

Re: Rule tag for _USERNAME_?

2021-03-14 Thread Kevin A. McGrail
Well, SpamAssMilter *must* be capturing the data from spamc and creating
that header.  If you look at the cpp, it's building it.  You could change
the Milter to create a header called X-ImaMilter and use any data you want.

But it looks like signal_user_changed sets self->{username} in spamd so if
you want, try this small patch for PerMsgStatus and lmk.  I tested it
locally and it works.  It would need more documentation and cleanup to add
it but it's safe as a proof of concept:

Index: lib/Mail/SpamAssassin/PerMsgStatus.pm
===
--- lib/Mail/SpamAssassin/PerMsgStatus.pm   (revision 1884910)
+++ lib/Mail/SpamAssassin/PerMsgStatus.pm   (working copy)
@@ -257,6 +257,11 @@
   my $pms = shift;
   $pms->{main}->timer_report();
 },
+
+USERNAME => sub {
+  my $pms = shift;
+  $pms->{main}->{username};
+},

 ADDEDHEADERHAM => sub {
   my $pms = shift;


Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Sun, Mar 14, 2021 at 7:10 AM Dan Mahoney  wrote:

>
>
> On Mar 13, 2021, at 7:51 PM, Kevin A. McGrail  wrote:
>
> Hi Dan,
>
> Milters are the glue that change the email.  SpamAssassin is just giving
> data back to the milter.
>
> I believe you will find that X-Spam-Status header is being built by
> spamass-milter not by spamassasin.  You need to change the milter code to
> keep track of the user and add it to the X-Spam-Status line in the
> spamass-milter.cpp
>
>
> That’s not true.
>
> While it’s true that we’ve had issues getting spamass-milter to allow
> headers OTHER than the standard spamassassin ones through, I can pack the
> info I want in to the X-Spam-Status header.  Here’s an example of a recent
> mail:
>
> X-Spam-Status: No, score=2.5 required=5.0 tests=DCC_CHECK=1.1,
>  DCC_REPUT_95_98=0.7,DKIM_INVALID=0.1,DKIM_SIGNED=0.1,
>  HAS_UNSUBSCRIBE=0.01,HTML_IMAGE_RATIO_04=0.001,HTML_MESSAGE=0.001,
>  ISC_UNDISCLOSED=0.01,KAM_DMARC_STATUS=0.01,KAM_EU=0.5,
>  SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=disabled version=3.4.4
>  Lang=fr ASN=AS3292 USER=_USERNAME_
>
> This comes from SA's local.cf:
>
> local.cf:add_header all Status _YESNO_, score=_SCORE_ required=_REQD_
> tests=_TESTSSCORES_ autolearn=_AUTOLEARN_ version=_VERSION_
> Lang=_LANGUAGES_ ASN=_ASN_ USER=_USERNAME_
> local.cf:add_header all Language _LANGUAGES_ (this one doesn’t show up)
>
> See where I have _USERNAME_ being passed through as a bareword?  I would
> like to have the LHS/RHS of whatever email address was used to pull up
> userprefs in that field.
>
> -Dan
>
>
> Regards,
> KAM
> --.
> Kevin A. McGrail
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
>
> On Fri, Jan 15, 2021 at 5:31 PM Dan Mahoney (Gushi) 
> wrote:
>
>> All,
>>
>> For dumb reasons, we at the day job are using spamass-milter, which
>> doesn't seem to let SpamAssassin add any extra X-Spam-Foo:  message tags
>> beyond stock (I have a github issue open on this, which seems to be
>> where a fork is being maintained).
>>
>> However, in order to work around this, I've added more tags to the
>> X-Spam-Status tag locally.  Which is useful because it also lets me grep
>> my maillogs for those things.
>>
>> What I can't find, and it feels like it should be a thing, is the
>> *username* for the tag.  That is to say, the username that's being used
>> to
>> find the user-prefs (in our case, with spamd, it's just %u, we don't have
>> the user/domain stuff set up).
>>
>> This *feels* like something a quick .pm file should be able to add rather
>> than having to modify spamassassin core (and in fact, the tokens for
>> username, mailbox and domain *are* available for the bayes_sql_query, but
>> for some reason aren't exposed as tags that can be used in the report
>> header.  Which feels somehow deliberate.)
>>
>> Would this be easy to do?
>>
>> It would also mean I could easily glean per-user/per-rule-hit reporting
>> from my maillogs with a simple grep, rather than having to
>> cross-correlate
>> the mta logs from the spamd ones.  This feels like a win.
>>
>> -Dan
>>
>> --
>>
>>
>> Dan Mahoney
>> Techie,  Sysadmin,  WebGeek
>> Gushi on efnet/undernet IRC
>> FB:  fb.com/DanielMahoneyIV
>> LI:   linkedin.com/in/gushi
>> Site:  http://www.gushi.org
>> ---
>>
>>
>


Re: Rule tag for _USERNAME_?

2021-03-14 Thread Dan Mahoney


> On Mar 13, 2021, at 7:51 PM, Kevin A. McGrail  wrote:
> 
> Hi Dan,
> 
> Milters are the glue that change the email.  SpamAssassin is just giving data 
> back to the milter.  
> 
> I believe you will find that X-Spam-Status header is being built by 
> spamass-milter not by spamassasin.  You need to change the milter code to 
> keep track of the user and add it to the X-Spam-Status line in the 
> spamass-milter.cpp

That’s not true.

While it’s true that we’ve had issues getting spamass-milter to allow headers 
OTHER than the standard spamassassin ones through, I can pack the info I want 
in to the X-Spam-Status header.  Here’s an example of a recent mail:

X-Spam-Status: No, score=2.5 required=5.0 tests=DCC_CHECK=1.1,
 DCC_REPUT_95_98=0.7,DKIM_INVALID=0.1,DKIM_SIGNED=0.1,
 HAS_UNSUBSCRIBE=0.01,HTML_IMAGE_RATIO_04=0.001,HTML_MESSAGE=0.001,
 ISC_UNDISCLOSED=0.01,KAM_DMARC_STATUS=0.01,KAM_EU=0.5,
 SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=disabled version=3.4.4
 Lang=fr ASN=AS3292 USER=_USERNAME_

This comes from SA's local.cf: 

local.cf:add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ 
tests=_TESTSSCORES_ autolearn=_AUTOLEARN_ version=_VERSION_ Lang=_LANGUAGES_ 
ASN=_ASN_ USER=_USERNAME_
local.cf:add_header all Language _LANGUAGES_ (this one doesn’t show up)

See where I have _USERNAME_ being passed through as a bareword?  I would like 
to have the LHS/RHS of whatever email address was used to pull up userprefs in 
that field.

-Dan

> 
> Regards,
> KAM
> --.
> Kevin A. McGrail
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail  - 
> 703.798.0171
> 
> 
> On Fri, Jan 15, 2021 at 5:31 PM Dan Mahoney (Gushi)  > wrote:
> All,
> 
> For dumb reasons, we at the day job are using spamass-milter, which 
> doesn't seem to let SpamAssassin add any extra X-Spam-Foo:  message tags 
> beyond stock (I have a github issue open on this, which seems to be 
> where a fork is being maintained).
> 
> However, in order to work around this, I've added more tags to the 
> X-Spam-Status tag locally.  Which is useful because it also lets me grep 
> my maillogs for those things.
> 
> What I can't find, and it feels like it should be a thing, is the 
> *username* for the tag.  That is to say, the username that's being used to 
> find the user-prefs (in our case, with spamd, it's just %u, we don't have 
> the user/domain stuff set up).
> 
> This *feels* like something a quick .pm file should be able to add rather 
> than having to modify spamassassin core (and in fact, the tokens for 
> username, mailbox and domain *are* available for the bayes_sql_query, but 
> for some reason aren't exposed as tags that can be used in the report 
> header.  Which feels somehow deliberate.)
> 
> Would this be easy to do?
> 
> It would also mean I could easily glean per-user/per-rule-hit reporting 
> from my maillogs with a simple grep, rather than having to cross-correlate 
> the mta logs from the spamd ones.  This feels like a win.
> 
> -Dan
> 
> -- 
> 
> 
> Dan Mahoney
> Techie,  Sysadmin,  WebGeek
> Gushi on efnet/undernet IRC
> FB:  fb.com/DanielMahoneyIV 
> LI:   linkedin.com/in/gushi 
> Site:  http://www.gushi.org 
> ---
> 



Re: Rule tag for _USERNAME_?

2021-03-13 Thread Kevin A. McGrail
Hi Dan,

Milters are the glue that change the email.  SpamAssassin is just giving
data back to the milter.

I believe you will find that X-Spam-Status header is being built by
spamass-milter not by spamassasin.  You need to change the milter code to
keep track of the user and add it to the X-Spam-Status line in the
spamass-milter.cpp

Regards,
KAM
--.
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Fri, Jan 15, 2021 at 5:31 PM Dan Mahoney (Gushi) 
wrote:

> All,
>
> For dumb reasons, we at the day job are using spamass-milter, which
> doesn't seem to let SpamAssassin add any extra X-Spam-Foo:  message tags
> beyond stock (I have a github issue open on this, which seems to be
> where a fork is being maintained).
>
> However, in order to work around this, I've added more tags to the
> X-Spam-Status tag locally.  Which is useful because it also lets me grep
> my maillogs for those things.
>
> What I can't find, and it feels like it should be a thing, is the
> *username* for the tag.  That is to say, the username that's being used to
> find the user-prefs (in our case, with spamd, it's just %u, we don't have
> the user/domain stuff set up).
>
> This *feels* like something a quick .pm file should be able to add rather
> than having to modify spamassassin core (and in fact, the tokens for
> username, mailbox and domain *are* available for the bayes_sql_query, but
> for some reason aren't exposed as tags that can be used in the report
> header.  Which feels somehow deliberate.)
>
> Would this be easy to do?
>
> It would also mean I could easily glean per-user/per-rule-hit reporting
> from my maillogs with a simple grep, rather than having to cross-correlate
> the mta logs from the spamd ones.  This feels like a win.
>
> -Dan
>
> --
>
>
> Dan Mahoney
> Techie,  Sysadmin,  WebGeek
> Gushi on efnet/undernet IRC
> FB:  fb.com/DanielMahoneyIV
> LI:   linkedin.com/in/gushi
> Site:  http://www.gushi.org
> ---
>
>


Re: Rule for plussed adddress

2020-12-28 Thread John Hardin

On Mon, 28 Dec 2020, RW wrote:


On Sun, 27 Dec 2020 10:17:15 -0800 (PST)
John Hardin wrote:


To catch those you'd need to check for the address in a Received:
header, assuming your MTA adds the envelope recipient to the
Received: header it generates.



You might do:

   header ABUSED_PLUS Received =~ /\bfor
/i


This isn't completely reliable as the MTA wont provide the envelope
recipient when there's more than one in the same SMTP session. It may
be good enough for a single user mail system though.

I presume this isn't trivial to fix as Fastmail had an unreliable
X-Delivered-to header for years.

Without a reliable envelope recipient, the best you can do is use all
the sources of addresses, something like the following (untested):

header ABUSED_PLUS All =~
/^(?:(?:To|Cc):\s(?:.*(?:,\s|<))?|Received:.*for\s<)(?:shiva[+.](?:abused1|abused2)\@sewingwitch\.com)[,>\s\n]/im


Right, that's better.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.org pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
 212 days since the first private commercial manned orbital mission (SpaceX)


Re: Rule for plussed adddress

2020-12-28 Thread RW
On Sun, 27 Dec 2020 10:17:15 -0800 (PST)
John Hardin wrote:


> To catch those you'd need to check for the address in a Received:
> header, assuming your MTA adds the envelope recipient to the
> Received: header it generates.

> You might do:
> 
>header ABUSED_PLUS Received =~ /\bfor
> /i

This isn't completely reliable as the MTA wont provide the envelope
recipient when there's more than one in the same SMTP session. It may
be good enough for a single user mail system though.

I presume this isn't trivial to fix as Fastmail had an unreliable
X-Delivered-to header for years.

Without a reliable envelope recipient, the best you can do is use all
the sources of addresses, something like the following (untested):

header ABUSED_PLUS All =~
/^(?:(?:To|Cc):\s(?:.*(?:,\s|<))?|Received:.*for\s<)(?:shiva[+.](?:abused1|abused2)\@sewingwitch\.com)[,>\s\n]/im



Re: Rule for plussed adddress

2020-12-27 Thread John Hardin

On Sun, 27 Dec 2020, Kenneth Porter wrote:

--On Saturday, December 26, 2020 11:20 PM -0500 Bill Cole 
 wrote:



You definitely want to escape that '+' and catch the recipient instead of
sender:

   header RULENAME To:addr =~ /\+.+\@/
   score  RULENAME -1


That looks like what I want. Although since my server is hacked to accept a 
dot as separator, I can use [+.] in the pattern, with /[+.].+\@/. I can then 
add exceptions with positive scores for the abusers.


You'll also need to check Cc: if you're looking at the message headers, 
so two rules.


This would miss spams where the recipients are BCC'd, though.

To catch those you'd need to check for the address in a Received: header, 
assuming your MTA adds the envelope recipient to the Received: header it 
generates. For example, the "for <>" in this:


  Received: from mxout1-he-de.apache.org (mxout1-he-de.apache.org 
[95.216.194.37])
by ga.impsec.org (8.14.7/8.14.7) with ESMTP id 0BRHZ0H5027977
(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 
verify=FAIL)
for ; Sun, 27 Dec 2020 11:35:11 -0600

You might do:

  header ABUSED_PLUS Received =~ /\bfor 
/i


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.org pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Men by their constitutions are naturally divided in to two parties:
  1. Those who fear and distrust the people and wish to draw all
  powers from them into the hands of the higher classes. 2. Those who
  identify themselves with the people, have confidence in them,
  cherish and consider them as the most honest and safe, although not
  the most wise, depository of the public interests.
  -- Thomas Jefferson
---
 211 days since the first private commercial manned orbital mission (SpaceX)


Re: Rule for plussed adddress

2020-12-27 Thread Kenneth Porter
--On Saturday, December 26, 2020 11:20 PM -0500 Bill Cole 
 wrote:



You definitely want to escape that '+' and catch the recipient instead of
sender:

   header RULENAME To:addr =~ /\+.+\@/
   score  RULENAME -1


That looks like what I want. Although since my server is hacked to accept a 
dot as separator, I can use [+.] in the pattern, with /[+.].+\@/. I can 
then add exceptions with positive scores for the abusers.





Re: Rule for plussed adddress

2020-12-26 Thread Bill Cole

On 26 Dec 2020, at 18:17, Kevin A. McGrail wrote:


Header rulename from:addr =~ /.*+.*\@/


You definitely want to escape that '+' and catch the recipient instead 
of sender:


  header RULENAME To:addr =~ /\+.+\@/
  score  RULENAME -1

Another approach:

  whitelist_to *+*@example.com

In that case you may also want to reduce the strength of that level of 
welcome:


  # Default is -6 but this is a more useful value
  score USER_IN_WELCOMELIST_TO -3





Should match an email with a plus one the left hand side.

On Sat, Dec 26, 2020, 18:11 Kenneth Porter  
wrote:



I usually sign up for a web service using a "plussed" address like
shiva+vendorn...@sewingwitch.com. (My server also recognizes a dot
instead
of a plus, to deal with broken websites that won't allow me to use a 
plus
in my email address.) I use procmail rules on my server to filter 
messages

from them into different folders. I'd like to give a point of spam
"forgiveness" to some sites (I've noticed some political begging 
letters
are bumping over the 5.0 limit), and a big bonus score to those 
who've
abused my address and handeded it out to others (or for those whose 
site

has been compromised). What should the rule look like for that?





--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


Re: Rule for plussed adddress

2020-12-26 Thread Kevin A. McGrail
Header rulename from:addr =~ /.*+.*\@/

Should match an email with a plus one the left hand side.

On Sat, Dec 26, 2020, 18:11 Kenneth Porter  wrote:

> I usually sign up for a web service using a "plussed" address like
> shiva+vendorn...@sewingwitch.com. (My server also recognizes a dot
> instead
> of a plus, to deal with broken websites that won't allow me to use a plus
> in my email address.) I use procmail rules on my server to filter messages
> from them into different folders. I'd like to give a point of spam
> "forgiveness" to some sites (I've noticed some political begging letters
> are bumping over the 5.0 limit), and a big bonus score to those who've
> abused my address and handeded it out to others (or for those whose site
> has been compromised). What should the rule look like for that?
>
>


Re: Rule HK_SCAM is triggered by standard business email

2020-07-02 Thread @lbutlr
On 01 Jul 2020, at 14:20, Aner Perez  wrote:
> we have the spam threshold set very low (2.4)

This is a terrible idea and exposes a fundamental misunderstanding of how SA 
works.

If SA scores an email as 3.3 then the message is not considered spam by SA. If 
you ignore this and mark it as sam anyway, you have no one to blame but 
yourself. Reducing the threshold increases the number of non-spam messages that 
are marked as spam. It will also have very little effect on actual spam 
messages. The only exception to this is if you have a badly trained Bayes, as 
that can swing the scoring quite a lot.

Set your threshold back to 5.0 and train your Bayes with actual spam you 
receive and actual ham you receive. The best Spam to train is spam that is not 
tagged by SA as spam (ignoring the bayes portion of a score). So, a message 
marked at 5.5 with BAYES_50 is a price candidate for training as it would be 
marked 4.7 without the BAYES_50.

It would have been better, I think, had SA designed the system to score 
anything over 0 as spam and anything under 0 as ham as I suspect very few 
people would make this mistake, but it's a bit late for that now.

Just think of it this way, when you set the threshold below 5, you are saying 
to SA "please mark legitimate mail theat I want to receive as spam."



-- 
'Oh, them as makes the endings don't get them,' said Granny.
--Maskerade



Re: Rule HK_SCAM is triggered by standard business email

2020-07-01 Thread Henrik K
On Wed, Jul 01, 2020 at 01:29:51PM -0700, John Hardin wrote:
>
> Agreed, that's why I want Henrik to comment. I don't have the corpus he used
> to develop that rule.

It's really old rules, I don't have either. ;-)

__HK_SCAM_S7 seems to have regressed FP wise, just gonna drop it..



Re: Rule HK_SCAM is triggered by standard business email

2020-07-01 Thread Martin Gregorie
On Wed, 2020-07-01 at 16:20 -0400, Aner Perez wrote:
> It looks like to me like the logic in __HK_SCAM_S7 is a little
> > off...
> > 
> > /(?:(?:investment|proposed|lucrative)
> > (?:business|venture)|(?:business|venture) 
> > (?:enterprise|propos(?:al|ition)))/i
> > 
> > seems like it should be:
> > 
> > /(?:(?:investment|proposed|lucrative)
> > (?:business|venture)|(?:business|venture|enterprise) 
> > propos(?:al|ition))/i
> > 
> 
IME using a meta-rule that ANDs two rules of that type works well. 

The key is to put words or phrases that often occur in spam in each of
the sub-rules, for instance having selling jargon ("lowest prices",
"unbeatable value") in one rule and product names ("flip flops",
"vodka", "power packs") in the other. As a benefit, if the lists are
well-chosen from words and phrases from spam you've received, it will
also hit on sales spam using combinations you've not previously seen
while being surprisingly good at not giving FPs on business or personal
letters.

The only disadvantage is that the subrules get a bit unwieldy and hard
to edit once their definitions get much longer than 80 characters. That
aside, they're easy to understand and maintain.

Martin





Re: Rule HK_SCAM is triggered by standard business email

2020-07-01 Thread John Hardin

On Wed, 1 Jul 2020, Aner Perez wrote:


On 7/1/20 3:52 PM, John Hardin wrote:

On Wed, 1 Jul 2020, Aner Perez wrote:

I opened a bug (7832) about this but was told to report on the SA users 
mailing list instead.


The attached email is an example which triggers the HK_SCAM rule.  Looks 
like __HK_SCAM_S7 is the culprit here since it matches the words 
"business" and "enterprise" when they are found one after the other (even 
on different lines).


In the real world this was triggered by a business email that had the 
following in the signature:


FirstName LastName
Altice Business
Enterprise Account Executive


What was the *overall* score of that message? Was this rule enough to push 
the message over the spam threshold (5 points)? Or was the message still 
scored as ham?


In our case it was marked as spam but only because we have the spam 
threshold set very low (2.4). The message scored a 3.357 when the 
BAYES_50 was added in.


Yeah, that's why doing that blindly is a bad idea. Masscheck sets the base 
rule scores so that spams score 5 points. If you reduce the spam 
threshold, you increase FPs. You need to compensate for that if you do it.



It looks like to me like the logic in __HK_SCAM_S7 is a little off...

/(?:(?:investment|proposed|lucrative) 
(?:business|venture)|(?:business|venture) 
(?:enterprise|propos(?:al|ition)))/i


seems like it should be:

/(?:(?:investment|proposed|lucrative) 
(?:business|venture)|(?:business|venture|enterprise) propos(?:al|ition))/i




That makes more sense but the rule still seems like it would be easily 
triggered by standard business talk (e.g. business proposal).  I guess that's 
the nature of business emails... they're naturally spammy.


Agreed, that's why I want Henrik to comment. I don't have the corpus he 
used to develop that rule.


--
 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
---
  Of the twenty-two civilizations that have appeared in history,
  nineteen of them collapsed when they reached the moral state the
  United States is in now.  -- Arnold Toynbee
---
 3 days until the 244th anniversary of the Declaration of Independence

Re: Rule HK_SCAM is triggered by standard business email

2020-07-01 Thread Aner Perez

On 7/1/20 3:52 PM, John Hardin wrote:

On Wed, 1 Jul 2020, Aner Perez wrote:

I opened a bug (7832) about this but was told to report on the SA users mailing list 
instead.


The attached email is an example which triggers the HK_SCAM rule.  Looks like 
__HK_SCAM_S7 is the culprit here since it matches the words "business" and "enterprise" 
when they are found one after the other (even on different lines).


In the real world this was triggered by a business email that had the following in the 
signature:


FirstName LastName
Altice Business
Enterprise Account Executive


What was the *overall* score of that message? Was this rule enough to push the message 
over the spam threshold (5 points)? Or was the message still scored as ham?


In our case it was marked as spam but only because we have the spam threshold set very low 
(2.4).  The message scored a 3.357 when the BAYES_50 was added in.




It looks like to me like the logic in __HK_SCAM_S7 is a little off...

/(?:(?:investment|proposed|lucrative) (?:business|venture)|(?:business|venture) 
(?:enterprise|propos(?:al|ition)))/i


seems like it should be:

/(?:(?:investment|proposed|lucrative) (?:business|venture)|(?:business|venture|enterprise) 
propos(?:al|ition))/i




That makes more sense but the rule still seems like it would be easily triggered by 
standard business talk (e.g. business proposal).  I guess that's the nature of business 
emails... they're naturally spammy.



...but I'll let Henrik comment.


Potentially, making it a rawbody rule might avoid this FP without affecting its 
performance against the targeted spams...



For future reference: sending a sample email to the list as a bare attachment is 
problematic, as it may be altered en-route and thus invalidate any meaningful analysis. 
It's better to attach it as a zip/gzip, or to upload it to someplace like Pastebin and 
just post the URL to it here. (In this case, your description should probably be enough to 
figure it out without the sample so you shouldn't need to do that unless someone 
explicitly asks you to do so.)




Thanks I'll keep that in mind.

- Aner


Re: Rule HK_SCAM is triggered by standard business email

2020-07-01 Thread John Hardin

On Wed, 1 Jul 2020, Aner Perez wrote:

I opened a bug (7832) about this but was told to report on the SA users 
mailing list instead.


The attached email is an example which triggers the HK_SCAM rule.  Looks like 
__HK_SCAM_S7 is the culprit here since it matches the words "business" and 
"enterprise" when they are found one after the other (even on different 
lines).


In the real world this was triggered by a business email that had the 
following in the signature:


FirstName LastName
Altice Business
Enterprise Account Executive


What was the *overall* score of that message? Was this rule enough to push 
the message over the spam threshold (5 points)? Or was the message still 
scored as ham?


It looks like to me like the logic in __HK_SCAM_S7 is a little off...

/(?:(?:investment|proposed|lucrative) (?:business|venture)|(?:business|venture) 
(?:enterprise|propos(?:al|ition)))/i

seems like it should be:

/(?:(?:investment|proposed|lucrative) 
(?:business|venture)|(?:business|venture|enterprise) propos(?:al|ition))/i

...but I'll let Henrik comment.


Potentially, making it a rawbody rule might avoid this FP without 
affecting its performance against the targeted spams...



For future reference: sending a sample email to the list as a bare 
attachment is problematic, as it may be altered en-route and thus 
invalidate any meaningful analysis. It's better to attach it as a 
zip/gzip, or to upload it to someplace like Pastebin and just post the URL 
to it here. (In this case, your description should probably be enough to 
figure it out without the sample so you shouldn't need to do that unless 
someone explicitly asks you to do so.)




--
 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
---
  The philosophy of gun control: Teenagers are roaring through
  town at 90MPH, where the speed limit is 25. Your solution is to
  lower the speed limit to 20.   -- Sam Cohen
---
 3 days until the 244th anniversary of the Declaration of Independence


Re: rule all_spam_to

2020-05-22 Thread Axb

On 5/22/20 12:18 PM, Maurizio Caloro wrote:


Hello
I have here spamassassin with Postfix and Dovevot on Debian 9 and 10 running.
i need to go shure if all Email that declare as spam, are relay spam so 
defininig this rule.

/etc/spamassassin# cat local.cf | grep all_spam_to
all_spam_to s...@domain.ch

but on this spam mailbox never appair any E-Mail?



all_spam_to will not do what you *think* it does.

See:

https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt

whitelist_to u...@example.com
If the given address appears as a recipient in the message headers
(Resent-To, To, Cc, obvious envelope recipient, etc.) the mail will
be whitelisted. Useful if you're deploying SpamAssassin 
system-wide,

and don't want some users to have their mail filtered. Same format
as "whitelist_from".

There are three levels of To-whitelisting, "whitelist_to",
"more_spam_to" and "all_spam_to". Users in the first level may 
still

get some spammish mails blocked, but users in "all_spam_to" should
never get mail blocked.

The headers checked for whitelist addresses are as follows: if
"Resent-To" or "Resent-Cc" are set, use those; otherwise check all
addresses taken from the following set of headers:

To
Cc
Apparently-To
Delivered-To
Envelope-Recipients
Apparently-Resent-To
X-Envelope-To
Envelope-To
X-Delivered-To
X-Original-To
X-Rcpt-To
X-Real-To

more_spam_to u...@example.com
See above.

all_spam_to u...@example.com
See above.


h2h


Re: Rule to catch a certain email adress?

2019-11-28 Thread Axb

On 2019-11-28 13:43, Anders Gustafsson wrote:

Assume I want to give extra points to e-p...@pedago.fi? This is our
adress as given on our wesite so many spammers harvest that. I waht to
bump it sligtly, but have been unable to write a regexp that catches it.
Can anyone help?



this could work:

blacklist_to e-p...@pedago.fi

# SET SCORE TO WHATEVER YOU WANT
score USER_IN_BLACKLIST_TO  3.0

h2h


Re: Rule for detecting two email addresses in From: field.

2019-10-05 Thread Grant Taylor

On 10/4/19 12:22 PM, A. Schulze wrote:

Hi Grant,

Maybe we're talking about different things :-)


Based on your description, I believe we are talking about different 
things.  Thank you for the clarification.



The OpenDMARC bug could be triggered by this RFC5322.From:
From: user , user 


I seem to recall that it is within RFC spec to have multiple addresses 
in the From: header.


I would assume that all would need to pass DMARC alignment tests for the 
message to also pass DMARC alignment tests.  This would likely be 
difficult to do if the From: addresses are part of separate domains, 
especially if they are from separate organizations.


Mallory could send a message which authenticates as badguy.example but 
OpenDMARC report "dmarc=pass domain=yahoo.example" That's fixed with 
https://github.com/trusteddomainproject/OpenDMARC/pull/48/commits/f6b615e345037408b88b2ffd1acd03239af8a858


That seems like a problem.  I'm glad that it was fixed.


But back to SA:
there is a difference between this comma separated list and the 
display name containing a second address ...


Agreed.

I still think that the MUA has some culpability in both cases; multiple 
addresses in one From: header and multiple From: headers.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Rule for detecting two email addresses in From: field.

2019-10-04 Thread A. Schulze



Am 04.10.19 um 16:40 schrieb Grant Taylor:
> On 10/4/19 6:43 AM, A. Schulze wrote:
>> that happen from time to time but currently I suspect the sender like to 
>> trigger a Bug in OpenDMARC to generate dmarc=pass for messages that 
>> otherwise would be classified as dmarc=reject.
> 
> Based on my understanding of DMARC, which could be wrong, I don't think this 
> is a bug in OpenDMARC, as an implementation, but rather an unexpected 
> behavior around the DMARC standard.
> 
> My understanding is that the DMARC standard is to check alignment of the 
> From: address, which means the part inside angle brackets, outside of the 
> optional double quoted friendly name.
> 
>    From:  "John Doe " 
> 
> Thus DMARC is supposed to /only/ check  and /not/ check 
> .

Hi Grant,

Maybe we're talking about different things :-) The OpenDMARC bug could be 
triggered by this RFC5322.From:
From: user , user 

Mallory could send a message which authenticates as badguy.example but 
OpenDMARC report "dmarc=pass domain=yahoo.example"
That's fixed with 
https://github.com/trusteddomainproject/OpenDMARC/pull/48/commits/f6b615e345037408b88b2ffd1acd03239af8a858

But back to SA:
there is a difference between this comma separated list and the display name 
containing a second address ...

Andreas


Re: Rule for detecting two email addresses in From: field.

2019-10-04 Thread shanew

I use a plugin that detects mismatches, but tries to be a little smart
about what counts as a mismatch (like making sure the mismatch isn't
really just that one address is from a subdomain of the other's
domain, or someone carelessly using the "@" character in the name part
of the From header).

https://github.com/enkidushane/sa-frommismatch



On Fri, 4 Oct 2019, Philip wrote:


Morning List,

Lately I'm getting a bunch of emails that are showing up with two email 
addresses in the From: field.


From: "Persons Name " 

When you look in your mail client (Outlook, Thunderbird) it's showing only 
"Persons Name "


Is there a way I can mark From: that has 2 email addresses in it as spam? 
Pro's Cons?


Phil




--
Public key #7BBC68D9 at| Shane Williams
http://pgp.mit.edu/|  System Admin - UT CompSci
=--+---
All syllogisms contain three lines |  sha...@shanew.net
Therefore this is not a syllogism  | www.ischool.utexas.edu/~shanew


Re: Rule for detecting two email addresses in From: field.

2019-10-04 Thread Grant Taylor

On 10/4/19 6:43 AM, A. Schulze wrote:
that happen from time to time but currently I suspect the sender like 
to trigger a Bug in OpenDMARC to generate dmarc=pass for messages that 
otherwise would be classified as dmarc=reject.


Based on my understanding of DMARC, which could be wrong, I don't think 
this is a bug in OpenDMARC, as an implementation, but rather an 
unexpected behavior around the DMARC standard.


My understanding is that the DMARC standard is to check alignment of the 
From: address, which means the part inside angle brackets, outside of 
the optional double quoted friendly name.


   From:  "John Doe " 

Thus DMARC is supposed to /only/ check  and /not/ 
check .


As such, some enterprising individuals have taken to using putting an 
address they want to pretend to be inside the double quoted friendly 
name while using something else they control in the actual from address. 
 Thus their messages /do/ /pass/ DMARC alignment tests while still 
appearing to be from what humans (mis)perceive as the address inside the 
double quoted friendly name.


To me, this is what the DMARC specification states.  Thus why 
enterprising individuals have taken to using this work around to make 
messages appear to be from j...@example.net.


This is also why some DMARC implementations have started going beyond 
the DMARC specification and looking for what appears to be an email 
address inside the double quoted friendly name and applying DMARC 
alignment tests to that in addition to what the specification says. 
Hence why I referred to these implementations as over zealous.


I'm aware, the Debian package of opendmarc was updated some weeks ago: 
https://www.debian.org/security/2019/dsa-4526


I thought that this bug was based on multiple From: headers in a message.

   From:  "unknown" 
   From:  "John Doe " 

The first part of this issue centering around the fact that some DMARC 
implementations would test the first From: header for alignment and 
ignoring other From: headers, assuming that there is only one.


The second part of this issue centering around the fact that some MUAs 
only display the last From: header and ignore other From: headers.


The combined interaction being that the questionable message passes 
DMARC alignment tests without any problems and the last From: address is 
displayed to the end user.  Thus making a message seemingly from John 
Doe  passed DMARC when  was the 
real sender that passed DMARC.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Rule for detecting two email addresses in From: field.

2019-10-04 Thread Grant Taylor

On 10/4/19 5:41 AM, Reindl Harald wrote:
there is nothing ill advised because otherwise you have no way to see 
the original address of the sender


There is nothing ill advised about having the information.  There is 
unfortunately a potential gotcha if the information is formatted as 
"" inside of the friendly name / double quoted.


The problem comes from over zealous DMARC implementations that look 
inside the friendly name / double quoted portion in addition to the 
actual email address.


I recommend that people format the information differently so that it 
does not appear as an actual email address to such questionable DMARC 
implementations.  E.g. "user at example.com".


Thus the information is there for the end user to utilize with much less 
risk of running afoul of over zealous DMARC implementations. 
Implementations which, as I understand it, go against the DMARC standard.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Rule for detecting two email addresses in From: field.

2019-10-04 Thread A. Schulze



Am 04.10.19 um 01:12 schrieb Philip:
> Lately I'm getting a bunch of emails that are showing up with two email 
> addresses in the From: field.

that happen from time to time but currently I suspect the sender like to 
trigger a Bug in OpenDMARC
to generate dmarc=pass for messages that otherwise would be classified as 
dmarc=reject.

I'm aware, the Debian package of opendmarc was updated some weeks ago:
https://www.debian.org/security/2019/dsa-4526

Andreas


Re: Rule for detecting two email addresses in From: field.

2019-10-04 Thread bOnK

On 4-10-2019 1:12, Philip wrote:

Morning List,

Lately I'm getting a bunch of emails that are showing up with two 
email addresses in the From: field.


From: "Persons Name " 

When you look in your mail client (Outlook, Thunderbird) it's showing 
only "Persons Name "


Is there a way I can mark From: that has 2 email addresses in it as 
spam? Pro's Cons?


Phil


header  FR_D_AT  From =~ /\S+\@[\w\-\.]+.*\S+\@[\w\-\.]+/
describe    FR_D_AT  From has double email address?
score   FR_D_AT  0.1

header  FR_NA_SAME   From =~ /(\S+\@[\w\-\.]+).*\1/
describe    FR_NA_SAME   From name and address is the same email 
address.

tflags  FR_NA_SAME   nice
score   FR_NA_SAME   -0.1

meta    SPOOF_EMAIL  (FR_D_AT && ! FR_NA_SAME)
describe    SPOOF_EMAIL  From name and address have different email 
address!

score   SPOOF_EMAIL  2.5

--
bOnK


Re: Rule for detecting two email addresses in From: field.

2019-10-04 Thread Tom Hendrikx

On 04-10-19 04:31, Bill Cole wrote:

On 3 Oct 2019, at 20:01, Rick Cooper wrote:


Philip wrote:

Morning List,

Lately I'm getting a bunch of emails that are showing up with two
email addresses in the From: field.

From: "Persons Name " 

When you look in your mail client (Outlook, Thunderbird) it's showing
only "Persons Name "

Is there a way I can mark From: that has 2 email addresses in it as
spam? Pro's Cons?

Phil


From: =~ /^.*?<.+?\@.+?>.*?<.+\@.+?>/g

Can't imagine the circumstance where such a from: format would be 
required


I've seen it used as a perfectly reasonable workaround for the 
misfeature described above of many MUAs of hiding the address field in 
To/From/CC headers. Because many people actually want to know what the 
actual address is.





I would disagree on the "reasonable" here. People using a mailclient 
should configure it as they wish. My client hides email addresses for 
everyone in my address book, but not for 'unknown' addresses.


That is how I like it, and I don't think senders should try to enforce a 
workaround for this because their recipients are too stupid to configure 
their email client (or switch to a decent one).


Anyway, the main harm is done when the email adresses in the 'addr' 
field and the 'name' are different, and that's detectable.


Kind regards,
Tom


Re: Rule for detecting two email addresses in From: field.

2019-10-03 Thread Bill Cole

On 3 Oct 2019, at 20:01, Rick Cooper wrote:


Philip wrote:

Morning List,

Lately I'm getting a bunch of emails that are showing up with two
email addresses in the From: field.

From: "Persons Name " 

When you look in your mail client (Outlook, Thunderbird) it's showing
only "Persons Name "

Is there a way I can mark From: that has 2 email addresses in it as
spam? Pro's Cons?

Phil


From: =~ /^.*?<.+?\@.+?>.*?<.+\@.+?>/g

Can't imagine the circumstance where such a from: format would be 
required


I've seen it used as a perfectly reasonable workaround for the 
misfeature described above of many MUAs of hiding the address field in 
To/From/CC headers. Because many people actually want to know what the 
actual address is.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)


Re: Rule for detecting two email addresses in From: field.

2019-10-03 Thread Grant Taylor

On 10/3/19 6:01 PM, Rick Cooper wrote:

Can't imagine the circumstance where such a from: format would be required


I've seen people (mis)use it as a way to work around DMARC alignment in 
mailing lists.  They move the purported senders to the friendly / pretty 
name and use the mailing list address as the actual From: address.  E.g.


From: "Grant " 

I think such use is ill advised and likely to end up running afoul of 
over zealous DMARC filters.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Rule for detecting two email addresses in From: field.

2019-10-03 Thread David B Funk

On Fri, 4 Oct 2019, Philip wrote:


Morning List,

Lately I'm getting a bunch of emails that are showing up with two email 
addresses in the From: field.


From: "Persons Name " 

When you look in your mail client (Outlook, Thunderbird) it's showing only 
"Persons Name "


Is there a way I can mark From: that has 2 email addresses in it as spam? 
Pro's Cons?


Phil


I seem to remember past discussions of this sort of thing.

Bottom line, it's a mixed bag. There are legitimate messages that include an 
address'ey looking in the "comment" part of the 'From:' header.


Use the "header rule_name  From:name =~ /target\@some\.place/"
format rule (IE use the From:name field).

This works best when looking for spear-phishing type messages where you're 
looking for specific kinds of deception, EG:


  header T_PAPAL_PHISH4From:name =~ 
/\b(?:Pay[Pp]al|service)\@paypal\.com\b/

For a general rule, I wouldn't treat it as a hard spam sign but use it in 
combination with meta's




--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{


RE: Rule for detecting two email addresses in From: field.

2019-10-03 Thread Rick Cooper
Philip wrote:
> Morning List,
> 
> Lately I'm getting a bunch of emails that are showing up with two
> email addresses in the From: field.
> 
> From: "Persons Name " 
> 
> When you look in your mail client (Outlook, Thunderbird) it's showing
> only "Persons Name "
> 
> Is there a way I can mark From: that has 2 email addresses in it as
> spam? Pro's Cons?
> 
> Phil

From: =~ /^.*?<.+?\@.+?>.*?<.+\@.+?>/g

Can't imagine the circumstance where such a from: format would be required

Rick



Re: Rule for non-DKIM-signed messages

2019-05-13 Thread David Jones
On 5/12/19 9:29 PM, Kurt Fitzner wrote:
> On 2019-05-11 23:25, David Jones wrote:
> 
> I don't have anything nearly so elaborate.  But then I don't have the 
> spam volume either.
> 

That's fine.  Just wanted to point out that "one size doesn't fit all" 
for other readers on this list.  The default SA rules have to follow 
RFCs and standard practices in a general way so SA can start out working 
for all then allow each admin to tune it toward the mail flow they have.

> 
> Thanks,
> 
>    Kurt
> -- 
David Jones


Re: Rule for non-DKIM-signed messages

2019-05-13 Thread Brent Clark

Shot for sharing David !!!

Regards
Brent Clark
P.s. I wonder what other tricks you have up your sleeve that you would 
be willing to share. :)


On 2019/05/10 16:48, David Jones wrote:

On 5/10/19 1:52 AM, Pedro David Marco wrote:

Hi Kurt,


On the contrary, most spam i see is valid DKIM signed...   tons of
hacked sites... tons of emails from free trials of big-cheeses...

Nevertheless...

meta    NO_DKIM_SIGNED    ! DKIM_SIGNED
score NO_DKIM_SIGNED        2
describe NO_DKIM_SIGNED        Email does not have DKIM signature



That alone is too risky to score alone and should be used in a meta rule
like this:

metaSPAM_NOT_DKIM_SIGNED!DKIM_SIGNED && (MISSING_HEADERS ||
FSL_BULK_SIG || RDNS_DYNAMIC || OTHER_RULE_COMMONLY_SEEN_AS_SPAM)
score   SPAM_NOT_DKIM_SIGNED2
describe SPAM_NOT_DKIM_SIGNED   Spammy characteristics and not DKIM signed



Pedro.


  >
  >On Friday, May 10, 2019, 4:26:46 AM GMT+2, Kurt Fitzner
 wrote:
  >
  >I've noticed on my mail server that DKIM signing is almost diagnostic of
  >spam.  Almost no legitimate sender is without DKIM, and about 90% of my
  >spam is unsigned, so I want to bias non-DKIM-signed heavily towards
  >spam.  To that end I was wondering if there are any built-in rules I can
  >activate to score emails that are not DKIM-signed? I'd rather use a
  >built-in rule than roll my own.


I caution against this since non-DKIM signed email has no relation to
spam or ham.  How did you come up with the "about 90%" number?  Did you
grep logs to get real numbers over a couple of months?

Any compromised account from Office 365 (and there are a lot) is going
to have DKIM_SIGNED by Microsoft's "tenant.onmicrosoft.com" domain which
means absolutely nothing when determining ham/spam.  All that means is
it was signed by Microsoft mail servers on the way out.  If DKIM_VALID
was hit, then it means the spam wasn't modified.



Re: Rule for non-DKIM-signed messages

2019-05-12 Thread Kurt Fitzner

On 2019-05-11 23:25, David Jones wrote:


Is this for a single mailbox?  If that is the case, then it's fine to
make a decision like that for a single mailbox.  For those of us 
running

mail filtering plaforms for customers, this would be a very bad rule.


Not a single mailbox, no.  Not nearly the size of operation you have, 
though.  Family and a few friends.  Anything they toss in their spam 
folders gets moved to a central spot where I can do a post mortem.



I have an automated system that finds these candidates every week and
adds them automatically to my SA config file.  This is a whole category
of email that I don't have to worry about false positives allowing me 
to

increase the sensitivity of scores and meta rules to help block
compromised accounts and zero-hour spam.


I don't have anything nearly so elaborate.  But then I don't have the 
spam volume either.



My SA servers see millions of emails each week and they handle a lot of
non-DKIM signed ham.


I'm small potatoes, almost all my "customers" are an amateur radio club 
who's members all email each other more than anyone else.  It wasn't 
until I personally started having to email a bunch of new gmail accounts 
that the problem with my server not having DKIM-signing really crossed 
the threshold from annoyance into "must fix".  But I honestly don't know 
(and I'm curious to find out) how can any major player still get away 
with not having DKIM-signing?  How does anyone without it manage when 
Google spam-boxes all their mail?


My rule is in now.  I'll monitor it closely.  I attached less of a 
penalty to not having DKIM than I originally intended, based on your 
feedback.  We'll see how it goes.


Thanks,

  Kurt



Re: Rule for non-DKIM-signed messages

2019-05-11 Thread David Jones
On 5/10/19 1:16 PM, Kurt Fitzner wrote:
> On 2019-05-10 12:42, Matus UHLAR - fantomas wrote:
> 
>> I wanted to comment OP's mail, but since I don't have DKIM set up, I 
>> wasn't
>> sure it would pass  :-)
> 
> I actually didn't have DKIM signing set up myself until a couple weeks 
> ago.  I had been lazy in setting it for a while, but I had to because 
> the first time I would email anyone on gmail it was going directly to 
> their spam folder.  Hotmail too, to a lesser extent.  But Google is 
> really aggressive with unsigned mail, and they have a strong "it's our 
> way or the highway" policy.
> 
> On 10.05.19 14:48, David Jones wrote:
> 
>>> I caution against this since non-DKIM signed email has no relation to
>>> spam or ham.  How did you come up with the "about 90%" number?  Did you
>>> grep logs to get real numbers over a couple of months?
> 
> I should clarify.  I do get DKIM-signed spam.  I just don't get any 
> non-DKIM-signed ham.  Going back and looking at my archived mail and 
> logs I can see that a) all legitimate emails were DKIM-signed, and b) 
> virtually every message that was not DKIM-signed was spam.  So I intend 
> to assign no ham scoring weight to a message having a DKIM signature, 
> but I do feel pretty safe in assigning a heavy penalty to those mails 
> without it.
> 

Is this for a single mailbox?  If that is the case, then it's fine to 
make a decision like that for a single mailbox.  For those of us running 
mail filtering plaforms for customers, this would be a very bad rule.

I filter for about 60,000 to 80,000 mailboxes (can't tell for sure with 
Exchange accepting everything and bouncing later) and use DKIM_VALID_AU 
heavily with thousands of subdomain entries like:

whitelist_auth *@*.joann.com
whitelist_auth *@*.potterybarn.com
whitelist_auth *@*.aa.com
whitelist_auth *@*.saks.com
whitelist_auth *@*.dominos.com
whitelist_auth *@*.fandango.com

I know for sure that these emails are:

1. System generated and not from user accounts that can be compromised
2. Generated by a mail server under the control or authorized by their 
respective domain owners.

I have an automated system that finds these candidates every week and 
adds them automatically to my SA config file.  This is a whole category 
of email that I don't have to worry about false positives allowing me to 
increase the sensitivity of scores and meta rules to help block 
compromised accounts and zero-hour spam.

My SA servers see millions of emails each week and they handle a lot of 
non-DKIM signed ham.

-- 
David Jones


Re: Rule for non-DKIM-signed messages

2019-05-10 Thread Kurt Fitzner

On 2019-05-10 12:42, Matus UHLAR - fantomas wrote:

I wanted to comment OP's mail, but since I don't have DKIM set up, I 
wasn't

sure it would pass  :-)


I actually didn't have DKIM signing set up myself until a couple weeks 
ago.  I had been lazy in setting it for a while, but I had to because 
the first time I would email anyone on gmail it was going directly to 
their spam folder.  Hotmail too, to a lesser extent.  But Google is 
really aggressive with unsigned mail, and they have a strong "it's our 
way or the highway" policy.


On 10.05.19 14:48, David Jones wrote:


I caution against this since non-DKIM signed email has no relation to
spam or ham.  How did you come up with the "about 90%" number?  Did 
you

grep logs to get real numbers over a couple of months?


I should clarify.  I do get DKIM-signed spam.  I just don't get any 
non-DKIM-signed ham.  Going back and looking at my archived mail and 
logs I can see that a) all legitimate emails were DKIM-signed, and b) 
virtually every message that was not DKIM-signed was spam.  So I intend 
to assign no ham scoring weight to a message having a DKIM signature, 
but I do feel pretty safe in assigning a heavy penalty to those mails 
without it.


Sorry Matus. :)

 Kurt



Re: Rule for non-DKIM-signed messages

2019-05-10 Thread Matus UHLAR - fantomas

On 5/10/19 1:52 AM, Pedro David Marco wrote:

On the contrary, most spam i see is valid DKIM signed...   tons of
hacked sites... tons of emails from free trials of big-cheeses...

Nevertheless...

meta    NO_DKIM_SIGNED    ! DKIM_SIGNED
score NO_DKIM_SIGNED        2
describe NO_DKIM_SIGNED        Email does not have DKIM signature


On 10.05.19 14:48, David Jones wrote:

That alone is too risky to score alone and should be used in a meta rule
like this:

metaSPAM_NOT_DKIM_SIGNED!DKIM_SIGNED && (MISSING_HEADERS ||
FSL_BULK_SIG || RDNS_DYNAMIC || OTHER_RULE_COMMONLY_SEEN_AS_SPAM)
score   SPAM_NOT_DKIM_SIGNED2
describe SPAM_NOT_DKIM_SIGNED   Spammy characteristics and not DKIM signed


I wanted to comment OP's mail, but since I don't have DKIM set up, I wasn't
sure it would pass  :-)


 >On Friday, May 10, 2019, 4:26:46 AM GMT+2, Kurt Fitzner
 wrote:
 >
 >I've noticed on my mail server that DKIM signing is almost diagnostic of
 >spam.  Almost no legitimate sender is without DKIM, and about 90% of my
 >spam is unsigned, so I want to bias non-DKIM-signed heavily towards
 >spam.  To that end I was wondering if there are any built-in rules I can
 >activate to score emails that are not DKIM-signed? I'd rather use a
 >built-in rule than roll my own.


I caution against this since non-DKIM signed email has no relation to
spam or ham.  How did you come up with the "about 90%" number?  Did you
grep logs to get real numbers over a couple of months?

Any compromised account from Office 365 (and there are a lot) is going
to have DKIM_SIGNED by Microsoft's "tenant.onmicrosoft.com" domain which
means absolutely nothing when determining ham/spam.  All that means is
it was signed by Microsoft mail servers on the way out.  If DKIM_VALID
was hit, then it means the spam wasn't modified.


I also doubt if DKIM_VALID is enough. To be sure, the mail should hit
DKIM_VALID_AU to prove it was signed by the sender's mail server...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm


Re: Rule for non-DKIM-signed messages

2019-05-10 Thread David Jones
On 5/10/19 1:52 AM, Pedro David Marco wrote:
> Hi Kurt,
> 
> 
> On the contrary, most spam i see is valid DKIM signed...   tons of 
> hacked sites... tons of emails from free trials of big-cheeses...
> 
> Nevertheless...
> 
> meta    NO_DKIM_SIGNED    ! DKIM_SIGNED
> score NO_DKIM_SIGNED        2
> describe NO_DKIM_SIGNED        Email does not have DKIM signature
> 

That alone is too risky to score alone and should be used in a meta rule 
like this:

metaSPAM_NOT_DKIM_SIGNED!DKIM_SIGNED && (MISSING_HEADERS || 
FSL_BULK_SIG || RDNS_DYNAMIC || OTHER_RULE_COMMONLY_SEEN_AS_SPAM)
score   SPAM_NOT_DKIM_SIGNED2
describe SPAM_NOT_DKIM_SIGNED   Spammy characteristics and not DKIM signed


> Pedro.
> 
> 
>  >
>  >On Friday, May 10, 2019, 4:26:46 AM GMT+2, Kurt Fitzner 
>  wrote:
>  >
>  >I've noticed on my mail server that DKIM signing is almost diagnostic of
>  >spam.  Almost no legitimate sender is without DKIM, and about 90% of my
>  >spam is unsigned, so I want to bias non-DKIM-signed heavily towards
>  >spam.  To that end I was wondering if there are any built-in rules I can
>  >activate to score emails that are not DKIM-signed? I'd rather use a
>  >built-in rule than roll my own.

I caution against this since non-DKIM signed email has no relation to 
spam or ham.  How did you come up with the "about 90%" number?  Did you 
grep logs to get real numbers over a couple of months?

Any compromised account from Office 365 (and there are a lot) is going 
to have DKIM_SIGNED by Microsoft's "tenant.onmicrosoft.com" domain which 
means absolutely nothing when determining ham/spam.  All that means is 
it was signed by Microsoft mail servers on the way out.  If DKIM_VALID 
was hit, then it means the spam wasn't modified.

-- 
David Jones


Re: Rule for non-DKIM-signed messages

2019-05-10 Thread Pedro David Marco
 Hi Kurt,

On the contrary, most spam i see is valid DKIM signed...   tons of hacked 
sites... tons of emails from free trials of big-cheeses...
Nevertheless...
meta    NO_DKIM_SIGNED    ! DKIM_SIGNEDscore   NO_DKIM_SIGNED       
 2describe  NO_DKIM_SIGNED        Email does not have DKIM signature

Pedro.
>   >On Friday, May 10, 2019, 4:26:46 AM GMT+2, Kurt Fitzner 
 wrote:  > >I've noticed on my mail server that DKIM signing is 
almost diagnostic of 
>spam.  Almost no legitimate sender is without DKIM, and about 90% of my 
>spam is unsigned, so I want to bias non-DKIM-signed heavily towards 
>spam.  To that end I was wondering if there are any built-in rules I can 
>activate to score emails that are not DKIM-signed? I'd rather use a 
>built-in rule than roll my own.
  

Re: Rule release workflow

2019-04-17 Thread Kevin A. McGrail
Depending on your level of interest you might join the sysadmins list but
here is a high level overview.

Rules are checked into trunk and then go through distributed volunteer
masschecks for promotion, demotion and rule qa for a genetic algorithm for
scoring.

When the system deems they are ok, DNS is updated to tell sa-update a new
ruleset is ready.

We use trunk with version conditional to produce one ruleset for most of
the modern versions.

This process takes about 48 hours and we could use volunteers who want to
dig into some thesis level systems to speed it up.

The primary reason I maintain KAM.cf is because of the publishing delays.

Hth, KAM

On Wed, Apr 17, 2019, 03:59  wrote:

> Hello,
>
> I am wondering how fixed and new rules go from the developer branch to the
> official updates. The website is a bit vague in this respect.
>
> Matthias
>
>


Re: Rule to resolve sending hostname & show it in description?

2019-02-14 Thread RW
On Thu, 14 Feb 2019 11:53:52 -0800
Loren Wilton wrote:

> About 99% (literally) of the spam I get is fron one spammer. He
> doesn't bother obfuscating the received headers, other than putting a
> fake hostname in the sending hostname. Here are the final two levels
> from a random spam from a few minutes ago as an example:
> 
> Received: from noehlo.host ([209.86.89.125])
>  by mdl-harvest.atl.sa.earthlink.net (EarthLink SMTP Server) with
> SMTP id 1GUltH2aW3Nl36V0; Thu, 14 Feb 2019 13:11:17 -0500 (EST)

The  header above looks to be internal to earthlink and isn't relevant.

> Received: from newdeals4you.com ([34.207.159.130])
>  by ibscan-hornet.atl.sa.earthlink.net (EarthLink SMTP Server) with
> SMTP id 1GUltH4Ke3PGoUd1
>  for ; Thu, 14 Feb 2019 13:11:17 -0500 (EST)

This header is added by earthlink, the only thing under the sender's
control is the 'helo' of newdeals4you.com. There's no other scope for
"obfuscating" this.


> While he's claiming to be from newdeals4you.com, 34.207.159.130 is an
> Amazon AWS cloud host.

A mismatch isn't necessarily wrong, but the A-record for
newdeals4you.com points elsewhere.
 
> Just as a matter of curiosity, I'd like some sort of rule that could
> resolve that hostname and display it in the description of a
> low-scoring rule, 


This is the job of ibscan-hornet.atl.sa.earthlink.net. It probably
doesn't because there is no full circle DNS

34.207.159.130 has rDNS of ec2-34-207-159-130.compute-1.amazonaws.com,
but that doesn't have an A-record pointing to 34.207.159.130

Without full-circle DNS the rDNS alone doesn't reliably connect the IP
address to the the domain.


Re: rule for docx o xlsx

2018-12-19 Thread Benny Pedersen

Rick Gutierrez skrev den 2018-12-19 18:44:


Hi Benny,  I am not an expert in amavisd, but I have installed a few
and in the official documentation you can block this type of files or
extension, but I would do it general and not on a certain pattern.


i repeat, spamassassin cant test things in deep file content scanning, 
we loose


one way to solve is:

configure clamav-milter to accept all virus detected in clamav
make spamas-milter reject pattern for macro virus detected in clamav
and still reject virus in spamas-milter

or make a bug report to clamav-milter for more policy accept quarantine 
reject rules


by adding more 3dr party clamav signatures one dont need spamassassin 
:=)


the above is only possible if clamav multer is done before spamas-milter

if other tools is used it require more work to make work


Re: rule for docx o xlsx

2018-12-19 Thread Rick Gutierrez
El lun., 17 dic. 2018 a las 14:22, Benny Pedersen () escribió:

>
> why not block it with default clamav installs ?
>
> spamassassin is not a virus scanner or macro detector, i still have not
> seen rules in mimedefang or amavisd, or canit, and other tools support
> deep content scanners in spamassassin
>
> just my one €

Hi Benny,  I am not an expert in amavisd, but I have installed a few
and in the official documentation you can block this type of files or
extension, but I would do it general and not on a certain pattern.


-- 
rickygm

http://gnuforever.homelinux.com


Re: rule for docx o xlsx

2018-12-19 Thread Rick Gutierrez
El lun., 17 dic. 2018 a las 13:40, RW () escribió:

>
> Content-Type:
> application/vnd.openxmlformats-officedocument.wordprocessingml.document,
>
> doesn't contain msword|excel

Hi RW , you suggest me to make the modification?



-- 
rickygm

http://gnuforever.homelinux.com


Re: rule for docx o xlsx

2018-12-17 Thread David B Funk

On Mon, 17 Dec 2018, RW wrote:


On Mon, 17 Dec 2018 13:18:12 -0600
Rick Gutierrez wrote:


Hi list , happy holidays to all, I am trying to make this rule work
that a friend wrote in github, to be able to give a high score to
documents sent from different countries, like pakistan, china or india
, I have it in my spamassassin and I do not see it working, to see if
someone on the list helps me improve it

RuleWordORExcel.cf

mimeheader __MIME_WORDOREXCEL Content-Type =~ /msword|excel/i

...

https://pastebin.com/bmRq7v7h




Content-Type:
application/vnd.openxmlformats-officedocument.wordprocessingml.document,

doesn't contain msword|excel


Not to mention that rule doesn't match "Application/OCTET-STREAM"

All too often I see mail clients use the catch-all MimeTyping of 
"Application/OCTET-STREAM' and assume the recipient will 'do the right thing' 
based on the file extension.




--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{


Re: rule for docx o xlsx

2018-12-17 Thread Benny Pedersen

Rick Gutierrez skrev den 2018-12-17 20:18:


https://pastebin.com/bmRq7v7h


why not block it with default clamav installs ?

spamassassin is not a virus scanner or macro detector, i still have not 
seen rules in mimedefang or amavisd, or canit, and other tools support 
deep content scanners in spamassassin


just my one €


Re: rule for docx o xlsx

2018-12-17 Thread RW
On Mon, 17 Dec 2018 13:18:12 -0600
Rick Gutierrez wrote:

> Hi list , happy holidays to all, I am trying to make this rule work
> that a friend wrote in github, to be able to give a high score to
> documents sent from different countries, like pakistan, china or india
> , I have it in my spamassassin and I do not see it working, to see if
> someone on the list helps me improve it
> 
> RuleWordORExcel.cf
> 
> mimeheader __MIME_WORDOREXCEL Content-Type =~ /msword|excel/i
...
> https://pastebin.com/bmRq7v7h



Content-Type:
application/vnd.openxmlformats-officedocument.wordprocessingml.document,

doesn't contain msword|excel


Re: Rule for a link with an numeric IP in body?

2018-10-30 Thread Martin Gregorie
On Tue, 2018-10-30 at 13:56 +, RW wrote:
> 
> I was using 3.4.2
> 
> > simply appending /alphastring to the
> > bare IP caused it to be recognised by a URI rule. I was a little
> > surprised as I'd been expecting the httpd:// or https:// prefix
> > would
> > be required.
>
A thought: I wonder how many spammers put example.com/unsubscribe
rather than https://example.com/unsubscribe in the message body and so,
by inference would also use 127.0.0.1/unsubscribe rather than 
https://127.0.0.1/unsubscribe 

If this is what any of them do, then 3.4.2 should probably revert to
3.4.1 behaviour and recognise 111.222.333.444/somepathname as a URI.

Martin





Re: Rule for a link with an numeric IP in body?

2018-10-30 Thread RW
On Mon, 29 Oct 2018 20:19:15 +
Martin Gregorie wrote:

> On Mon, 2018-10-29 at 18:18 +, RW wrote:
> > On Mon, 29 Oct 2018 17:26:29 +
> > Martin Gregorie wrote:
> > 
> >   
> > > describe MG_BARE_IP Bare IP in a URI
> > > body __MG_BAI0 /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
> > > uri  __MG_BAI1 /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\/\w*/
> > > meta MG_BARE_IP (__MG_BAI0 || __MG_BAI1)
> > > scoreMG_BARE_IP 0.01
> > > 
> > > Note that the bare IP - n.n.n.n - is NOT a URI and so must be a
> > > body
> > > text rule while the bare IP with a '/name' suffix is a URI and so
> > > is
> > > found by a URI rule.   
> > 
> > What I'm seeing is that an IP address is only identified as a URI if
> > there is a protocol. Having a path doesn't matter.
> >  
> When I tested it here (SA 3.4.1), 

I was using 3.4.2

> simply appending /alphastring to the
> bare IP caused it to be recognised by a URI rule. I was a little
> surprised as I'd been expecting the httpd:// or https:// prefix would
> be required.


Re: Rule for a link with an numeric IP in body?

2018-10-29 Thread Martin Gregorie
On Mon, 2018-10-29 at 18:18 +, RW wrote:
> On Mon, 29 Oct 2018 17:26:29 +
> Martin Gregorie wrote:
> 
> 
> > describe MG_BARE_IP Bare IP in a URI
> > body __MG_BAI0 /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
> > uri  __MG_BAI1 /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\/\w*/
> > meta MG_BARE_IP (__MG_BAI0 || __MG_BAI1)
> > scoreMG_BARE_IP 0.01
> > 
> > Note that the bare IP - n.n.n.n - is NOT a URI and so must be a
> > body
> > text rule while the bare IP with a '/name' suffix is a URI and so
> > is
> > found by a URI rule. 
> 
> What I'm seeing is that an IP address is only identified as a URI if
> there is a protocol. Having a path doesn't matter.
>
When I tested it here (SA 3.4.1), simply appending /alphastring to the
bare IP caused it to be recognised by a URI rule. I was a little
surprised as I'd been expecting the httpd:// or https:// prefix would
be required.

Martin





Re: Rule for a link with an numeric IP in body?

2018-10-29 Thread RW
On Mon, 29 Oct 2018 14:53:51 -0500 (CDT)
David B Funk wrote:

> On Mon, 29 Oct 2018, Martin Gregorie wrote:
> 

> > Note that technical computing discussions may validly contain bare
> > IPs, e.g. 127.0.0.1 is never a spam indication since it is the IP of
> > 'localhost' and so its appearance is not a spam indication. There
> > are other well-known IPs that are also not spam indications.  
> 
> Not to mention all the other ways that dotted-number strings can be
> used; EG version numbers of sofware.

The OP wants to detect unsubscribe links using IP addresses, so this is
a non-issue.


Re: Rule for a link with an numeric IP in body?

2018-10-29 Thread David B Funk

On Mon, 29 Oct 2018, Martin Gregorie wrote:


On Mon, 2018-10-29 at 15:55 +0200, Anders Gustafsson wrote:

Is there such a rule already in 3.3.x? I would ideally want a version
of that that adds to the spam score if it sees a x.x.x.x/unsubscribe
link, possibly translated.


[snip..]


describe MG_BARE_IP Bare IP in a URI
body __MG_BAI0 /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
uri  __MG_BAI1 /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\/\w*/
meta MG_BARE_IP (__MG_BAI0 || __MG_BAI1)
scoreMG_BARE_IP 0.01

Note that the bare IP - n.n.n.n - is NOT a URI and so must be a body
text rule while the bare IP with a '/name' suffix is a URI and so is
found by a URI rule. This is why I used two subrules joined by the
meta-rule.

Note that technical computing discussions may validly contain bare IPs,
e.g. 127.0.0.1 is never a spam indication since it is the IP of
'localhost' and so its appearance is not a spam indication. There are
other well-known IPs that are also not spam indications.


Not to mention all the other ways that dotted-number strings can be used;
EG version numbers of sofware.

I have libwmf installed on my machine and if I was discussing a programming 
issue with it I might mention that the RPM I have is: 
libwmf-0_2-7-0.2.8.4-lp150.2.6.x86_64




--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{


Re: Rule for a link with an numeric IP in body?

2018-10-29 Thread RW
On Mon, 29 Oct 2018 17:26:29 +
Martin Gregorie wrote:


> describe MG_BARE_IP Bare IP in a URI
> body __MG_BAI0 /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
> uri  __MG_BAI1 /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\/\w*/
> meta MG_BARE_IP (__MG_BAI0 || __MG_BAI1)
> scoreMG_BARE_IP 0.01
> 
> Note that the bare IP - n.n.n.n - is NOT a URI and so must be a body
> text rule while the bare IP with a '/name' suffix is a URI and so is
> found by a URI rule. 

What I'm seeing is that an IP address is only identified as a URI if
there is a protocol. Having a path doesn't matter.


Sv: Re: Rule for a link with an numeric IP in body?

2018-10-29 Thread Anders Gustafsson
Thanks. I hd some issues installing 3.4, libc conflict IIRC so I Installed 3.3, 
but I have been planning to upgrade. I guess I will jut download the source 
tarball and build it on the system.


FWIW this system is not facing the internet. The MTA deposits incoming main 
into a folder where sa picks it up, processes and dumps into another, where the 
MTA picks it up.

Thanks for the ponters. I will have a peek.


>>> "Bill Cole"  2018-10-29 19:08 >>>
Do not run SpamAssassin 3.3.x. It is not safe. There have been multiple 
serious security bugs fixed in the 3.4.x series.



Re: Rule for a link with an numeric IP in body?

2018-10-29 Thread Martin Gregorie
On Mon, 2018-10-29 at 15:55 +0200, Anders Gustafsson wrote:
> Is there such a rule already in 3.3.x? I would ideally want a version
> of that that adds to the spam score if it sees a x.x.x.x/unsubscribe
> link, possibly translated.
> 
> Asking here as regexps are not really my strong side.
> 
Here's a (partially) tested rule that can spot two forms of bare IP.
The the rule given below the __MG_BAI0 subrule recognises plain IPs.
i.e. n.n.n.n and the __MG_BAI1 recognises URIs like your example, i.e. 
n.n.n.n/w :

describe MG_BARE_IP Bare IP in a URI
body __MG_BAI0 /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
uri  __MG_BAI1 /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\/\w*/
meta MG_BARE_IP (__MG_BAI0 || __MG_BAI1)
scoreMG_BARE_IP 0.01

Note that the bare IP - n.n.n.n - is NOT a URI and so must be a body
text rule while the bare IP with a '/name' suffix is a URI and so is
found by a URI rule. This is why I used two subrules joined by the
meta-rule.

Note that technical computing discussions may validly contain bare IPs,
e.g. 127.0.0.1 is never a spam indication since it is the IP of
'localhost' and so its appearance is not a spam indication. There are
other well-known IPs that are also not spam indications.

Martin




Re: Rule for a link with an numeric IP in body?

2018-10-29 Thread Bill Cole

On 29 Oct 2018, at 9:55, Anders Gustafsson wrote:


Is there such a rule already in 3.3.x?


Do not run SpamAssassin 3.3.x. It is not safe. There have been multiple 
serious security bugs fixed in the 3.4.x series.


However, the rules for 3.3.x and 3.4.x are identical.  And yes, the rule 
"NORMAL_HTTP_TO_IP" will catch http(s) URLs using dotted-quad IPs and 
"NUMERIC_HTTP_ADDR" will catch http(s) URLs using a single decimal 
number (which some resolvers will treat as an IP address)


I would ideally want a version of that that adds to the spam score if 
it sees a x.x.x.x/unsubscribe link, possibly translated.


IP_LINK_PLUS does something similar that could be adapted pretty easily.


Asking here as regexps are not really my strong side.


Well, if you look in the standard rule distribution (under 
/var/lib/spamassassin/ or somewhere similar, depending on your platform) 
you will find the file 20_uri_tests.cf, in which all of the standard 
URI-based rules are defined, many with comments. Even if you're not a 
wizard with regexps, you may be able to find rules there which you can 
adapt to your own needs with simple changes.


Re: Rule for multiple paragraphs

2018-09-18 Thread RW
On Tue, 18 Sep 2018 08:20:38 +0100
Marisa Clardy wrote:

> Hello,
> 
> How I'd do it is with this regex:
> 
> /^(apache(\r|\n)+)+$/s

Owing to the way the normalized body is stored, this kind of thing won't
work with body rules - that's what the thread is about. It can work with
rawbody rules, but they have problems of their own.

> The 's' flag would be necessary here.

It wouldn't since there's no '.' in the rule.

>  Technically there should always be a single \r\n at the end of the
> line,

That's required during an SMTP transaction, but emails are usually
converted to native format before being stored. Most SpamAssassin rules
operate on derived data stored with native line endings.


  1   2   3   4   5   6   7   8   9   10   >