From 9f685d4b89b97e5fe987ac38e06756308a440f5c Mon Sep 17 00:00:00 2001 From: Vincent Breitmoser Date: Thu, 14 Nov 2019 10:59:30 +0100 Subject: [PATCH] i18n: fix some more "email" strings --- templates-untranslated/about/news.html.hbs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/templates-untranslated/about/news.html.hbs b/templates-untranslated/about/news.html.hbs index aa03bf7..dabb522 100644 --- a/templates-untranslated/about/news.html.hbs +++ b/templates-untranslated/about/news.html.hbs @@ -63,7 +63,7 @@ Our traffic is currently at about ten requests per second (more during the day, less on the weekend), - and we delivered roughly 100.000 mails + and we delivered roughly 100.000 emails in the last month. No sweat. @@ -82,7 +82,7 @@ You can find a more complete list here. -

Secure mail delivery with MTA-STS

+

Secure email delivery with MTA-STS

One improvement that deserves special mention is @@ -97,12 +97,12 @@ instead of a proper one (e.g. from Let's Encrypt). But delivery failures upset customers more than reduced security, - and many mails are still delivered without encryption. + and many emails are still delivered without encryption.

With MTA-STS, domain operators can indicate (via HTTPS) - that their mail server does support encryption. + that their email server does support encryption. When a secure connection can't be established to such a server, message delivery will be postponed @@ -113,7 +113,7 @@ This is extremely useful for service like keys.openpgp.org. If encryption isn't reliable, - attackers can intercept verification mails relatively easily. + attackers can intercept verification emails relatively easily. But for providers who have MTA-STS deployed, we can be sure that every message is delivered securely,