Welcome to the Hotel California: MTA-STS Unintended consequences?

1

I am just wondering if anyone is aware of the unintended consequences of mta-sts?

Specifically, that if someone moves their email from MiaB to a different provider, they will be in a kind of “Hotel California” situation.

Of course, the ONLY provider who enforces mta-sts is Google, and they WILL cache your mta-sts.txt file for the domain for the duration of the 7 day max_age entry of the mta-sts.txt file. Which means no emails from Google for your domain when you check out, cause you can ‘never leave’ (for a week).

`Sorry, I just had to make a play on one of the world’s most popular rock songs.’

1 Like
2

I’d say that’s a pretty easy PR to submit, but I’d require you to sing the song for it to be accepted. (o;

3

I am still thinking through posting the issue on GitHub and thought that I would get some input from the community here first …

How this came to my attention is that the email service provider I team up with to provide the SMTP relay brought it up to me. He pointed out that there have been clients who had been complaining that they could not receive emails from Google and were complaining to him since they had no problems at all receiving emails from Google before they switched providers. It seems that Google does not sent a delivery failure notice for several days when this happens. When they do finally send the notice, the bounce message refers to STS policy. All of the clients that this affected came from MiaB.

Oh, and the last thing you want to hear is me singing, lol! :slight_smile:

4

I only just skimmed RFC 8461, but found this:

10.3. Denial of Service

We additionally consider the Denial-of-Service risk posed by an
attacker who can modify the DNS records for a recipient domain.
Absent MTA-STS, such an attacker can cause a Sending MTA to cache
invalid MX records, but only for however long the sending resolver
caches those records. With MTA-STS, the attacker can additionally
advertise a new, long “max_age” MTA-STS Policy with “mx” constraints
that validate the malicious MX record, causing senders to cache the
policy and refuse to deliver messages once the victim has resecured
the MX records.

This attack is mitigated in part by the ability of a victim domain to
(at any time) publish a new policy updating the cached, malicious
policy, though this does require the victim domain to both obtain a
valid CA-signed certificate and to understand and properly configure
MTA-STS.

Similarly, we consider the possibility of domains that deliberately
allow untrusted users to serve untrusted content on user-specified
subdomains. In some cases (e.g., the service “tumblr.com”), this
takes the form of providing HTTPS hosting of user-registered
subdomains; in other cases (e.g. dynamic DNS providers), this takes
the form of allowing untrusted users to register custom DNS records
at the provider’s domain.

In these cases, there is a risk that untrusted users would be able to
serve custom content at the “mta-sts” host, including serving an
illegitimate MTA-STS Policy. We believe this attack is rendered more
difficult by the need for the attacker to also serve the “_mta-sts”
TXT record on the same domain – something not, to our knowledge,
widely provided to untrusted users. This attack is additionally
mitigated by the aforementioned ability for a victim domain to update
an invalid policy at any future date.

And I’m guessing the original source for the max_age is from Section 3.2.

I don’t see why 86400 would be a problem, but I have to admit I’ve never looked closely at MTA-STS, although I vaguely recall figuring out that MiaB isn’t configured to use it when receiving sending.

5

I wouldn’t either except for the fact that the value is 7 days, not 1.

version: STSv1
mode: enforce
mx: box.domain.tld
max_age: 604800
6

Yeah, that’s why I mentioned the length stated in the RFC is what is used in MiaB, so I wondered if that is the original source for 604800. IOW, maybe there wasn’t any strong reason other than that was in the RFC.

7

Found it:

Originally was 86400 and changed to match the RFC example, but not stated why it should match the RFC example.

8

Ok, thanks for your investigative work. :slight_smile:

So this begs the question … are we as users satisfied with this default, or do we want to petition for it to be lowered?

OR

Alternatively, do we just make it known to people that when/if they migrate away from MiaB that this will be an issue that they will need to deal with?

Personally, I have no skin in this game. But in each of the cases of people who migrated away from MiaB to another provider, they had no clue of the unintended consequences that they’d face when leaving.

If it were up to me alone, I’d say write some extra information in the guides about issues that come up when migrating away from MiaB … such as the need to de-activate DNSSEC and this issue. But my goal here is for there to be a discussion within the community to determine the next step.

So let the discussion begin …

9

I’m not an expert on the topic, but after reading this, I don’t think it does make much sense to set the max_age to a shorter default value. If you set the max_age value too short it kind of defeats the purpose of the whole thing. If anything, it should be configurable via the web UI, or entirely optional, which would be even better.

For users who want to avoid a “Hotel California situation” :slight_smile: , I would recommend to set the policy to “none” with a max_age of one day, as described here. After that you have to wait one week plus one day to be sure that there is no overlap with the old policy.

10

That would require a change that permits at least publishing a unique policy per domain, since right now MiaB uses the same policy on all domains (/var/lib/mailinabox/mta-sts.txt).

A UI change I suspect is a lot more work than some way to edit nginx.conf such as using the undocumented custom.yaml feature.

11

Ah yes you’re right, that’s not gonna work if you have multiple domains hosted on your Box and you don’t want to disable it for all of them. I also was was wrong about the “one week + 1 day” in my previous post. If you change the policy to none, it’s turned off in 24 hours or less…

Hmmm… Since the mta-sts.txt file has to be served from “mta-sts.box.domain.tld/.well-known/mta-sts.txt” I’m not sure how you would serve multiple mta-sts.txt files from one server. Or how else would you change the policy for just one of the domains? You could of course maually remove the DNS text record in the zone file, but than you would have to wait the whole week, before you can move the domain to another server…

12

I was thinking you would just serve a different mta-sts.txt file for each domain. Currently /etc/nginx/conf.d/local.conf has the following in every HTTPS server block:

        location = /.well-known/mta-sts.txt {
                alias /var/lib/mailinabox/mta-sts.txt;
        }

This is setup this way by web_update.py using nginx-alldomains.conf.

So somebody would have to figure out how to undo that either one domain at a time or all domains separately.

13

I was thinking you would just serve a different mta-sts.txt file for each domain. Currently /etc/nginx/conf.d/local.conf has the following in every HTTPS server block:

        location = /.well-known/mta-sts.txt {
                alias /var/lib/mailinabox/mta-sts.txt;
        }

Ah yes this should work and sounds easy enough to to it manually, if you want to move away a domain from your box.

I still think there should be a way in the UI to change the policy for a domain in order to remove it from the box. Or it should maybe even be completly optional in the first place. I mean Google is afaik the only big provider that enforces it anyways… Some others have set it to testing and the majority of smaller providers have not implemented it at all. :wink:

14

removing the DNS records for the mta-sta woudn’t fix the problem (after waiting 7 days)?

Well I suppose that is for all the people that are using External DNS too, if your using MiaB not sure if you can do that without going into BIND.

15

When you create Custom DNS record it overrides identical automatically created ones.

16

yeah, but what would you be doing here setting it to the new IP of the new host? I think the action that needs to happens is to be able to “delete” the record.

17

I’m not sure if it’s even an issue at all? I mean if you delete a domain from your box and move it somwhere else, you would create new DNS records and a new MTA-STS policy anyways on the new server. Also the MTA-STS record ist tied to the MX record, not to the IP address of the server. The only situation where there might be a problem would be if you move the domain to a server or provider where you can’t or don’t want to use MTA-STS. But maybe I’m missing something here…?

18

This should work. Just maually remove the TXT record for MTA-STS. After seven days you should definitly be fine. Just don’t upgrade or execute the install script during this time period, otherwise it would probably overwrite your changes.

19

This doesn’t resolve the issue reported by the OP.

20

Maybe I have to be more clear. If you want to move a domain from your server you delete only the DNS TXT record for MTA-STS. Then you use the domain for another seven days on your Mail-in-a-Box instance. After the seven days are over you move the domain to your new server / provider…

https://support.google.com/a/answer/9711996?hl=en&ref_topic=9261406