Many ISPs have limits on the amount of emails received in a period of time, not respecting this will reduce the reputation of the sender.

Mailman 2 doesn’t support throttling, though there’re some patches in the wild adding this feature. Exim supports rate limiting incoming emails, but not emails going out, though it may be possible to do this with some convoluted configuration.

The easy solution is to rate limit emails coming from Mailman to Exim, so Mailman will retry them later.

This is the Mailman configuration:

DELIVERY_RETRY_WAIT = minutes(15)

Here we tell Mailman to retry sending delayed emails every 15 minutes, this is the minimum possible time, because the retry process only runs every 15 minutes. The default value is 1 hour.

Here we’re telling Exim to accept no more than 75 emails every 15 minutes for any given domain. As seen above 15 minutes is the minimum possible for Mailman. The value 75 depends on how many emails you’re sending: look at the exim logs, pick up the domain you’re sending the most emails, and adjust this value accordingly.

Safari and Firefox on Mac will recognize -apple-system and use the Mac system font, just as system-ui, but not standard. Then comes the standard system-ui, but only available in Chrome 56. Older versions of Chrome, on Mac only, will interpret the same with BlinkMacSystemFont. Now comes Segoe UI, unlike the first three this is a real font name, the one used in Windows since Windows Vista. Now comes: Roboto for Android, Helvetica Neue for some versions of macOS, and Arial for old Windows.

Ah that looks better, just added Oxygen for KDE, Ubuntu for.. (I let you guess this one), Cantarell for Gnome, and Helvetica because… well I don’t know why.

If you want, you can still add Droid Sans for old Android, Fira Sans for Firefox OS, and maybe Lucida Grande for some old versions of macOS. Okey, the list is long but you only have to type it once. You can also define the list using @font-face

Make your own list, decide which platforms you don’t care about, and use it as default in your projects. But don’t be insensitive and include Cantarell in the list!

Of course, if your site tries to sell something or to send a message, and if you care enough, then consider choosing a nice font (adjust letter spacing bla bla). To make it short, maybe something like:

Just learned about HSTS and started using it. First let me explain HSTS with my own words.

Scenario without hsts:

The user types the domain name in the URL bar without the protocol, such as “example.com”, and the browser automatically adds the “http://” prefix. This first request is vulnerable to Man In The Middle (MITM) attacks.

The server replies with a redirection to the secure “https://example.com”. From the rest of the interaction communication is secure.

The next day the user types again “example.com” in the URL bar. The browser sends again an insecure HTTP request.

Scenario with hsts:

The user types the domain name in the URL bar without the protocol, such as “example.com”, and the browser automatically adds the “http://” prefix. This first request is vulnerable to Man In The Middle (MITM) attacks.

The server replies with a redirection to the secure “https://example.com”. From the rest of the interaction communication is secure. And, the server adds the response header:

Strict-Transport-Security: max-age=31536000

This response header instructs the browser to use HTTPS, and asks him to do so for the next 31.536.000 seconds (1 year).

The next day, the user types again “example.com” in the URL bar. But, the browser remembers, and it uses HTTPS instead of HTTP. And will do so even if the user includes explicitly the prefix “http://example.com”.

Closing

So with HSTS the user will only be vulnerable the first time, and not every time she starts a session.

After learning this I have added support for HSTS to my Ansible role for Django deployment. See commit, and I encourage you to start using HSTS too.