Re: regexp dealing with display name don't work

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: To answer John Harding, here are some display names that I want to block : "@ADMIN" "@WEB-SUPPORT" "@SUPPORT ADMIN" "@webmaster" Is the @ at the beginning of the name part in all cases? Try this: header FROM_NAME_PREFIX_ATSIGN From:name =~

Re: regexp dealing with display name don't work

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: Hi David, Thank you for your answer. I don't think I have to escape the @ character. You do. It is recognized without being escaped since when my rule is : From:name =~ /@.b/i The period is changing the interpretation of the @ sign. -- John

Re: regexp dealing with display name don't work

On 27 Apr 2018, at 16:27, Joëlle Pfeffer wrote: Hi David, Thank you for your answer. I don't think I have to escape the @ character. Yes, you do, if you want to match a character following it that could be the first character in an unreserved variable name (letter or underscore) or is an

Re: Dropping mail

On Fri, 27 Apr 2018 15:18:28 -0500 (CDT) David B Funk wrote: > If you have that many different classes of recipients, just set the > number of allowed recipients/transaction to one and be done with it. That will cause mail failures. It's not *supposed* to, but I

regexp dealing with display name don't work

To answer John Harding, here are some display names that I want to block : "@ADMIN" "@WEB-SUPPORT" "@SUPPORT ADMIN" "@webmaster" I think I already tried to escape the @ character but it didn't work better. I will try again. Cordialement, Joëlle Pfeffer, Cheffe de projet

Re: regexp dealing with display name don't work

Hi David, Thank you for your answer. I don't think I have to escape the @ character. It is recognized without being escaped since when my rule is : From:name =~ /@.b/i the display names consisting of @Ab or @Abc hit. It seems as if the character following the @ is not recognized except if

Re: Dropping mail

On Fri, 27 Apr 2018, Dianne Skoll wrote: On Fri, 27 Apr 2018 14:39:43 -0500 (CDT) David B Funk wrote: [snip] Define two classes of recipients: class A == all users who want everything class B == all users who want "standard" filtering This works if you

Re: regexp dealing with display name don't work

On Fri, 27 Apr 2018, David B Funk wrote: (note the trailing 'i' makes the regex be case-insenstive so /\@A/i doesn't make sense). ...it makes precisely as much sense as /\@a/i does... :) -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org

Re: regexp dealing with display name don't work

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: I have progressed. If my rule is header REGLE_HF002 From:name =~ /@A/i e-mails containing From: @A or From: "@AB" or From: "@Ab" are not blocked but if my rule is header REGLE_HF002

Re: regexp dealing with display name don't work

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: I have progressed. If my rule is header REGLE_HF002 From:name =~ /@A/i e-mails containing From: @A < jopfef...@free.fr > or From: "@AB" < jopfef...@free.fr > or From: "@Ab" < jopfef...@free.fr > are not blocked but if my rule is header REGLE_HF002

Re: regexp dealing with display name don't work

On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: I have progressed. If my rule is header REGLE_HF002 From:name =~ /@A/i e-mails containing From: @A < jopfef...@free.fr > or From: "@AB" < jopfef...@free.fr > or From: "@Ab" < jopfef...@free.fr > are not blocked but if my rule is header REGLE_HF002

Re: Dropping mail

On Fri, 27 Apr 2018 14:39:43 -0500 (CDT) David B Funk wrote: [snip] > Define two classes of recipients: >class A == all users who want everything >class B == all users who want "standard" filtering This works if you have a limited number of classes, but in

Re: Dropping mail

On Fri, 27 Apr 2018, Dianne Skoll wrote: Hi, I have reluctantly come to the conclusion that in some cases, it is necessary to silently drop spam rather than reject it. This is the situation: An email comes in for two recipients in one SMTP trasaction (ie, a MAIL, two RCPTs and then DATA).

regexp dealing with display name don't work

I have progressed. If my rule is header REGLE_HF002 From:name =~ /@A/i e-mails containing From: @A < jopfef...@free.fr > or From: "@AB" < jopfef...@free.fr > or From: "@Ab" < jopfef...@free.fr > are not blocked but if my rule is header REGLE_HF002 From:name =~ /@.b/i e-mails

Dropping mail

Hi, I have reluctantly come to the conclusion that in some cases, it is necessary to silently drop spam rather than reject it. This is the situation: An email comes in for two recipients in one SMTP trasaction (ie, a MAIL, two RCPTs and then DATA). One recipient's rules say to accept. The

Re: dropping other's email(s) as a "best practice" for hosted email?

On Fri, 27 Apr 2018, L A Walsh wrote: Alan Hodgson wrote: Rejecting the message during receipt causes the sending server to generate a bounce. If it's at all functional. That used to happen on poorly implemented mailing lists -- a delivery error would be bounced back to the email list as a

Re: dropping other's email(s) as a "best practice" for hosted email?

Alan Hodgson wrote: Rejecting the message during receipt causes the sending server to generate a bounce. If it's at all functional. On 27.04.18 09:32, L A Walsh wrote: If a given user wants emails to be dropped at the border -- that would be fine. *I* would not mind configuring a

Re: dropping other's email(s) as a "best practice" for hosted email?

Alan Hodgson wrote: Rejecting the message during receipt causes the sending server to generate a bounce. If it's at all functional. That used to happen on poorly implemented mailing lists -- a delivery error would be bounced back to the email list as a reply that would get

configuring spamassassin

sorry if this question is a bit vague but i am currently unable to ssh into my server to get more info. i am using centos 7 and i have set up spamassassin training by scanning messages which are moved into or out of the junk folder. it seems to work ok because database entries are being

Re: FP with URI_TRY_3LD on get.adobe.com

On Fri, 27 Apr 2018, Sebastian Arcus wrote: On 27/04/18 10:49, Sebastian Arcus wrote: I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in the body of emails: Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> got hit: "http://get.adobe.com;

Re: FP with URI_TRY_3LD on get.adobe.com

If this is causing the entire mail to be flagged as SPAM, we need to see the entire FP not just a hit on one rule. That rule has a max 0.8 score. Though it does appear to be hitting on more than intended though. Anyone know what it is supposed to hit because I think it might be hitting on a

Re: FP with URI_TRY_3LD on get.adobe.com

On Fri, 27 Apr 2018, Sebastian Arcus wrote: I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in the body of emails: Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> got hit: "http://get.adobe.com; Would it be possible to add some exception to

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

On Fri, 27 Apr 2018, Matus UHLAR - fantomas wrote: On 26.04.18 13:41, 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

Re: Anti Phish Rules

On 27/04/2018 17:53, Matus UHLAR - fantomas wrote: > On 27.04.18 06:51, Noel Butler wrote: > >> 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,

Re: Anti Phish Rules

On 27/04/2018 07:27, David Jones wrote: > 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

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

On Thu, 26 Apr 2018 13:41:05 -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

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

On 2018-04-26 (14:41 MDT), 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

Re: FP with URI_TRY_3LD on get.adobe.com

On 27/04/18 10:49, Sebastian Arcus wrote: I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in the body of emails: Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> got hit: "http://get.adobe.com; Would it be possible to add some exception to this

FP with URI_TRY_3LD on get.adobe.com

I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in the body of emails: Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> got hit: "http://get.adobe.com; Would it be possible to add some exception to this rule - as many legitimate emails

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

On 26.04.18 13:41, 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

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