[SOLVED] Block emails that pass through a specific upstream server

[troycarpenter]

I have been searching and trying different solutions, but I can't seem to find the magic incantation that makes this work.

I have a user getting blasted with various loosely related emails all from various email addresses and domains. However, they all are being used by the same email relay service. For example:

Received: from smtp.sandia.mailrealy.com (smtp.sandia.mailrelay.com [254.223.231.24])
    (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    by pmg.mydomain.com (Proxmox) with ESMTPS
    for <user@mydomain.com>; Wed, 28 Sep 2022 14:10:40 -0500 (CDT)

ALL unwated emails are being relayed through servers with names like "smtp.xxxx.mailrealy.com" where xxxx is a different server name almost every time. I have checked and none of my other users are receiving valid emails from that email relay service.

How do I block those? I have tried using mail filter rules with a What Object of "Match Field" of "Recieved=^.*\.mailrelay.com.*$" When using one of the Received headers from an email in the test string box, it says "OK". Then I used that object in the mail filter rule to quarantine the message, but it doesn't do it.

I've also tried using /etc/postfix/senderaccess, but I've been editing that by hand and sometime overnight any edits I make go away.

The user is not happy that I've not been able to solve this problem. Any help would be appreciated.

 

[Stoiko Ivanov]

How do I block those? I have tried using mail filter rules with a What Object of "Match Field" of "Recieved=^.*\.mailrelay.com.*$"

This should work - however there was a small issue in pmg-api fixed recently (before that it only matched the first such header)

what's your pmgversion -v output?

 

[troycarpenter]

This should work - however there was a small issue in pmg-api fixed recently (before that it only matched the first such header)

what's your pmgversion -v output?

root@pmg:~# pmgversion -v
proxmox-mailgateway-container: 7.1-1 (API: 7.1-4/523ac520, running kernel: 5.13.19-6-pve)
pmg-api: 7.1-4
pmg-gui: 3.1-3
clamav-daemon: 0.103.6+dfsg-0+deb11u1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
libarchive-perl: 3.4.0-1
libjs-extjs: 7.0.0-1
libjs-framework7: 4.4.7-1
libproxmox-acme-perl: 1.4.2
libproxmox-acme-plugins: 1.4.2
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.2-2
libpve-http-server-perl: 4.1-3
libxdgmime-perl: 1.0-1
lvm2: not correctly installed
pmg-docs: 7.1-2
pmg-i18n: 2.7-2
pmg-log-tracker: 2.3.1-1
postgresql-13: 13.7-0+deb11u1
proxmox-mini-journalreader: 1.3-1
proxmox-spamassassin: 3.4.6-4
proxmox-widget-toolkit: 3.5.1
pve-xtermjs: 4.16.0-1

I went ahead and did an upgrade, and now this is the output:
root@pmg:~# pmgversion -v
proxmox-mailgateway-container: 7.1-2 (API: 7.1-7/4d02e400, running kernel: 5.13.19-6-pve)
pmg-api: 7.1-7
pmg-gui: 3.1-4
clamav-daemon: 0.103.7+dfsg-0+deb11u1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
libarchive-perl: 3.4.0-1
libjs-extjs: 7.0.0-1
libjs-framework7: 4.4.7-1
libproxmox-acme-perl: 1.4.2
libproxmox-acme-plugins: 1.4.2
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.2-3
libpve-http-server-perl: 4.1-3
libxdgmime-perl: 1.0-1
lvm2: not correctly installed
pmg-docs: 7.1-2
pmg-i18n: 2.7-2
pmg-log-tracker: 2.3.1-1
postgresql-13: 13.8-0+deb11u1
proxmox-mini-journalreader: 1.3-1
proxmox-spamassassin: 3.4.6-4
proxmox-widget-toolkit: 3.5.1
pve-xtermjs: 4.16.0-1

I see that it installed a newer version, so now I will wait and see if the rule now works.

 

[troycarpenter]

I just watched another email sail through the system and delivered to the end user even with the latest versions installed.

 

[troycarpenter]

Something you said earlier made me try a different header to inspect. Instead of using the "Received" header, which there are many in the message, I switched to "Received-SPF" (of which there is only one of those headers) and the rule triggered.

So even with the latest code, there still is something wrong with rules with multiple headers of the same name.

 

[Stoiko Ivanov]

So even with the latest code, there still is something wrong with rules with multiple headers of the same name.

could of course be - but I did test that one quite a bit...

would it be possible for you to share the email which did not trigger (as .eml) and the rule you created - then I could see if somethin/what goes wrong?

 

[troycarpenter]

could of course be - but I did test that one quite a bit...

would it be possible for you to share the email which did not trigger (as .eml) and the rule you created - then I could see if somethin/what goes wrong?

I have attached the .eml, with the end user's email address changed. All other info (relays, IP addresses, etc) are unaltered.

As far as the filter, Here's the What object:

Before, I was just using the Received header, but that didn't work. Only worked when I started using Received-SPF as above.

The rule is this:

 

[Stoiko Ivanov]

you need to remove the anchors (they are added implicitly for match-fields) '^', '$' - but it does work for Received headers as well (with '.*bluehornet.com.*' and the .eml)

I hope this helps!

 

[troycarpenter]

That worked. I made the change to the regex and switched the header back to Received. The first email to come across since then matched just fine.