Controlling MS Azure Cloud Spam

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Controlling MS Azure Cloud Spam

ludicree

Hi,

 

I am seeing a wave of MS Azure Cloud Spam these days.

 

Many of these mails come with a header:

 

  • Return-Path: <MAILER-DAEMON>
  • Empty From Field

 

They than pass the greylisting filter (and all others it seems) with „Bounce message. Skip.“

 

Is there a way to influence this behaviour?

 

Postfix on debian stretch / no Spamassassin.

 

Greets,

Ludi

 

 

 

 

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Controlling MS Azure Cloud Spam

Nick Tait

Hi Ludi.

One option might be to add OpenDMARC to your implementation? The reason for mentioning this is because in addition to checking DMARC policies, OpenDMARC also has an option to reject any message that doesn't have the mandatory headers according to RFC 5322:

RequiredHeaders (Boolean)

If set, the filter will ensure the header of the message conforms to the basic header field count restrictions laid out in RFC5322, Section 3.6. Messages failing this test are rejected without further processing. A From: field from which no domain name could be extracted will also be rejected.

If I understand the RFC correctly this includes the Date and From headers.

Nick.


On 26/12/20 6:58 am, [hidden email] wrote:

Hi,

 

I am seeing a wave of MS Azure Cloud Spam these days.

 

Many of these mails come with a header:

 

  • Return-Path: <MAILER-DAEMON>
  • Empty From Field

 

They than pass the greylisting filter (and all others it seems) with „Bounce message. Skip.“

 

Is there a way to influence this behaviour?

 

Postfix on debian stretch / no Spamassassin.

 

Greets,

Ludi

 

 

 

 

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Controlling MS Azure Cloud Spam

John Schmerold
On 12/27/2020 3:15 PM, Nick Tait wrote:

Hi Ludi.

One option might be to add OpenDMARC to your implementation? The reason for mentioning this is because in addition to checking DMARC policies, OpenDMARC also has an option to reject any message that doesn't have the mandatory headers according to RFC 5322:

RequiredHeaders (Boolean)

If set, the filter will ensure the header of the message conforms to the basic header field count restrictions laid out in RFC5322, Section 3.6. Messages failing this test are rejected without further processing. A From: field from which no domain name could be extracted will also be rejected.

If I understand the RFC correctly this includes the Date and From headers.

Nick.


On 26/12/20 6:58 am, [hidden email] wrote:

Hi,

 

I am seeing a wave of MS Azure Cloud Spam these days.

 

Many of these mails come with a header:

 

  • Return-Path: <MAILER-DAEMON>
  • Empty From Field

 

They than pass the greylisting filter (and all others it seems) with „Bounce message. Skip.“

 

Is there a way to influence this behaviour?

 

Postfix on debian stretch / no Spamassassin.

 

Greets,

Ludi

 

You don't say why no Spam-assassin, assuming you're not philosophically opposed to SA, I recommend you add it to the mix.

Proxmox Mail Gateway & MailScanner.info are good implementations


Reply | Threaded
Open this post in threaded view
|

AW: Controlling MS Azure Cloud Spam

ludicree

Hi,

 

thanks for your replies.

 

I took a second look at that spam wave and noticed that the scheme

 

  1. Return-Path: <MAILER-DAEMON>
  2. Empty From Field

 

might not actually be true. The From field often contains something, but no FQDN.

 

Postfix rejected the spam correctly when pointed at Azure account IDs in the Received line.

So header checks do apply before „Bounce message. Skip“.

 

@Nick

A check for a valid FQDN in From is in smtpd_sender_restrictions.

At the point where it got to bounce message, SPF was skipped. Would OpenDMARC then still work?

 

@John

It is a Plesk machine. Spamassassin has many implications there.

I might install it again, but will have to check that all the user mailboxes do not get altered.

Also I am trying to secure it via postfix only and reject what is unwanted and discard what should be unknown.

Works out pretty good so far. A permanent field of work, of course.

 

Greets,

Ludi

 

Von: [hidden email] <[hidden email]> Im Auftrag von John Schmerold
Gesendet: Montag, 28. Dezember 2020 03:29
An: Nick Tait <[hidden email]>; [hidden email]
Betreff: Re: Controlling MS Azure Cloud Spam

 

On 12/27/2020 3:15 PM, Nick Tait wrote:

Hi Ludi.

One option might be to add OpenDMARC to your implementation? The reason for mentioning this is because in addition to checking DMARC policies, OpenDMARC also has an option to reject any message that doesn't have the mandatory headers according to RFC 5322:

RequiredHeaders (Boolean)

If set, the filter will ensure the header of the message conforms to the basic header field count restrictions laid out in RFC5322, Section 3.6. Messages failing this test are rejected without further processing. A From: field from which no domain name could be extracted will also be rejected.

If I understand the RFC correctly this includes the Date and From headers.

Nick.

 

On 26/12/20 6:58 am, [hidden email] wrote:

Hi,

 

I am seeing a wave of MS Azure Cloud Spam these days.

 

Many of these mails come with a header:

 

  1. Return-Path: <MAILER-DAEMON>
  2. Empty From Field

 

They than pass the greylisting filter (and all others it seems) with „Bounce message. Skip.“

 

Is there a way to influence this behaviour?

 

Postfix on debian stretch / no Spamassassin.

 

Greets,

Ludi

 

You don't say why no Spam-assassin, assuming you're not philosophically opposed to SA, I recommend you add it to the mix.

Proxmox Mail Gateway & MailScanner.info are good implementations

 

Reply | Threaded
Open this post in threaded view
|

Re: AW: Controlling MS Azure Cloud Spam

Nick Tait
On 30/12/2020 2:38 am, [hidden email] wrote:
@Nick

A check for a valid FQDN in From is in smtpd_sender_restrictions.

At the point where it got to bounce message, SPF was skipped. Would OpenDMARC then still work?

The smtpd_sender_restrictions that you specify are applied to the envelope sender address (a.k.a. RFC5321.MailFrom). IIUC the mail you are talking about has the null sender address, <>, which is probably handled as a special case and not rejected by reject_non_fqdn_sender (and other smtpd_sender_restrictions)?

FYI I'd also suspect that SPF treats the null address as a special case too?

In order to accept or reject the mail based on the From header in the mail (a.k.a. RFC5322.From) you'd need to use some sort of content filter...

The simplest option is to use the Postfix built-in content inspection available with the header_checks option, to reject mail containing a From header matching a particular regular expression. Check out http://www.postfix.org/BUILTIN_FILTER_README.html for more information. However this won't work if the header is absent (i.e. no From header in the message).

Other options are a before-queue content filter (http://www.postfix.org/SMTPD_PROXY_README.html) or before-queue milter (http://www.postfix.org/MILTER_README.html). OpenDMARC is an example of the latter.

The one caveat with using OpenDMARC is that I'm pretty sure you'd need to use OpenDKIM and OpenDMARC together to implement DMARC policy checking and then you get that option I mentioned previously as bonus functionality. But if you had no desire to implement DMARC policy checking then this is a bit like using a sledgehammer to crack a nut.

Nick.