On Thu, 22 Feb 2018, David Jones wrote:

On 02/22/2018 04:40 PM, John Hardin wrote:
On Thu, 22 Feb 2018, David Jones wrote:

On 02/22/2018 03:49 PM, John Hardin wrote:
On Thu, 22 Feb 2018, David Jones wrote:

My SA filters just received 45 unsolicited junk emails from Office 365 that hit ENCRYPTED_MESSAGE which subtracted a point.  Looking at 72_active.cf, the description for this rule is:

"Message is encrypted, not likely to be spam"

The body of the email was a MIME attachment of application/pkcs7-mime so SA didn't have access to it for body content rules.

I am seriously thinking about changing the score on this rule locally to 1.0 or 2.0 to add points if SA can't do any body checks.

I'd recommend against that. It would be better to do offsetting scores in a meta rule...

Good idea.

 Outlook and Outlook Web was able to display the email automatically. This may be a new feature that we are about to see more often to hide spam from SA.

It also hit BAYES_00 (not much can be done to change that), DCC_CHECK, PYZOR_CHECK, and FSL_BULK_SIG to score 2.88.

...e.g. ENCRYPTED_MESSAGE && (DCC_CHECK || PYZOR_CHECK || FSL_BULK_SIG) as bulk encrypted mail seems unlikely


This is not hitting FREEMAIL* rules but I have started treating anything coming from Google and Office 365 with local meta rules like this:

header __RCVD_GOOGLE    Received =~ /\.google\.com \[/

Is that accurately freemail? Wouldn't that also hit Google corporate emails?

header __RCVD_OFFICE365 Received =~ /\.outbound\.protection\.outlook\.com \[/

You might want to drop that in your sandbox so that it gets published...




That above would end up being a net score of +2.0 for freemail sources of email.

That sounds a lot safer. The rule *was* added with a negative score for a specific reason, after all...

Sure. The description doesn't sound like a very solid reason to assume that most encrypted email is ham when we can't do any body checks. :)

I that description was primarily from an assumption that spammers wouldn't be encrypting email as that would probably *reduce* the likelihood it would get viewed. But that may be changing.

It's also there to somewhat offset FPs due to unexpected matches in the encrypted gibberish.

Sometimes the passing of time with new spam techniques from software changes (i.e. Office 365 now auto handling of encrypted email) can allow this to be abused and need changing.


I'd be open to adding !__RCVD_OFFICE365 to ENCRYPTED_MESSAGE if they are making it *that* easy to abuse.

I am just trying to bring this up in case others may be seeing the same thing in their logs and not noticed it yet.

I will put it in my sandbox and see how it goes.  Thanks

I was just referring to the OFFICE365 subrule, as there isn't one like that yet - hotmail, sure, outlook, sure, but not office365. We should have added that back when O365 started up.

 John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
 jhar...@impsec.org    FALaholic #11174     pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
  ...have you noticed how the people sniveling over Trump are
  the same people slobbering over Fidel? They accuse Trump of wanting
  to put gays and minorities in camps, then post paeans
  to a guy who did just that.                     -- Toastrider @ TSM
 Today: George Washington's 286th Birthday

Reply via email to