Differences

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

--- email:email_firewall [2017/03/31 15:44] – 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.
-Unlike **postgrey**, where the remote sender have a log of a "rejected" delivery (and so can point at us as the problem), the fake-MX will show that the webserver could not even connect and didn't retry, giving no excuse for the remote side about the problem.
-Recommendations:
-  * Do not use private IPs or IPs that you don't control for the fake MX (if you add ipv6 address, ALSO add a ipv4 one).  This avoid problems with broken DNS and mailservers and surprises of other getting your email (by installing a smtp server on the IP you don't control).  Also, CNAME are forbidden for MX, so don't use it also, just a plain A record.
-  * A tcp-reset should be sent for the fake MX, to improve performance (host or port unreachable) instead of a plain timeout (by dropping the packet), so it's recommended to add it to you firewall.