Re: regexp dealing with display name don't work

[John Hardin]

On Thu, 26 Apr 2018, Joelle wrote:


Hello,

I want to block e-mails with a sender display name containing given strings.

All my rules of the type ;
From:name =~ /string/
don't work

On the other side,
rules of the type :
From:addr =~ /string/
work

and rules of the type

From =~ /string/

work only if string lies in the address part of the From field

What must I do to filter e-mails on the display name ?


Firstly, please provide some examples of complete From: headers that you 
want to match. Please don't change them in any way.


Secondly, your first example is case-sensitive. Is it possible that your 
RE and the actual header display name you want to match differ in case?


--
 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
---
  From the Liberty perspective, it doesn't matter if it's a
  jackboot or a Birkenstock smashing your face. -- Robb Allen
---
 5 days until May Day - Remember 110 million people murdered by Communism

regexp dealing with display name don't work

[Joelle]

Hello,

I want to block e-mails with a sender display name containing given strings.

All my rules of the type ;
From:name =~ /string/
don't work

On the other side,
rules of the type :
From:addr =~ /string/
work

and rules of the type
>From =~ /string/
work only if string lies in the address part of the From field

What must I do to filter e-mails on the display name ?



--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html

Re: Why emails relayedfrom trusted/internal networks trigger rules?

[RW]

On Thu, 26 Apr 2018 16:21:01 -0400
Bill Cole wrote:

> On 26 Apr 2018, at 3:04 (-0400), Palvelin Postmaster wrote:
> 

> > Received: ⁨by palvelin.fi (CommuniGate Pro PIPE 6.2.3)  
> 
> That may be your first problem. SA can't parse that as a proper
> Received header, which may trigger it to not classify the rest of the
> Received headers correctly.


Aside from disabling ALL_TRUSTED, unparseable received headers are
simply ignored. Actually I think that pattern is parsed as a header
that should be explicitly skipped.


> At this point, SA should have already given up parsing Received
> headers so the fact that this and the remaining Received headers use
> RFC1918 IPs and a generic name in a non-resolvable domain doesn't
> matter: SA cannot trust these because the chain of trust and working
> DNS is already broken.

The headers do parse correctly provided that you remove the invisible
unicode isolates in the email text. They presumably weren't present at
the time of the scan or no IP addresses would have been found. 

Everything here is consistent with the OP leaving-out 172.16.0.0/12 from
from the trusted/internal networks.

Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")

[Bill Cole]

On 26 Apr 2018, at 16:41 (-0400), L A Walsh wrote:


To my way of thinking, dropping someone else's email,
telling the sender the email is being rejected for having
spam-like characteristics and telling the recipient nothing
seems like it might have legal liability for the for the
user potentially missing vital email.


Not so much, at least not in the US, Canada, or the EU. There are safe 
harbor provisions in the relevant laws (e.g. COPPA and CAN-SPAM in the 
US) protecting service providers from liability for errors in their good 
faith efforts at filtering out harmful material. Beyond that, email end 
users typically have a business relationship only with their immediate 
service provider to whom they first submit a message, NOT with any 
intermediaries between their provider and the ultimate recipient 
end-user. Internet email is a loose store-and-forward system. A 
message's transport path usually has 3 transactions involved (but often 
more) with usually exactly 1 of those being governed by no specific law 
or any contract between the parties involved. At that interface, only 
courtesy and pragmatic interoperability concerns govern, and it provides 
a wall between the parties accountable to the sender and those 
accountable to the recipient. NO party involved in normal cross-provider 
email transport has obligations to both end users.


It also would seem to violate what used to be a basic expectation of 
internet email -- that it is either delivered

to the recipient's inbox OR you'll receive a
non-delivery notification (a "bounce").


How is being told using a standard mechanism during initial submission 
that the mail is rejected by a spam filter not the operational 
equivalent of a bounce message? That is precisely the mechanism that 
would cause an intermediary MTA to construct and send a non-delivery 
notification message.


It has ALWAYS been true for the entire existence of SMTP (and of its 
relatively new "Message Submission" subset) that the server side of a 
SMTP transaction can reject the transaction at any step and that the 
client side has the only duty to notify anyone and that it should ONLY 
notify the sender, NOT the recipient.



Furthermore, for me, about 20-25% of the email lists I used
to be on have policies to drop subscribers w/o notice if an
email cannot be delivered.


[ examples of how various entities do good, bad, or no notification 
elided... ]



I hope some of those who think it was a good practice to
delete a user's email (because they think it is malware)
might rethink that practice.


There is a huge difference between deleting stored delivered mail and 
refusing to accept deliver mail.



I didn't realize email was no longer considered unreliable
primarily due to spam scanning.


For the entire history of the Internet, cross-domain email has been an 
intrinsically unreliable means of communication. Whoever made you think 
otherwise deceived you.



I wonder if that will
happen for USPS letters: getting permanently dropped due
to the envelop having SPAM-like characteristics (like
most bulk mail).


USPS is a government entity with special privileges and duties defined 
in law and/or by regulations promulgated to implement the governing law. 
They handle every step of delivery from sender to recipient and are 
prepaid by every sender to perform end-to-end delivery.


In most of the Internet-heavy world, no email provider has any of those 
supporting features of reliability, even within their own home nations.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: Anti Phish Rules

[David Jones]

MailScanner became very mature and didn't need any major updates for years then 
Jules turned it over to Jerry Benton who had a commercial product based on it.  
It's still being updated and runs fine now on systemd-based OSes and newer 
versions of Perl.  One of our customers, Shawn Iversion, is helping Jerry 
maintain MailScanner now as part of his EFA project.  https://efa-project.org/


From: Kevin Miller 
Sent: Thursday, April 26, 2018 4:16 PM
To: users@spamassassin.apache.org
Subject: RE: Anti Phish Rules


It’s not abandonware – Jules handed it off to some other folks that are 
actively putting out new versions.  As a matter of fact one came out not too 
long ago.  MailWatch for MailScanner is also being actively developed still.

Latest/greatest is available at 
www.mailscanner.info for anyone wanting to check 
it out.



...Kevin

--

Kevin Miller

Network/email Administrator, CBJ MIS Dept.

155 South Seward Street

Juneau, Alaska 99801

Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357



From: Noel Butler [mailto:noel.but...@ausics.net]
Sent: Thursday, April 26, 2018 12:51 PM
To: users@spamassassin.apache.org
Subject: Re: Anti Phish Rules



On 26/04/2018 18:12, Matus UHLAR - fantomas wrote:

On 26.04.18 18:00, Nick Edwards wrote:

We've been using a separate product to do this, but it struck me, maybe
spamassassin can do this easier (or without having to call yet another
binary to run as can over mails)

Rules that look at URLs in a html message  href and src tags, check the "A"
tag to see if there is a URL there, and if they do not match,  consider it
a phis so apply said phis score to the message.

Has anyone done this? module even?

the main problem: may non-spam senders do that, see:

https://wiki.apache.org/spamassassin/AntiPhishFakeUrlRule

and further the discussion in linked bug:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=4255





I suspect Nick is still using and referring to mailscanner (which is/was 
written in perl), it has/had this ability, I (like a good few of the names 
around here) used it back in the day as well, until it became clear it was 
abandonware, and did not like certain newer versions of perl causing exits 
after each scan, mind you, I did dump it for amavisd back around 2008/9/10, 
that said I liked that function, and rarely noticed any FP's, my memorys hazy, 
but IIRC, it disarmed the links, rather than take any scoring action... I might 
be wrong though, like I said, its been along time.



--

Kind Regards,

Noel Butler

This Email, including any attachments, may contain legally privileged 
information, therefore remains confidential and subject to copyright protected 
under international law. You may not disseminate, discuss, or reveal, any part, 
to anyone, without the authors express written authority to do so. If you are 
not the intended recipient, please notify the sender then delete all copies of 
this message including attachments, immediately. Confidentiality, copyright, 
and legal privilege are not waived or lost by reason of the mistaken delivery 
of this message. Only PDF and 
ODF documents accepted, please do 
not send proprietary formatted documents

RE: Anti Phish Rules

[Kevin Miller]

It’s not abandonware – Jules handed it off to some other folks that are 
actively putting out new versions.  As a matter of fact one came out not too 
long ago.  MailWatch for MailScanner is also being actively developed still.
Latest/greatest is available at 
www.mailscanner.info for anyone wanting to check 
it out.

...Kevin
--
Kevin Miller
Network/email Administrator, CBJ MIS Dept.
155 South Seward Street
Juneau, Alaska 99801
Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357

From: Noel Butler [mailto:noel.but...@ausics.net]
Sent: Thursday, April 26, 2018 12:51 PM
To: users@spamassassin.apache.org
Subject: Re: Anti Phish Rules


On 26/04/2018 18:12, Matus UHLAR - fantomas wrote:
On 26.04.18 18:00, Nick Edwards wrote:
We've been using a separate product to do this, but it struck me, maybe
spamassassin can do this easier (or without having to call yet another
binary to run as can over mails)

Rules that look at URLs in a html message  href and src tags, check the "A"
tag to see if there is a URL there, and if they do not match,  consider it
a phis so apply said phis score to the message.

Has anyone done this? module even?

the main problem: may non-spam senders do that, see:

https://wiki.apache.org/spamassassin/AntiPhishFakeUrlRule

and further the discussion in linked bug:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=4255





I suspect Nick is still using and referring to mailscanner (which is/was 
written in perl), it has/had this ability, I (like a good few of the names 
around here) used it back in the day as well, until it became clear it was 
abandonware, and did not like certain newer versions of perl causing exits 
after each scan, mind you, I did dump it for amavisd back around 2008/9/10, 
that said I liked that function, and rarely noticed any FP's, my memorys hazy, 
but IIRC, it disarmed the links, rather than take any scoring action... I might 
be wrong though, like I said, its been along time.

--

Kind Regards,

Noel Butler
This Email, including any attachments, may contain legally privileged 
information, therefore remains confidential and subject to copyright protected 
under international law. You may not disseminate, discuss, or reveal, any part, 
to anyone, without the authors express written authority to do so. If you are 
not the intended recipient, please notify the sender then delete all copies of 
this message including attachments, immediately. Confidentiality, copyright, 
and legal privilege are not waived or lost by reason of the mistaken delivery 
of this message. Only PDF and 
ODF documents accepted, please do 
not send proprietary formatted documents

Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")

[Alan Hodgson]

On Thu, 2018-04-26 at 13:41 -0700, L A Walsh wrote:
> To my way of thinking, dropping someone else's email,
> telling the sender the email is being rejected for having
> spam-like characteristics and telling the recipient nothing
> seems like it might have legal liability for the for the
> user potentially missing vital email.
> 
> It also would seem to violate what used to be a basic 
> expectation of internet email -- that it is either delivered
> to the recipient's inbox OR you'll receive a
> non-delivery notification (a "bounce").

Rejecting the message during receipt causes the sending server to
generate a bounce. If it's at all functional.

Re: Anti Phish Rules

[Noel Butler]

On 26/04/2018 18:12, Matus UHLAR - fantomas wrote:

> On 26.04.18 18:00, Nick Edwards wrote: 
> 
>> We've been using a separate product to do this, but it struck me, maybe
>> spamassassin can do this easier (or without having to call yet another
>> binary to run as can over mails)
>> 
>> Rules that look at URLs in a html message  href and src tags, check the "A"
>> tag to see if there is a URL there, and if they do not match,  consider it
>> a phis so apply said phis score to the message.
>> 
>> Has anyone done this? module even?
> 
> the main problem: may non-spam senders do that, see:
> 
> https://wiki.apache.org/spamassassin/AntiPhishFakeUrlRule
> 
> and further the discussion in linked bug:
> 
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=4255

I suspect Nick is still using and referring to mailscanner (which is/was
written in perl), it has/had this ability, I (like a good few of the
names around here) used it back in the day as well, until it became
clear it was abandonware, and did not like certain newer versions of
perl causing exits after each scan, mind you, I did dump it for amavisd
back around 2008/9/10, that said I liked that function, and rarely
noticed any FP's, my memorys hazy, but IIRC, it disarmed the links,
rather than take any scoring action... I might be wrong though, like I
said, its been along time.

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")

[L A Walsh]

To my way of thinking, dropping someone else's email,
telling the sender the email is being rejected for having
spam-like characteristics and telling the recipient nothing
seems like it might have legal liability for the for the
user potentially missing vital email.

It also would seem to violate what used to be a basic 
expectation of internet email -- that it is either delivered

to the recipient's inbox OR you'll receive a
non-delivery notification (a "bounce").

Furthermore, for me, about 20-25% of the email lists I used
to be on have policies to drop subscribers w/o notice if an
email cannot be delivered.

Some, ~10-15% will drop your email address from all lists hosted on
the server.

Some ~20-25% will send out some sort of probe or notification
of missed messages, many claiming you need to respond to
a notice:
  Your membership in the mailing list XXX has been disabled
  due to excessive bounces The last bounce received from you was
  dated 01-Jan-2017.  You will not get any more messages from this
  list until you re-enable your membership.  You will receive
  3 more reminders like this before your membership in the list is
  deleted.


Some simply inform you of missed messages. Only "ezmlm" gave 
some clue allowing me to track what was happening w/a

message like:
  Subject: failure notice

  Hi. This is qmail. [not able to deliver.  Permanent error.]
   failed. 
  
  Remote host said: 
  550 5.7.1 This message has been blocked for containing

  SPAM-like characteristics.


Some were notifications of a response to a message I
posted in a forum -- an automated form, but certainly not
spam or malware.  None of the ones I was able to find
copies of (went to a list-archive), were spam or malware.

The most troublesome are those lists who auto-drop you for
a bounced message (like the linux-kernel mailing list
and other high-volume lists).  



Ironically (or maliciously), anytime I've brought a problem
like this to a MSP's support staff, I'm inevitably asked for 
a copy of the email or its headers.  I can't provide what 
never reached me.  Then they'll respond that they can't

do anything without a copy of the rejected email (as though
they only work with user emails that were outgoing or 
something).



If it is a 'MSP', I'd hope they'd act more responsibly 
with emails.  


Of note: in my case, I was often told that I could diable
filtering in my account options (it was disabled & had never
been enabled).  All of the front-line support
people I've talked to have had no idea that email was also
being filtered on the incoming server, so of course they
had a problem wrapping their head around what was happening
and even though I've been told more than once that filtering
was turned off for my account -- it eventually continues.

Another reason I have asked about this is that if the email
is in an alternate encoding, they decode it to check it and 
place the decoded version in my mail stream.  Unfortunately

they don't do it right with the result that problems occur
on my email client (T-bird) with the improperly decoded 
email (since I don't have the original, I can't tell exactly

why it is bad).

I hope some of those who think it was a good practice to
delete a user's email (because they think it is malware)
might rethink that practice.  


I didn't realize email was no longer considered unreliable
primarily due to spam scanning.  I wonder if that will
happen for USPS letters: getting permanently dropped due
to the envelop having SPAM-like characteristics (like
most bulk mail).

Thanks for the hints on the headers...

-linda

 

Re: Why emails relayedfrom trusted/internal networks trigger rules?

[Bill Cole]

On 26 Apr 2018, at 3:04 (-0400), Palvelin Postmaster wrote:


Hi,

I relay mail from another server to my main mail server. I have set 
its IP 52.28.104.67 in my spamassassin conf in the internal_networks 
and trusted_networks. I assumed that would prevent spamassassin from 
scanning the messages but no. Why does this happen?


Even when SA can recognize that a message is coming via only trusted 
systems, by default it does not exempt the message from other scanning, 
it simply hits the ALL_TRUSTED rule. That rule normally has a 
significant negative score itself and is used to prevent matching in 
many 'meta' rules.



X-Spam-Status: ⁨Yes, score=6.1 required=5.0 
tests=AWL,DKIM_ADSP_NXDOMAIN, 
HELO_DYNAMIC_IPADDR,NO_DNS_FOR_FROM,RDNS_DYNAMIC,T_RP_MATCHES_RCVD 
autolearn=disabled version=3.4.1⁩


Since proper determination of the "X-Spam-Relays-*" pseudo-headers 
controls most of those hits as well as ALL_TRUSTED, getting that fixed 
will almost surely be adequate. It will also help with other rules that 
depend on identifying the boundaries between internal vs. external 
and/or trusted vs. untrusted Received headers.



Received: ⁨by palvelin.fi (CommuniGate Pro PIPE 6.2.3)


That may be your first problem. SA can't parse that as a proper Received 
header, which may trigger it to not classify the rest of the Received 
headers correctly. It's hard to tell if this is causing trouble in this 
case, because there are problems with the rest as well. With that said, 
if you can make CGP use SA via an external filter rather than delivering 
through the PIPE module, you'll get a more robust and performant 
solution without this oddball Received header. For the 8+ years I ran 
CGP systems, I used the free cgpav filter, but for modern CGP that needs 
some patching to work. I seem to recall that cgpsa is also a free tool 
that works.


Received: ⁨from [52.28.104.67] (HELO 
ip-172-31-20-213.eu-central-1.compute.internal) by palvelin.fi 
(CommuniGate Pro SMTP 6.2.3) with ESMTPS id 10108357 for 
i...@.com; Mon, 23 Apr 2018 06:35:44 +0300⁩


The Postfix MTA running on the AWS instance using 52.28.104.67 is 
grossly misconfigured. It should use a EHLO/HELO name ( myhostname, or 
smtp_helo_name if there's a reason myhostname can't be changed) that 
resolves to 52.28.104.67 and also should have proxy_interfaces set to 
52.28.104.67. It appears that 
ec2-52-28-104-67.eu-central-1.compute.amazonaws.com would be a good 
choice, but if that machine talks to anyone else you may want to post a 
non-generic name at the IP and use that.


Received: ⁨from ip-172-31-26-125.eu-central-1.compute.internal 
(ip-172-31-26-125.eu-central-1.compute.internal [172.31.26.125]) by 
ip-172-31-20-213.eu-central-1.compute.internal (Postfix) with ESMTP id 
ECF2CC0C32 for ; Mon, 23 Apr 2018 06:35:43 +0300 
(EEST)⁩


At this point, SA should have already given up parsing Received headers 
so the fact that this and the remaining Received headers use RFC1918 IPs 
and a generic name in a non-resolvable domain doesn't matter: SA cannot 
trust these because the chain of trust and working DNS is already 
broken.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: Why emails relayedfrom trusted/internal networks trigger rules?

[RW]

On Thu, 26 Apr 2018 10:04:32 +0300
Palvelin Postmaster wrote:

> Hi,
> 
> I relay mail from another server to my main mail server. I have set
> its IP 52.28.104.67 in my spamassassin conf in the internal_networks
> and trusted_networks. I assumed that would prevent spamassassin from
> scanning the messages but no. Why does this happen?

internal_networks and trusted_networks aren't there to avoid scanning
(although there is an ALL_TRUSTED rule with a negative score), they are
there to help SA determine which relays are relevant to certain tests. 

However, HELO_DYNAMIC_IPADDR and RDNS_DYNAMIC shouldn't be there if
your network settings are correct.

You mention listing 52.28.104.67, but not 172.16.0.0/12.  When you
specify internal or trusted networks you then have to include any
relevant RFC 1918 address blocks. 

Re: Warning while running spam assasin on the message

[jkon]

I have a similar problem. I use spamassassin on Centos 7, which worked well
until updating all packages to the latest versions. Now I have spamassassin
ver. 3.4.0 and when I run "spamassassin --mbox < spam", where mbox spam
contains one message, it writes for example:
Apr 26 17:04:10.072 [28581] warn: netset: cannot include 127.0.0.0/8 as it
has already been included
Apr 26 17:04:10.868 [28581] warn: Useless use of a constant (1) in void
context at (eval 1288) line 10.
Apr 26 17:04:10.868 [28581] warn: Useless use of a constant (1) in void
context at (eval 1289) line 10.
Apr 26 17:04:10.868 [28581] warn: Useless use of a constant (1) in void
context at (eval 1290) line 10.
Apr 26 17:04:10.873 [28581] warn: Useless use of a constant (1) in void
context at (eval 1291) line 10.
Apr 26 17:04:10.873 [28581] warn: Useless use of a constant (1) in void
context at (eval 1292) line 10.
Apr 26 17:04:10.874 [28581] warn: Useless use of a constant (1) in void
context at (eval 1293) line 10.
Apr 26 17:04:10.874 [28581] warn: Useless use of a constant (1) in void
context at (eval 1294) line 10.
Apr 26 17:04:10.874 [28581] warn: Useless use of a constant (1) in void
context at (eval 1295) line 10.
Apr 26 17:04:10.874 [28581] warn: Useless use of a constant (1) in void
context at (eval 1296) line 10.
Apr 26 17:04:10.875 [28581] warn: Useless use of a constant (1) in void
context at (eval 1297) line 10.
Apr 26 17:04:10.875 [28581] warn: Useless use of a constant (1) in void
context at (eval 1298) line 10.
Apr 26 17:04:10.875 [28581] warn: Useless use of a constant (1) in void
context at (eval 1299) line 10.
Apr 26 17:04:10.875 [28581] warn: Useless use of a constant (1) in void
context at (eval 1300) line 10.
Apr 26 17:04:10.875 [28581] warn: Useless use of a constant (1) in void
context at (eval 1301) line 10.
Apr 26 17:04:10.876 [28581] warn: Useless use of a constant (1) in void
context at (eval 1302) line 10.
Apr 26 17:04:10.876 [28581] warn: Useless use of a constant (1) in void
context at (eval 1303) line 10.
Apr 26 17:04:10.876 [28581] warn: Useless use of a constant (1) in void
context at (eval 1304) line 10.
Apr 26 17:04:10.876 [28581] warn: Useless use of a constant (1) in void
context at (eval 1305) line 10.
Apr 26 17:04:10.877 [28581] warn: Useless use of a constant (1) in void
context at (eval 1306) line 10.
Apr 26 17:04:10.877 [28581] warn: Useless use of a constant (1) in void
context at (eval 1307) line 10.
Apr 26 17:04:10.877 [28581] warn: Useless use of a constant (1) in void
context at (eval 1308) line 10.
Apr 26 17:04:10.877 [28581] warn: Useless use of a constant (1) in void
context at (eval 1309) line 10.
Apr 26 17:04:10.878 [28581] warn: Useless use of a constant (1) in void
context at (eval 1310) line 10.
Apr 26 17:04:10.878 [28581] warn: Useless use of a constant (1) in void
context at (eval 1311) line 10.
Apr 26 17:04:10.878 [28581] warn: Useless use of a constant (1) in void
context at (eval 1312) line 10.
Apr 26 17:04:10.878 [28581] warn: Useless use of a constant (1) in void
context at (eval 1313) line 10.
Apr 26 17:04:10.879 [28581] warn: Useless use of a constant (1) in void
context at (eval 1314) line 10.
Apr 26 17:04:10.879 [28581] warn: Useless use of a constant (1) in void
context at (eval 1315) line 10.
Apr 26 17:04:10.879 [28581] warn: Useless use of a constant (1) in void
context at (eval 1316) line 10.
Apr 26 17:04:10.879 [28581] warn: Useless use of a constant (1) in void
context at (eval 1317) line 10.
Apr 26 17:04:10.880 [28581] warn: Useless use of a constant (1) in void
context at (eval 1318) line 10.
Apr 26 17:04:10.880 [28581] warn: Useless use of a constant (1) in void
context at (eval 1319) line 10.
Apr 26 17:04:10.880 [28581] warn: Useless use of a constant (1) in void
context at (eval 1320) line 10.
Apr 26 17:04:10.881 [28581] warn: Useless use of a constant (1) in void
context at (eval 1321) line 10.
Apr 26 17:04:10.881 [28581] warn: Useless use of a constant (1) in void
context at (eval 1322) line 10.
Apr 26 17:04:10.881 [28581] warn: Useless use of a constant (1) in void
context at (eval 1323) line 10.
Apr 26 17:04:10.881 [28581] warn: Useless use of a constant (1) in void
context at (eval 1324) line 10.
Apr 26 17:04:10.882 [28581] warn: Useless use of a constant (1) in void
context at (eval 1325) line 10.
Apr 26 17:04:10.882 [28581] warn: Useless use of a constant (1) in void
context at (eval 1326) line 10.
Apr 26 17:04:10.882 [28581] warn: Useless use of a constant (1) in void
context at (eval 1327) line 10.
Apr 26 17:04:10.882 [28581] warn: Useless use of a constant (1) in void
context at (eval 1328) line 10.
Apr 26 17:04:10.882 [28581] warn: Useless use of a constant (1) in void
context at (eval 1329) line 10.
Apr 26 17:04:10.883 [28581] warn: Useless use of a constant (1) in void
context at (eval 1330) line 10.
Apr 26 17:04:10.885 [28581] warn: Use of uninitialized value $rr_type in
string eq at /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/AskDNS.pm
line 59

Re: Anti Phish Rules

[David Jones]

That was for a specific spoofing campaign so remove it if you want.  That was 
only an example to show what can be done to pair up with 
whitelist_auth/whitelist_dkim entries.  I would not put that particular one in 
the core SA ruleset if there was enough interest to add this rule.


I also have a rule just like this with full names of spoofing targets like CEOs 
and finance people to block fake requests to transfer money or click a link.


From: sha...@shanew.net 
Sent: Thursday, April 26, 2018 10:01 AM
To: users@spamassassin.apache.org
Subject: Re: Anti Phish Rules

On Thu, 26 Apr 2018, David Jones wrote:

> header  __BAD_FROM_NAME From:name =~
> /(^chase$|chase\.com|Internal Revenue Service|banking|Bank of
> America|American Express|Wells Fargo|NavyFederal|Geico|E-fax|Share.oint|UPS
> Delivery|FedEx|PayPal|Apple Support|USAA|.ropbox|Dro.box)/i
> metaBAD_FROM_NAME   __BAD_FROM_NAME && !ALL_TRUSTED
> describe  BAD_FROM_NAME   Displayed From contains bad information to
> trick the recipients
> score   BAD_FROM_NAME   4.0

People named Chase may not care for that first item in the grouping

--
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: Anti Phish Rules

[shanew]

On Thu, 26 Apr 2018, David Jones wrote:


header          __BAD_FROM_NAME     From:name =~
/(^chase$|chase\.com|Internal Revenue Service|banking|Bank of
America|American Express|Wells Fargo|NavyFederal|Geico|E-fax|Share.oint|UPS
Delivery|FedEx|PayPal|Apple Support|USAA|.ropbox|Dro.box)/i
meta            BAD_FROM_NAME       __BAD_FROM_NAME && !ALL_TRUSTED
describe      BAD_FROM_NAME       Displayed From contains bad information to
trick the recipients
score           BAD_FROM_NAME       4.0


People named Chase may not care for that first item in the grouping

--
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: Anti Phish Rules

[David Jones]

I have a local rule that adds a few points for commonly spoofed companies like 
Paypal, Bank of America, Chase, Fedex, etc. since all of these will have good 
SPF/DKIM and now have def_whitelist_auth entries in the 60_whitelist_auth.cf.


Maybe we need to consider putting these in the SA core ruleset to help 
everyone.  The problem is that once we publish the exact rules for everyone 
running sa-update, then the spammers just start spoofing new companies.  At 
least it does help stop many of the common spoofing emails.


header  __BAD_FROM_NAME From:name =~ /(^chase$|chase\.com|Internal 
Revenue Service|banking|Bank of America|American Express|Wells 
Fargo|NavyFederal|Geico|E-fax|Share.oint|UPS Delivery|FedEx|PayPal|Apple 
Support|USAA|.ropbox|Dro.box)/i
metaBAD_FROM_NAME   __BAD_FROM_NAME && !ALL_TRUSTED
describe  BAD_FROM_NAME   Displayed From contains bad information to 
trick the recipients
score   BAD_FROM_NAME   4.0

You need to make sure any company name above has a whitelist_auth or 
whitelist_dkim entry for their real emails.

Dave



From: Emanuel Gonzalez 
Sent: Thursday, April 26, 2018 7:08 AM
To: Matus UHLAR - fantomas; users@spamassassin.apache.org
Subject: Re: Anti Phish Rules


Here is an example of an phishing email:

Authentication-Results: spf=none (sender IP is 200.58.117.126)
 smtp.mailfrom=ppl3.com; hotmail.com; dkim=fail (body hash did not verify)
 header.d=c0800455.domain.com;hotmail.com; dmarc=none action=none
 header.from=ppl3.com;
Received-SPF: None (protection.outlook.com: ppl3.com does not designate
 permitted sender hosts)
Received: from smht-x-x.domain.com (200.58.117.126) by
 DB5EUR03FT006.mail.protection.outlook.com (10.152.20.106) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
 15.20.696.11 via Frontend Transport; Thu, 26 Apr 2018 10:22:41 +
X-IncomingTopHeaderMarker: 
OriginalChecksum:BC2CEE5C26E95CD829053392BF062A8A8EF5B80B38721334E4D422793F5D4711;UpperCasedChecksum:DBAACD04967E0EBE075BAE00C7F9A355386276A19553DE2D32FBB1B903C63A0B;SizeAsReceived:3262;Count:21
Received: from c00.domain.com (c00 [172.x.x.x])
by smarthost.domain.com (Postfix) with ESMTPS id 4FC2A2A24
for ; Thu, 26 Apr 2018 07:22:39 -0300 (-03)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=c0800455.domain; s=mail; h=Content-Transfer-Encoding:Content-Type:

MIME-Version:Date:Subject:To:From:Message-ID:Sender:Reply-To:Cc:Content-ID:

Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc

:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=LUcrH5hRyj2Ujx36ZGDIENRVn7MtrTTfammZnXLJGrg=; 
b=RXl8e5v1c/TQQo/kLRo+tyg4VA

54BiXbsaC0z2TFM3dMDf4uNZpILl2RXYzhwcKptr9UVm+LQHUXW9UJmdqXKywlisZXyyJtk4U5KSP
LcaKmcWO+d9HwQWLY3MeDjBT4iw4xEiEeVN4Myra1K8Mf8Pfs3U42IqPHJWF4lLVPSeo=;
Received: from [105.155.80.137] (helo=Abdo-PC)
by c000.domain.com with esmtpsa (TLSv1:EDH-RSA-DES-CBC3-SHA:168)
(Exim 4.87_1)
(envelope-from )
id 1fBe2q-0006i7-4d
for mkch...@hotmail.com; Thu, 26 Apr 2018 07:22:39 -0300
Message-ID: <0364314f-43216-021f47358625@abdo-pc>
From: PayPal Inc 


Could you apply some verification for the signature dkim? I'm working in it




De: Matus UHLAR - fantomas 
Enviado: jueves, 26 de abril de 2018 5:12:05
Para: users@spamassassin.apache.org
Asunto: Re: Anti Phish Rules

On 26.04.18 18:00, Nick Edwards wrote:
>We've been using a separate product to do this, but it struck me, maybe
>spamassassin can do this easier (or without having to call yet another
>binary to run as can over mails)
>
>Rules that look at URLs in a html message  href and src tags, check the "A"
>tag to see if there is a URL there, and if they do not match,  consider it
>a phis so apply said phis score to the message.
>
>Has anyone done this? module even?

the main problem: may non-spam senders do that, see:

https://wiki.apache.org/spamassassin/AntiPhishFakeUrlRule

and further the discussion in linked bug:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=4255

--
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.
Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...

Re: anyone recognize these headers? From SA or are they from another spam product?

[@lbutlr]

On 2018-04-24 (18:10 MDT), L A Walsh  wrote:
> 
> What email SW censors things by rejecting them before accepting them?

As other have said, the proper behavior for any mail server is to reject mail 
that is not desired. This may because of spam, size, types of attachments, 
origin, or even virus/malware scanning.

On my mail server, 97% of the connections are rejected (or dropped) before mail 
is accepted.

-- 
Puny god!

Re: Anti Phish Rules

[Emanuel Gonzalez]

Here is an example of an phishing email:

Authentication-Results: spf=none (sender IP is 200.58.117.126)
 smtp.mailfrom=ppl3.com; hotmail.com; dkim=fail (body hash did not verify)
 header.d=c0800455.domain.com;hotmail.com; dmarc=none action=none
 header.from=ppl3.com;
Received-SPF: None (protection.outlook.com: ppl3.com does not designate
 permitted sender hosts)
Received: from smht-x-x.domain.com (200.58.117.126) by
 DB5EUR03FT006.mail.protection.outlook.com (10.152.20.106) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
 15.20.696.11 via Frontend Transport; Thu, 26 Apr 2018 10:22:41 +
X-IncomingTopHeaderMarker: 
OriginalChecksum:BC2CEE5C26E95CD829053392BF062A8A8EF5B80B38721334E4D422793F5D4711;UpperCasedChecksum:DBAACD04967E0EBE075BAE00C7F9A355386276A19553DE2D32FBB1B903C63A0B;SizeAsReceived:3262;Count:21
Received: from c00.domain.com (c00 [172.x.x.x])
by smarthost.domain.com (Postfix) with ESMTPS id 4FC2A2A24
for ; Thu, 26 Apr 2018 07:22:39 -0300 (-03)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=c0800455.domain; s=mail; h=Content-Transfer-Encoding:Content-Type:

MIME-Version:Date:Subject:To:From:Message-ID:Sender:Reply-To:Cc:Content-ID:

Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc

:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=LUcrH5hRyj2Ujx36ZGDIENRVn7MtrTTfammZnXLJGrg=; 
b=RXl8e5v1c/TQQo/kLRo+tyg4VA

54BiXbsaC0z2TFM3dMDf4uNZpILl2RXYzhwcKptr9UVm+LQHUXW9UJmdqXKywlisZXyyJtk4U5KSP
LcaKmcWO+d9HwQWLY3MeDjBT4iw4xEiEeVN4Myra1K8Mf8Pfs3U42IqPHJWF4lLVPSeo=;
Received: from [105.155.80.137] (helo=Abdo-PC)
by c000.domain.com with esmtpsa (TLSv1:EDH-RSA-DES-CBC3-SHA:168)
(Exim 4.87_1)
(envelope-from )
id 1fBe2q-0006i7-4d
for mkch...@hotmail.com; Thu, 26 Apr 2018 07:22:39 -0300
Message-ID: <0364314f-43216-021f47358625@abdo-pc>
From: PayPal Inc 


Could you apply some verification for the signature dkim? I'm working in it




De: Matus UHLAR - fantomas 
Enviado: jueves, 26 de abril de 2018 5:12:05
Para: users@spamassassin.apache.org
Asunto: Re: Anti Phish Rules

On 26.04.18 18:00, Nick Edwards wrote:
>We've been using a separate product to do this, but it struck me, maybe
>spamassassin can do this easier (or without having to call yet another
>binary to run as can over mails)
>
>Rules that look at URLs in a html message  href and src tags, check the "A"
>tag to see if there is a URL there, and if they do not match,  consider it
>a phis so apply said phis score to the message.
>
>Has anyone done this? module even?

the main problem: may non-spam senders do that, see:

https://wiki.apache.org/spamassassin/AntiPhishFakeUrlRule

and further the discussion in linked bug:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=4255

--
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.
Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...

Re: Anti Phish Rules

[Matus UHLAR - fantomas]

On 26.04.18 18:00, Nick Edwards wrote:

We've been using a separate product to do this, but it struck me, maybe
spamassassin can do this easier (or without having to call yet another
binary to run as can over mails)

Rules that look at URLs in a html message  href and src tags, check the "A"
tag to see if there is a URL there, and if they do not match,  consider it
a phis so apply said phis score to the message.

Has anyone done this? module even?


the main problem: may non-spam senders do that, see:

https://wiki.apache.org/spamassassin/AntiPhishFakeUrlRule

and further the discussion in linked bug:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=4255

--
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.
Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...

Anti Phish Rules

[Nick Edwards]

Hi,

We've been using a separate product to do this, but it struck me, maybe
spamassassin can do this easier (or without having to call yet another
binary to run as can over mails)

Rules that look at URLs in a html message  href and src tags, check the "A"
tag to see if there is a URL there, and if they do not match,  consider it
a phis so apply said phis score to the message.

Has anyone done this? module even?

ciao

Re: Why emails relayedfrom trusted/internal networks trigger rules?

[Matus UHLAR - fantomas]

On 26.04.18 10:04, Palvelin Postmaster wrote:

I relay mail from another server to my main mail server. I have set its IP
52.28.104.67 in my spamassassin conf in the internal_networks and
trusted_networks.  I assumed that would prevent spamassassin from scanning
the messages but no.  Why does this happen?


because you feed the messages to spamassassin. SpamAssassin has no option
for ignoring messages, if you really want to avoid spamassassin, then avoid
spamassassin and don't feed messages into it.

SA options trusted_networks and internal_networks are used for better spam
detection - there is still possibility of spam soming from trusted server,
SA only believes that the trusted server does not fake real sender (in the
Received: header).

see https://wiki.apache.org/spamassassin/TrustedRelays


X-Spam-Status: ⁨Yes, score=6.1 required=5.0 tests=AWL,DKIM_ADSP_NXDOMAIN, 
HELO_DYNAMIC_IPADDR,NO_DNS_FOR_FROM,RDNS_DYNAMIC,T_RP_MATCHES_RCVD 
autolearn=disabled version=3.4.1⁩
Received: ⁨by palvelin.fi (CommuniGate Pro PIPE 6.2.3)
Received: ⁨from [52.28.104.67] (HELO 
ip-172-31-20-213.eu-central-1.compute.internal) by palvelin.fi (CommuniGate Pro 
SMTP 6.2.3) with ESMTPS id 10108357 for i...@.com; Mon, 23 Apr 2018 
06:35:44 +0300⁩
Received: ⁨from ip-172-31-26-125.eu-central-1.compute.internal 
(ip-172-31-26-125.eu-central-1.compute.internal [172.31.26.125]) by 
ip-172-31-20-213.eu-central-1.compute.internal (Postfix) with ESMTP id ECF2CC0C32 for 
; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩
Received: ⁨by ip-172-31-26-125.eu-central-1.compute.internal (Postfix) id 
DCA21C000C; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩
Received: ⁨by ip-172-31-26-125.eu-central-1.compute.internal (Postfix, from 
userid 0) id D6BF2C010F; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩


--
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.
10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!

Why emails relayedfrom trusted/internal networks trigger rules?

[Palvelin Postmaster]

Hi,

I relay mail from another server to my main mail server. I have set its IP 
52.28.104.67 in my spamassassin conf in the internal_networks and 
trusted_networks. I assumed that would prevent spamassassin from scanning the 
messages but no. Why does this happen?

X-Spam-Status: ⁨Yes, score=6.1 required=5.0 tests=AWL,DKIM_ADSP_NXDOMAIN, 
HELO_DYNAMIC_IPADDR,NO_DNS_FOR_FROM,RDNS_DYNAMIC,T_RP_MATCHES_RCVD 
autolearn=disabled version=3.4.1⁩
Received: ⁨by palvelin.fi (CommuniGate Pro PIPE 6.2.3)
Received: ⁨from [52.28.104.67] (HELO 
ip-172-31-20-213.eu-central-1.compute.internal) by palvelin.fi (CommuniGate Pro 
SMTP 6.2.3) with ESMTPS id 10108357 for i...@.com; Mon, 23 Apr 2018 
06:35:44 +0300⁩
Received: ⁨from ip-172-31-26-125.eu-central-1.compute.internal 
(ip-172-31-26-125.eu-central-1.compute.internal [172.31.26.125]) by 
ip-172-31-20-213.eu-central-1.compute.internal (Postfix) with ESMTP id 
ECF2CC0C32 for ; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩
Received: ⁨by ip-172-31-26-125.eu-central-1.compute.internal (Postfix) id 
DCA21C000C; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩
Received: ⁨by ip-172-31-26-125.eu-central-1.compute.internal (Postfix, from 
userid 0) id D6BF2C010F; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩


--
Palvelin.fi Hostmaster
postmas...@palvelin.fi