Differences

This shows you the differences between two versions of the page.

--- email:email_firewall [2017/03/31 15:38] – created peter
+++ email:email_firewall [2019/11/27 21:51] (current) – removed peter
@@ Line 1: / Line 1: @@
-====== Email - Email firewall ======
-Use fake MX records to combat spam.
-Set a bogus server as the lowest and highest MX records with the working server's MX record in the middle.
-For example:
-<code>
-fake.example.com    1
-realmx.example.com  2
-fake2.example.com   3
-</code>
-The theory is, since majority of the spam will query for the the highest MX record to spam since usually they're backup servers that don't filter spam.  The lowest fake MX-record is for the rest of the spammers.. and generally spammers don't retry after failures.
-Risks:
-  * **High retry times** - Most servers will retry the next MX after the first one timeouts, others will try in the next few minutes, but some servers will only retry after one hour or one day.  They are very rare and are often misconfigured.
-  * **Delays in delivering emails** - All emails will have a delay - but this should not be much.  Almost all real mailservers will retry to the next MX after the the first timeout, so we are talking about 30s delay.  They usually try at least 3 MX before queuing the message for a longer delay.
-  * **Broken sites** - Some webservers send emails for passwords, notifications, etc. and instead of delivering for a internal real mail server, they try to be a "fake" mail server and delivery directly.  As its a webserver, they will never retry and the email is lost.  Again its a bad configuration from the webmaster/web developers, as only real email servers should send email.
-  * **No logs** - As the fake MX is unconnected to a proper IP, there will be no logs of what tried to be delivered.  You only know that something went wrong when someone complains.  You can always claim that you have no attempts to deliver any email, so it's a remote problem.  The other side must check their logs and solve the problem.   You can prove there is no connection at all to the real server, moving the pressure to resolve the problem to the other side.  If the other side is unable to fix the problem it looked as untrusted, unreliable.
-  * **No whitelist** - This applies to all servers via DNS, so you can not whitelist one server... actually is just half-true, but is harder. the whitelist solution is that the lowest MX points to a IP where a SMTP is running, but filtered by firewall for everyone.  The servers you want to whilelist needed to be permitted in the firewall.  This way all servers will be rejected by the firewall and the whitelisted will be able to deliver to the mail server.  It works, but only for IPs whitelist, not for email whitelist.