Forward all email from a linux host to an SMTP server.
vi /etc/postfix/transport
* smtp:mail.mydomain.com
vi /etc/postfix/main.cf
transport_maps = hash:/etc/postfix/transport
postmap hash:/etc/postfix/transport
postfix reload
Hits: 0
Tag: email
Kulish.com Email Services Termination
Email services at kulish.com have been terminated.
Please use your ISP’s provided email or another provider such as gmail or yahoo.
Hits: 0
Email Cleanup
Our email server directories will be cleaned out February 28th.
What this means…
All ham and spam folders will be completely wiped cleaned.
If you have email in either folder on your account, move it to your inbox or create a new folder to store it.
Thanks.
The Administration
Hits: 0
Email Greylisting
First, for the un-initiated, click here to learn about email greylisting.
When email admins talk about greylisting, one of the benefits they normally point to is load on the actual email server but fail to mention supporting systems. I did notice a decrease in mail processing load there as well as my database server.
Keep in mind this is NOT a busy email server. It’s only hosting a couple TLDs.
I noticed an immediate improvement after restarting mail services (I did not reboot the server).
Email processing by amavisd was greatly reduced since the SMTP server rejected all new connections initially.
The “orange” is spam detected by amavis:
Below is the MariaDB database server.
Notice the drop in “pink” (ignore the spikes, those are backups) since the email server is rejecting before it has to query the database:
All things considered, SPAM and processing load has been greatly reduced.
Hits: 1
Block Incoming IP Using dd-wrt (iptables)
While reviewing logs on the email server I noticed 112.121.136.26 trying to authenticate via SASL.
This is not a normal IP that would be relaying email through the server, so I decided to block it at the firewall.
Undoubtedly, someone was trying to relay spam, whether they were aware or not.
First, I logged into my firewall via ssh to get a rule in place immediately:
iptables -I CHAIN -s 112.121.136.26 -j DROP
Listing the rules:
iptables -L --line-number
1 DROP 0 — ppp-112.121.136.26.revip.proen.co.th anywhere
Shows the new rule at the top of the chain. Exactly where I need it.
Now I have to make sure this rule survives rebooting the firewall.
To do this, I used the web interface and added a command to Administration >> Commands.
iptables -I CHAIN -s 112.121.136.26 -j DROP
Clicked the “Save Firewall” button.
I went ahead and rebooted to confirm the new rule was loaded at startup.
No more auth attempts from that IP.
NOTE 1: This method will drop ALL TRAFFIC from the listed IP. Play for keeps.
NOTE 2: If this is your IP, you need to check yo’ self before you wreck yo’ self…
Ongoing Additions:
High Frequency POP3 attempts (multiple a second):
iptables -I CHAIN -s 67.136.48.186 -j DROP
67.136.48.186
Hits: 1