diff --git a/content/u/blog/nftables-block-dhcp-and-router-advertisements/contents.lr b/content/u/blog/nftables-block-dhcp-and-router-advertisements/contents.lr
new file mode 100644
index 0000000..5b134fc
--- /dev/null
+++ b/content/u/blog/nftables-block-dhcp-and-router-advertisements/contents.lr
@@ -0,0 +1,108 @@
+title: Blocking DHCP servers and router advertisements with nftables
+---
+pub_date: 2020-08-27
+---
+author: ungleich
+---
+twitter_handle: ungleich
+---
+_hidden: no
+---
+_discoverable: yes
+---
+abstract:
+Blocking typical data center workloads with nftables
+---
+body:
+
+## Motivation
+
+Here at [ungleich](https://ungleich.ch) we are providing a variety of
+hosting services in the [Data Center
+Light](https://datacenterlight.ch). One of the workloads we offer is
+VM hosting and we need to take some security measures to prevent one
+customer abusing another customer.
+
+## The problem
+
+The virtual machines in our next generation uncloud hosting will be
+using standard DHCP and IPv6 address assignments. Currently
+we are still using the
+[OpenNebula](https://github.com/OpenNebula/addon-context-linux)
+contextualisation scripts that read the networking information from an
+attached ISO.
+
+While this makes it easier to create VM images and VMs behave even
+more like regular computers, this exposes the VMs to attacks where one
+customer runs a DHCP server or IPv6 router advertisement daemon and
+tricks the other VMs into sending traffic to it.
+
+## The architecture
+
+VMs are connected to a single shared network in which they get
+their IP addresses (in uncloud usually only IPv6) and then they can
+retrieve more information from a metadata server. So the main
+protection that is required is preventing to trick other customers
+into using a wrong IP address or route.
+
+Also, if the network is IPv6 only, another customer should not be able
+to trick someone else into using IPv4.
+
+## Fixing it
+
+So the easiest thing to do is to disallow IPv6 router advertisements
+and IPv4 DHCP server answers. However as all the interfaces are put
+into one bridge, we will need to filter on bridge and not ip level:
+
+```
+table bridge filter {
+    chain prerouting {
+        type filter hook prerouting priority 0;
+        policy accept;
+    }
+```
+
+Next we create a chain to drop the packets we dislike:
+
+```
+    chain drop_ra_dhcp {
+        # Blocks: router advertisements, dhcpv6, dhcpv4
+        icmpv6 type nd-router-advert drop
+        ip6 version 6 udp sport 547 drop
+        ip  version 4 udp sport 67 drop
+    }
+```
+
+Now the only thing left is to correctly classify the traffic. For this
+lets take some real world assumptions:
+
+* Let's assume the bridge is named **br100**
+* Let's assume the upstream interface that should allow RA/DHCP is
+  named **vxlan100**
+
+Then we can connect the chains together:
+
+```
+table bridge filter {
+    chain prerouting {
+        type filter hook prerouting priority 0;
+        policy accept;
+
+        iifname != vxlan100 meta ibrname br100 jump drop_ra_dhcp
+    }
+
+    chain drop_ra_dhcp {
+        # Blocks: router advertisements, dhcpv6, dhcpv4
+        icmpv6 type nd-router-advert drop
+        ip6 version 6 udp sport 547 drop
+        ip  version 4 udp sport 67 drop
+    }
+}
+```
+
+This way we have a very simple filter to prevent router advertisements
+or dhcp answers to come from customer VMs.
+
+We hope you enjoyed reading it, but if something does not make sense,
+you can ask on our [open chat](/u/projects/open-chat/) or
+[consult the nftables reference](https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes#Meta).
diff --git a/content/u/products/mail-hosting/contents.lr b/content/u/products/mail-hosting/contents.lr
index 45d7948..6780e7b 100644
--- a/content/u/products/mail-hosting/contents.lr
+++ b/content/u/products/mail-hosting/contents.lr
@@ -12,7 +12,7 @@ headline1: Mail Hosting:
 ---
 headline2: Your Mails in Switzerland
 ---
-header_background_color: #788BCE 
+header_background_color: #788BCE
 ---
 header_text_color: text-light
 ---
@@ -39,14 +39,26 @@ description2:
 
 This mailhosting is mainly targeted for low volume, single person or
 single system usage.
+If you need a mail gateway for sending system logs or if you just need
+an easy to use mail account, this is the right product.
+
+This product is feasible for normal use of email. Spamming is
+prohibited and will lead to suspension and/or terminaton of your
+account.
+
+If you are interested in a legit high volume mail traffic product,
+[contact us](/u/contact/) for an individual offer.
 
 ## What you get
 
 * A single mailbox account (yourname@ungleich.cloud)
 * Up to 100 mail aliases
-* Up to 100GB usage
+* Up to 100GB usage (additional storage: 100GB for 2 CHF/month)
+* Access via SMTP, IMAPS and Webmail
 
 ## Pricing
 
 The one time setup fee is 15 CHF, the monthly recurring fee is 7 CHF
 per month.
+
+You can order it by sending an email to **support at ungleich.ch**.