How To Reject Unknown Local Recipients And Stop Backscattering Using Postfix
Our eCommerce website was suddenly flooded by customer service requests, because a Korean blogger featured one of our products and recommended it to their audience. But there was a problem. The Korean fans werent receiving any account validation email(s) because, unknown to us, we were listed on a service called Backscatter.
The symptom of the problem was the fact that user validation emails from our Drupal website were not getting through. I found a clue as to the root cause of the problem by scanning /var/log/maillog, where I found messages like this:
Dec 10 08:44:06 vm postfix/smtp[8559]: A36BA1915E4: to=<someone@naver.com>, relay=mx3.naver.com[125.209.222.14]:25, delay=320375, delays=320375/0.04/0.5/0, dsn=4.3.2, status=deferred (host mx3.naver.com[125.209.222.14] refused to talk to me: 421 4.3.2 Your ip blocked from this server Lszkr3-+Su+X+YG-8za6uQ - nsmtp)
Dec 10 17:34:07 vm postfix/smtp[15483]: C74731915E5: host mx1.naver.com[125.209.238.100] refused to talk to me: 421 4.3.2 Your ip blocked from this server ty6AmtSvS3uZtg7Q+O5krA - nsmtp
Surprised by this information, I checked the IP address of the email server on a Real Time Blacklist (RBL) server called mxtoolbox.com.
Here's what I got back from them:
A bit surprised, I clicked on BACKSCATTERER and here's what I got:
Ultimately, the trail of clues led me to backscatterer.org.
Backscatterer has a really interesting business model, along with a chequered story and murky past. As a consequence, it has a lot of haters who claim that it is nothing better than a "ransomware" website that is abusing the (usually) free RBL mechanism for profit.
Here's what Backscatterer has to say for itself:
Anyways, if you are listed with Backscatterer, and you want "expedited removal service" to be removed from their list, you can pay a fee of 50 Swiss Francs (USD50.81), or you can wait a month, at which point removal is automatic and free.
Now, waiting a month can feel like forever when dozens of newly activated customers are calling you and demanding to know what's going on with their activation(s) so they can buy your stuff! Basically, these users want to be activated now, and so do you, so you can get their business!
Here's a typical listing in Backscatterer.org:
How To Test Your Server On backscatterer.org
To test your server on the Backscatterer website, just append the IP address of your machine to their URL, to see what they have to say about your machine:
http://www.backscatterer.org/?ip=w.x.y.z
Why I Resolved The Backscatterer Problem
As it turns out, our mail server wasn't listed anywere else, on any other Real Time Blacklist (RBL) server, which made Backscatterer.org really stand out.
But, considering the Korea situation and the fact that perhaps other websites may some day in the future start using the Backscatterer RBL, it seemed like a good idea to resolve the underlying reason why we were listed by Backscatter.org in the first place.
So I looked into it. Here's what I found out:
What Predicates A Backscatterer.org Listing?
The reasoning behind backscatterer.org is quite legitimate. It seems that spammers have figured out a way to cause "backscatter" by forging the headers of emails in such a way that they can be used as a means of launching a Denial Of Service (DOS) attack on a mail server by flooding it with bogus emails.
Preventing Backscatter
The best way to prevent backscatter is to configure your email server so it only accepts email for known recipients. This means that the identity listed in the To: field checks out against a local database of known local recipients that the email server can consult whenever a new email arrives. Any email that is addressed to someone not in the local database is called an unknown local recipient, and it can be dealt with in one of these ways:
- It can be rejected (this increases network traffic)
- It can be deleted (this reduces network traffic)
- The IP of the sending machine can be flagged as a spammer (what happened to us)
My initial feeling was that it was easiest to either reject or delete the offending mail.
People sometimes get email addresses wrong, and it's a bit heavy handed to block an entire mail server (which may be handling dozens of domains and hundreds of email accounts) because a single user somewhere might be sending out spam.
Configuring Postfix To Prevent Backscattering
Our email server is postfix, a pretty popular Mail Transfer Agent (MTA) that has been around for quite some time. A lot of very high quality documentation is available for postfix online, including www.postfix.org.
To configure a postfix email server so that it only accepts email for Known Local Recipients, a few settings need to be verified and the following steps accomplished:
A) Enable postfix To Only Accept Mail For Known Local Recipients
B) Enable postfix To Know Who Its Known Local Recipients Are
C) Enable postfix To Respond To Unknown Local Recipient Emails
D) Verify That Unknown Local Recipients Are Being Rejected by postfix
E) Clean Up Any postfix Related Loose Ends
A) Enable postfix To Only Accept Mail For Known Local Recipients
In CentOS 7, the main configuration file for postfix, is called main.cf, and it is located in the /etc/postfix directory. Processing email is a very complicated affair, so this file is simply loaded with configuration options, but we are just going to focus on those needed to turn on its Known Local Recipients capabilities.
Here's the relevant section of main.cf (around line 165)
# REJECTING MAIL FOR UNKNOWN LOCAL USERS
#
# The local_recipient_maps parameter specifies optional lookup tables
# with all names or addresses of users that are local with respect
# to $mydestination, $inet_interfaces or $proxy_interfaces.
#
# If this parameter is defined, then the SMTP server will reject
# mail for unknown local users. This parameter is defined by default.
#
# To turn off local recipient checking in the SMTP server, specify
# local_recipient_maps = (i.e. empty).
#
# The default setting assumes that you use the default Postfix local
# delivery agent for local delivery. You need to update the
# local_recipient_maps setting if:
#
# - You define $mydestination domain recipients in files other than
# /etc/passwd, /etc/aliases, or the $virtual_alias_maps files.
# For example, you define $mydestination domain recipients in
# the $virtual_mailbox_maps files.
#
# GL 2019-12-14 List all allowed email address in a file named
# virtual that lives in /etc/postfix
#
virtual_alias_maps = hash:/etc/postfix/virtual
If the virtual_alias_maps parameter is set, postfix automatically goes into Known Local Recipients mode. Its parameter, hash:/etc/postfix/virtual tells postfix use the file named virtual in the /etc/postfix directory to validate incoming email addresses.
B) Enabling postfix To Know Who Its Known Local Recipients Are
virtual_email_address other_email_address
In Known Local Recipient mode, postfix treats the virtual file as a lookup table, or hash, to see if there's a matching email address entry on the left margin. If there isn't one, postfix will reject the incoming email as an Uknown Local Recipient, which is what we want.
C) Setting Up postfix To Respond Properly To Unknown Local Recipient Emails
When postfix does encounter an Unknown Local Recipient (i.e. a bogus email), we need to tell the sending server that we are not interested in it. Luckily, there's a standard error message that we can use to tell the sending email server that we are not having any of it.
# The unknown_local_recipient_reject_code specifies the SMTP server
# response code when a recipient domain matches $mydestination or
# ${proxy,inet}_interfaces, while $local_recipient_maps is non-empty
# and the recipient address or address local-part is not found.
#
# The default setting is 550 (reject mail) but it is safer to start
# with 450 (try again later) until you are certain that your
# local_recipient_maps settings are OK.
#
#unknown_local_recipient_reject_code = 550
#
# GL 2019-12-15 REJECT Unknown Local Recipient emails
#
unknown_local_recipient_reject_code = 550
How To Restart Postfix
With all of the implicated postfix settings adjusted, I needed to tell it to re-read its configuration. This happens automatically when you restart it, so that's what I did:
# service postfix restart
Redirecting to /bin/systemctl restart postfix.service
Whenever postfix is restarted, it's always a good idea to double-check that it is running and happy:
# service postfix status
Redirecting to /bin/systemctl status postfix.service
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2019-12-15 10:35:19 HKT; 4s ago
Process: 11127 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
Process: 11146 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
Process: 11141 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
Process: 11138 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
Main PID: 11219 (master)
CGroup: /system.slice/postfix.service
├─11219 /usr/libexec/postfix/master -w
├─11220 pickup -l -t fifo -u
└─11221 qmgr -l -t fifo -u
Dec 15 10:35:18 vm.yougrow.net systemd[1]: Starting Postfix Mail Transport Agent...
Dec 15 10:35:19 vm.yougrow.net postfix/postfix-script[11217]: starting the Postfix mail system
Dec 15 10:35:19 vm.yougrow.net postfix/master[11219]: daemon started -- version 2.10.1, configuration /etc/postfix
Dec 15 10:35:19 vm.yougrow.net systemd[1]: Started Postfix Mail Transport Agent.
D) Verify That Unknown Local Recipients Are Being Rejected by postfix
Looking around, I found a nifty service out of Germany that provides a web-based backscatter test interface. Its service is located at http://its-netzwerk.com/bscatter and it is simple to use. Enter:
- The IP address of your mail server
- The domain of the mail server (optional)
- The CAPTCHA
Then wait for the results. Here's what I got:
E) Clean Up Any postfix Related Loose Ends
The last thing to do is to clear away any lingering messages that may have been injected into the system while it was backscattering, that may have not yet been delivered yet because of resolution, availability, addressing or other mail transport-related problems.
These messages need to be deleted because postfix will attempt to deliver them for as long as they linger in the system - so they really should be expunged at this point. To see how many of these message are still lingering on your system, use the mailq command.
Here's what I got when I used the mailq command in this way:
# mailq | grep "("
(connect to mail.cnt-grms.com.ec[200.107.61.69]:25: Connection timed out)
(connect to mail.mysipl.com[120.138.98.21]:25: Connection timed out)
(connect to timelessbeautyspa.com[23.20.239.12]:25: Connection timed out)
(connect to wfaseuna.computerstlouis.com[38.131.222.30]:25: Connection refused)
(connect to icasualties.org[66.206.4.66]:25: Connection timed out)
(connect to comcastbusiness.net[165.160.15.20]:25: Connection timed out)
(connect to mx.ns.od.ua[92.60.176.21]:25: Connection timed out)
(connect to omni.lt[194.176.33.17]:25: Connection timed out)
(connect to mail.neanet.pl[31.132.64.252]:25: Connection timed out)
(connect to tienaakotona.com[198.54.117.200]:25: Connection timed out)
(connect to site.com[204.74.99.100]:25: Connection timed out)
(connect to mx.ns.od.ua[92.60.176.21]:25: Connection timed out)
(connect to site.com[204.74.99.100]:25: Connection timed out)
(connect to site.com[204.74.99.100]:25: Connection timed out)
(connect to pelikan.net.br[160.238.160.14]:25: Connection refused)
(connect to mx.idsbangladesh.net.bd[117.103.80.101]:25: No route to host)
(connect to gvt.net.br[200.139.127.26]:25: Connection timed out)
(connect to security.tdatabrasil.net.br[200.153.1.180]:25: Connection timed out)
(connect to mail.cnt-grms.com.ec[200.107.61.69]:25: Connection timed out)
(connect to mail.usieng.com[71.12.99.171]:25: Connection timed out)
None of these domains looked legit to me, so I deleted them using the postsuper command:
# postsuper -d ALL deferred
postsuper: Deleted: 22 messages
Then I re-ran the above mailq command to make sure that I had gotten rid of them:
# mailq | grep "("
#
Conclusion
Maybe being listed on the Backscatterer.org RBL was ultimately a good thing for us.
In the end, we were made aware of an ongoing problem that we didn't know about. Our postfix configuration (and related configuration documentation) is much better as a consequence of resolving the problem. Finally, we were able to produce an article about what we did to resolve the backscatter problem that we were a part of, in the hope that the article would be able to help others in the same circumstances get out of trouble quickly.
Great Success!
REFERENCES:
https://sharadchhetri.com/2014/02/06/how-to-delete-mail-queue-in-postfix/
https://serverfault.com/questions/251850/how-do-i-change-postfix-configuration-after-installing-it
https://help.returnpath.com/hc/en-us/articles/220568667-What-is-backscatter-
https://serverfault.com/questions/251850/how-do-i-change-postfix-configuration-after-installing-it
http://its-netzwerk.com/bscatter/
http://www.postfix.org/
No comments:
Post a Comment