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

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

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,

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

Re: Anti Phish Rules

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

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

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

Re: Warning while running spam assasin on the message

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]

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

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

Re: Anti Phish Rules

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

Why emails relayedfrom trusted/internal networks trigger rules?

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

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

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

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

Anti Phish Rules

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

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

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

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

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

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

Re: regexp dealing with display name don't work

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

regexp dealing with display name don't work

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

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 meta     

Re: Anti Phish Rules

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

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

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

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

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