Howto block email from Mailchimp 1

[bluegroper]

Hi forum
We like and have been using Postfix in our small business for many years.
We have a small~ish list of sender domains that we reject using the usual details in /etc/postfix/sender_access and the following line in /etc/postfix/main.cf
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access
This works suitably for many senders that we'd rather not communicate with.

BUT we also receive too much junk email marketing from the Mailchimp.
Mailchimp's emails use a "forged" From header, such as sender@some-domain.com.
These emails actually come from numerous servers such as mail168.atl21.rsgsv.net
In this case it seems our sender_access file cannot reject emails from some-domain.com

Is there a better way to get this working so we can be rid of Mailchimp's spam ?
TIA's

 

[ChrisHirst]

Is there a better way to get this working so we can be rid of Mailchimp's spam ?

Not using the smtp_sender_restriction methods, (not as far as I have found at least), we use that with SpamAssassin integrated into the Postfix master.cf

https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix

Then write some SpamAssassin rules to score the mail headers.

https://wiki.apache.org/spamassassin/WritingRules

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[bluegroper]

[SOLVED]
Looks like my PBKAC
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access
I had incorrectly included the above instruction within section smptd_sender_restrictions =
Now moved to section smptd_recipient_restrictions = and appears working as intended.
This distinction between sender and recipient restrictions remains mildly confusing.
I post this here, in case it helps somebuddy else.
Meanwhile, it seems we can now happily reject some regular dross from MailChimp, using error code 554, ie permanent faliure.

 

[ChrisHirst]

This distinction between sender and recipient restrictions remains mildly confusing.

It's easy when you know how/why.

The category/section naming is relative to the local MTA, so 'sender' is for outgoing messages by local domains to an external MTA, whereas 'recipient' is relative to messages coming from external sources TO local domains.



Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[bluegroper]

Chris
Thanks for the great explanation. I couldn't find that anywhere else. I give you a star.
I agree its easy, almost obvious, when you know how/why.

I'm not a complete idiot. There's still a few pieces missing.

 

[ChrisHirst]

Thanks and I know the feeling, it took me a while to figure it out as well.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[bluegroper]

Chris
I've blown a few years of dust off some good old texts.
Postfix (2001) by Richard Blum ; and
The Book of Postfix (2005) by Ralf Hildenbrandt and Patrick Koetter
Yes, I have some dead-tree versions in my library.
Also

https://wiki.centos.org/HowTos/postfix_restrictions#head-2a3f36bf29e76f3a6f7a23708868ab9d9604197f

and

http://www.postfix.org/ADDRESS_VERIFICATION_README.html

After reading relevant parts of all these, I'm inclined to suggest a slight improvement to your explanation above.
I'm thinking :
- smptd_sender_restrictions -> refers to messages that postfix might send
- smptd_recipient_restrictions -> refers to messages that postfix might receive
Since postfix is an MTA, both restriction types ignore any distinction/s regarding the source (ie localhost, or remote host) of message/s.
Sender restrictions being important to avoid malformed messages.
Recipient restrictions apply to messages from localhost as well as incoming messages from the interwebs.
I include this suggestion just in case it helps somebody else, and for personal posterity.

 

[bluegroper]

Sadly, it seems the smptd_recipient_restrictions are not sufficient to block selected junk spewing out from Mailchimp's servers.
I'm not surprised, since Mailchimp has significant resources to ensure their messages are not easily blocked.
From the mail logs, it looks like Mailchimp is forging the FROM headers, which make it difficult to target for blocking.

Mailchimp appears to use the mcsv.net and rsgsv.net domains for sending. Perhaps others too.
It should be possible to block this domain using usual restrictions, BUT we receive some "good" emails from Mailchimp, as well as plenty of spam.
So we'll need to explore suitable techniques for blocking/rejecting only the unwanted crap, further downstream in the postfix process, or even use procmail.

The Mailchimp is such a PITA. :-(

Edit. See more detail at

https://www.facebook.com/prageru/po...ient-emails-correctly-they-/1930682406974606/

 

[ChrisHirst]

Technically they don't 'forge' their headers in the spam sense of 'forging' but they do 'forge' them in the 'manufactured from raw materials' usage of 'forge'.

Like so many bulk mailers the from headers identify the Mail Chimp user account along with other data they (Mail Chimp) can use to automatically 'clean' user mailing lists of failed mail addresses in the case of a 'bounce'. This is where employing the regular expression pattern match filtering used by Spam Assassin is advisable as well as the 'brute force' address blacking.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[bluegroper]

Chris, thanks for your reply.
Perhaps "obfiscated" is a better description for Mailchimp's smptd FROM headers.

Meanwhile, I'm redefining our problem, and hoping to stay within the postfix framework to achieve a satisfactory rejection outcome.
We have a manageable number of senders who (despite requests to "unsubscribe") persist in sending us their spam.
Most (but not all) of those use the Mailchimp service.

Clearly, attempted blocking using smptd restrictions will not achieve desired outcomes.
So the message/s must be received, and then submitted for processing further down the postfix stack.

We're going to try using header_checks. Initial testing is positive.
header_checks = pcre:/etc/postfix/header_checks.pcre

And header_checks.pcre contains many lines similar to following :
/^From:.*\@unwanted_domain\.com\/i REJECT Your SPAM from Mailchimp is rejected. Your domain is reported as blacklisted.

Suggesting that a domain has been blacklisted is deliberately intended to attract attention.
Further testing needed.
Any comments, tips or clues will be gratefully received.

 

[ChrisHirst]

I have several of our clients who "drag and drop" junk messages (over IMAP) to a report mailbox, plus a bunch of deliberately compromised email addresses and a few 'catchall' addresses on our servers that I grab messages from, then have scripts and filters that create the block lists for our postfix and exim servers, uploads them using SCP, the SA rulesets are uploaded with rsync then a server script creates the hash map for Postfix then restarts the MTAs and spamassassin

Public email providers such as aol, hotmail, live, gmail, yandex etc. are blocked as a single address while "crash and burn" domains are wildcard blocked.

In an occasional case where genuine (real life) senders who get accidentally reported by one of the clients, the script includes a gmail address that I monitor so they can ask for removal. The spammers never see or read NDRs so they never ask

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[bluegroper]

Yes, I've been contemplating something similar.
Create an email folder/file called "Blocked".
Move emails to the Blocked folder/file as desired.
Nightly script to parse the users' Blocked emails and update the postfix header_checks file as needed to include REJECT.
Since we only use webmail, and all emails are kept server-side, there's no SCP or SA needed.
Postfix header_checks seems to be a perfectly suitable solution for our needs.
After using a file of header_checks for a few days, we're very happy with results.

 

[ChrisHirst]

Spam Assassin also runs on the server and unlike Postfix which can only block on addresses, SA can score and filter on sender names, subject line or any message header you care to read.
If all your users are on one server, then all the analysis can be done on the server, I look after four servers, (one Exim, three Postfix) with multiple clients on many domains, so do the scripting on my desktop (Linux) and upload the files to all the servers three or four times a day.


Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.

 

[bluegroper]

For the moment we're staying within postfix, since I have little experience with SA.
Also, I like giving the unwanted sender/s a specially crafted REJECT message which is intended to cause them confusion. It appears to work.
There's some good and relevant info at the bottom of this page.

https://doxfer.webmin.com/Webmin/Postfix_Mail_Server

(I link it here so that I can discover it again later.)

 

[bluegroper]

Well, after using a nice file of header_checks for a coupla weeks, We're getting this job done.
Many lines in header_checks.pcre like this one :

/^From:.*@linkedin\.com/i REJECT SPAM is rejected. Sender address is blacklisted.

For the most persistent spammers, our perimeter firewall now includes a few drop rules, so there's no load on postfix, SA, or anything else downstream.

/sbin/iptables -A INPUT -s 205.147.102.166 -j DROP

Brutal, but effective. Of course these few rules will need to be maintained, or not.

Happy days.

 

[bluegroper]

Now that the MailChimp problem has been solved, we're moved on.

Since we don't want to receive any emails from correspondents in Russia or Ukraine,
the following lines in header_checks.pcre are stopping a quantity of spam being processed by our email server.

/^From:.*\.ru>?$/i REJECT
/^From:.*\.ua>?$/i REJECT

More goodness being done by postfix.