Status check against .well-known/mta-sts.txt

Hello there!

TLDR: It will be great to have a check that [domain]/.well-known/mta-sts.txt exists and is valid.

Use case:
I use mailinabox as mailserver, but I do not redirect my A and AAAA records for the domains I maintain to my mail-box, as those need to host complex sites with php, dbs and some other custom nginx that mailinabox does not support.

I’m aware that current status checks promt an error about invalid A and AAAA records, but I have live with that. What I wasn’t aware until today is that mailinabox was setting a path to /.wellknown/mta-sts.txt that is mandatory for propper mta-sts email protection.
I just set that in my web-box to address the issue, but I believe it will be in everyone’s benefit to add such a check, as I know that there are more people out there with a similar use case than me.

I can work on that (it would’t be my first contribution to miab… but the second), but before investing any time on that, I’d like to confirm that it will be worth it, and that if well implemented, it will end in the master repo for a next version.

Thx in advance.

1 Like

You don’t need to create A records for your root domains pointing to MiaB, because MiaB runs on a subdomain like box.yourdomain.tld or mail.yourdomain.tld.

The External DNS page says: “Sets the IP address that yourdomain.tld resolves to for web hosting and other services besides mail. The A record must be present but its value does not affect mail delivery.”, which means that the A records can point to another server where you host your web services,

However, I’m pretty sure that not even that is strictly necessary, because I’d say it’s perfectly possible to host email under a domain name that doesn’t serve any website or web services at all, and at least in my expirience email deliverability for a particular domain name doesn’t depend on whether or not a website is served from that domain name, or whether or not an A record exists in DNS for that domain name.

Yes, but that should be served via mta-sts.yourdomain.tld/.well-known/mta-sts.txt, so the following DNS records are all you actually need for mta-sts to work:

mta-sts       IN      A       <IP ADDRESS>
_mta-sts      IN      TXT     "v=STSv1; id=XxxxxxxxxxxxxxxxxxxX"

TLDR: You are right about the mta-sts subdomain, I missread some info I got. However, the A and AAAA records are necessary as per my experience, but not necessarily need to point to miab server… that part could be improved.

The long part now:

No, you don’t, but it still shows as an error on status check, one like this:

This domain should resolve to this box’s IP address (A xxx.xxx.xxx.xxx) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to yyy.yyy.yyy.yyy in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.

I believed the same, until I got some email delivery errors staying in the response that it was due to the lack of an AAAA record on the main domain. Adding that to my DNS solved the issue.

You are right here. I missread an email I received yesterday at my postmaster account (at first I though it was some scam as many other times, however, after reading it carefully and doing some checks, I found it to be legit). The email stated this, but I missed the mta-sts subdomain in the error message.

Hello,
We are a group of security researchers from Virginia Tech and the Max Planck Institute for Informatics currently conducting a study on MTA-STS (Mail Transfer Agent Strict Transport Security) configurations across various domains.
During our most recent scan on September 29th, 2024, we identified potential issue(s) with your domain [domain.tld]. Specifically, we encountered the following error(s):
1.We were unable to resolve the policy host. We attempted to retrieve your policy from https://mta-sts.[domain.tld]/.well-known/mta-sts.txt
We are reaching out as you may not be aware of this issue. Addressing these issue(s) is important as it may impact how emails are delivered for your domain.

I added the .well-known mta-sts thing to all my domains, but I clearly was mistaken and I can undo that now. I’ll let the email sender know.

So forget about the "Status check agains .well=known/mta-sts.txt check request. But I can start another thread about the main domain A/AAAA records showing as an error if you think it will be usefull… my proposal would be to show an error if they are not set, but a warning or even an OK if they are, even if they point to a different IP.

Hmm, even though I’ve been using a Mailcow server as my primary mail server for quite some time now, which doesn’t serve a static web page for all mail domains out of the box like Mail in a Box does, and therefore I don’t have any A/AAAA records set up for my mail domains, I’ve never experienced issues like this.

Of course, this doesn’t mean that there aren’t mail servers out there that reject emails because of missing A/AAAA records, although I don’t think they should.

Yes, I mean, why not, if missing A/AAAA records have the potential to cause problems, it would certainly be helpful to make users aware of it. However, I’d suggest a warning rather than an error, similar to the warnings about the nameserver not pointing to MiaB when using external DNS, or when DNSSEC is not enabled for a domain.

Just for your info. This is the error message I got from the server (twice, until I added the missing record):

This is the mail system at host [miab_server.tld].
I’m sorry to have to inform you that your message could not
be delivered to one or more recipients. It’s attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<destination_email>(mailto:[destination_email])>: host mx1.[remote_mailserver.tld][xxx.xxx.xxx.xxx] said: 550
Sender ([domain.ltd] has no A, AAAA, or MX DNS records. (in reply to RCPT
TO command)

I guess I could provide the [remote_mailserver.tld] if needed for checks, but unsure if that will be useful without a known email address at that mailhost, which I can not provide for privacy reasons.

Well but that could also be due to a missing MX record, as it says no A, AAAA, or MX DNS records.

Let’s say your mail server is hosted at box.domain1.com and you want to use it to send and receive mail for domain1.com and domain2.com, the only A record that is technically necessary is the one in the DNS zone of domain1.com pointing to the mail subdomain:

domain1.com:

box    IN    A    <IP ADDRESS>
@      IN    MX   10 box.domain1.com.

domain2.com:

@      IN    MX   10 box.domain1.com.

Also, I couldn’t find any RFC that says that you have to set an A record pointing to a web server in order to be allowed to send/receive email from a particular domain, and there’s certainly no technical need for it, since that’s what MX records are for.

But of course an email provider can still reject emails based on this, or literally for whatever reason they want, and send back some standard email, or even silently reject your emails. There are even email providers, such as Deutsche Telekom, that require you to host a website with a disclaimer for your email domains, otherwise they won’t accept your emails.

I thought that too. But as I see it (but I’m not a native English speaker) that OR in that sentence can be read as “you need to have any of this” or “you are lacking any of this”.

There is actually a check for the MX DNS register in Status check.

Domain’s email is directed to this domain. [[domain.ltd] ↦ 10 [mail_box.ltd]]

As I said, I had MX and A records, but still got that message twice… and then I added the AAAA and they were gone.

Nevertheless, I agree with you, we should not add rules depending on what a particular email provider states as mandatory, but, following RFCs. And if that is not stated in an RFC… let’s not add this now (as we won’t never stop adding random rules).

Regards.
lamberete

Yeah, they probably think that if there’s no A record and therefore no website for the root domain, you must be a spammer, and of course they’re not interested in people hosting their own mail servers in the first place, because they want to sell their services :wink:

Anyway, I only use my mail server for personal use and don’t send many emails, so I can’t really say how common it is for mail providers to reject emails due to missing A/AAAA records. But if it’s a relatively common problem, a note or warning might be useful for people using external DNS.

On the other hand, it is mentioned on the External DNS page, so I guess one could argue that users should assess for themselves whether they should implement it or not :slight_smile:

Well, let’s see if someone else has experienced this (if anyone ever gets this far in this thread), and if so we can consider adding that.

Until then… thanks for the debate. I’m happy I asked first before implementing anything :wink:

Have a good one!

1 Like