illwieckz
commented
2 years ago The output mail has been tested on various services like mail-tester.com example and appmaildev.com. They're services that allows to send an email for real and validate it for real.
The DNS configuration has been checked using various services like easydmarc.com.
Both ipv4 and ipv6 addresses has been checked for blacklists with mxtoolbox.com and dnschecker.org.
Our ipv4 wasn't listed but our ipv6 was blacklisted in one list because it didn't had a proper reverse. Once the reverse had been set I had to delist it. manually.
Now both our ipv4 and ipv6 are now seen as not listed: ipv4 mxtoolbox, ipv4 dnschecker, ipv6 mxtoolbox, ipv6 dnschecker.
The mail server output was reconfigured to follow actual best practices.
Here are some reports on what has been done, and some considerations about what can be done more.
Reverse
Both ipv4 and ipv6 now have a proper reverse.
Previously, only ipv4 had a proper reverse.
SPF
SPF is a mechanism servers receiving mails from us can use to know if the mail comes from our server by validating the originating ip.
The configuration is stored in a specific DNS entry.
SPF is now configured this way:
v=spf1 a ip4:172.86.178.34 ip6:2604:5800:0:55::2 mx ~allIt means
unvanquished.netmail are considered legit if coming from our ipv4 and ipv6 or ouraandmxDNS entries, but is accepted while not being considered legit when coming from everywhere else (~all, SoftFail). In case the mail is relayed this may increase the risk the mail to be flagged as spam (but it should not be rejected).Previously the SPF entry was configured to block mails from “everywhere else“ (
-all, Fail), this was a bad idea of mine as there are legit use cases where a mail coming from us can be relayed. We may even want to not use SoftFail but Neutral for mails not coming from our servers. See below why.SPF is bad by design but we better have an SPF configuration as having a SPF configuration usually increases the goodness score of our server as seen by antispam software: it means our domain is actually expected to send mails and there is an admin able to configure it.
DKIM
DKIM is a mechanism servers receiving mails from us can use to know if the mail comes from our server by validating a key.
We now have a 4096bit sha256 private key, the public key is stored in a specific DNS entry.
The server now signs every mail coming from us using this private key and then server receiving mail can verify the mail really comes from us by checking it against the public key. This mechanism works in all case even if our mails are relayed (something SPF don't do).
Previously we didn't have DKIM at all.
Having DKIM configured tells antispam software our domain is actually expected to send mails and there is an admin able to configure it, but also allow mail servers receiving our mails and also mail clients to actually verify the mail comes from us using cryptographic signature, which is a good proof the mail really comes from our server (even if it had been relayed).
DMARC
DMARC is a mechanism servers receiving mails from us can use to know what to do with SPF and DKIM information.
The configuration is now configured this way:
v=DMARC1;p=reject;sp=reject;pct=100;rua=mailto:xxxxxx;ruf=mailto:xxxxxx;ri=86400;aspf=r;adkim=s;fo=d. Thep=rejectkey means that if the following rules are not met, the mail should be rejected. theaspf=rrule (r for Relaxed) means if the mail doesn't match SPF configuration, the mail will be accepted anyway. Theadkim=srule (s for Strict) means that if the mail doesn't match the DKIM configuration, the mail will be refused.Previously we just had a dummy DMARC configuration (
"v=DMARC1; p=none") just saying there is a DMARC configuration but telling nothing to do. It was enough to tick the checkbox “we have a DMARC” configuration, meaning our domain is actually expected to send mails and there is an admin able to configure it, but now the DMARC configuration is better.BIMI
I also configured a BIMI record. BIMI is a mechanism to provide our logo to mail software to be used when displaying our e-mails. I haven't configured a trademark certificate so most providers like GMail will ignore it anyway. But the presence of the configuration is another sign of the server being actually maintained.
SPF is bad anyway
SPF is bad because it assumes every mail comes from one server to another one without being relayed, as SPF can only validate the last servers distributing the email. There are legit situations were mails are relayed.
Simple redirections: Mail from
bob@example.comcan be sent toalice@example.netthat redirects toalice@example.org. Theexample.orgserver will see the mail originating fromexample.netwhile theFrom:address is fromexample.organd SPF will fail.Mail lists: Mail from
bob@example.comcan be sent tomail-list@example.netthat redirects toalice@example.org. Theexample.orgserver will see the mail originating from example.net while theFrom:address is fromexample.organd SPF will fail.The SPF design is not compatible with the mail architecture itself. Unfortunately SPF is widely used and expected to be configured. One can set
allor?all(equivalent) instead of~allto actually tell there is no reason that a mail from us coming from another server is wrong, but I'm afraid that can be seen as a bad configuration. Maybe I'll change that in the future if that looks better.What can be done next
Our mail server has two usages:
apply@).Those addresses are redirections for 99% of them. If a spammer sends an email to something@ our domain that is a redirected address, the final address will see our server as the origin of the spam and reduce the goodness score or our server. We can't take the risk to block mails using tools like spamassassin (unless they're very obvious) and flagging them as spam would change nothing.
The most efficient way to block very obvious spams is greylisting. When receiving a mail from an unknown source our server would just say “come back later”, and if the mail server actually resend the mail, the originating source will be whitelisted and the mail accepted (and redirected if needed).
It works very well, but by using it elsewhere, I know a big problem that is currently growing is that the industry doesn't take care of it and badly configure their systems. For example, many mail-based two-factor authentication has sent-by-mail token timeout smaller than the time they configured their mail server to resend the mail if the destination says “come back later”. That's just a fault in their design, but they usually don't care. Also, many of them will almost never send mails from the same mail server, meaning once you get the out-of-date token, retrying will not get the next token avoiding the greylist since it would be sent with yet another server…
That's why I have not implemented greylisting on our server yet, because I want to think twice about it. Given we don't receive a huge amount of mails and we don't manage a huge amount of accounts on social platforms that may badly implement mail authentication, this may be fine.