mail blacklisting is overblocking

[svoeth]

Steps to reproduce the problem

I use a blocklist from https://github.com/disposable-email-domains/disposable-email-domains to prevent spamaccount for maildomain blocking. A user reported to me today that he was not able to register with his personal maildomain which is not listed in above mentioned list. It was also not listed in the output of "tootctl email-domain-blocks list" But I was able to reproduce this behavior. His domain is being blocked. Sadly i am not able to share the domain publicly, but i am happy to provide it to whoever is debugging the issue.

Dns-resolving is not being used. Also the actual mailserverdomain (ionos) is also not in the blocklist. If i remove the blocked domains, everything works fine.

What happens

1. add some/a lot of domains to mail-blacklist
2. non-listed domain gets blocked

Expected behaviour

only blacklisted domains get blocked

Actual behaviour

non blacklisted domain got blocked

Specifications

v3.5.1

[svoeth]

i can't even force it by cli...

RAILS_ENV=production bin/tootctl accounts create $USERNAME --email mail@nonblacklist.tld --force
Failure/Error: email
    verwendet einen nicht erlaubten E-Mail-Anbieter

[nightpool]

Mastodon uses MX name resolution to prevent people from getting around the email blocklist by using "cloaked" domains, if the domains resolve to the same IP address. My guess is that the user's email domain uses the same IP as some other email on your (very large) blocklist. Unfortunately, without any details about what the legitimate or blocked domains are, there's no way we can reproduce this issue or fix it. If you're able to provide that information we may be able to help you troubleshoot the issue a little more, but it's probably just that the domain resolves to the same IP address as another blocked domain

[svoeth]

Mastodon uses MX name resolution to prevent people from getting around the email blocklist by using "cloaked" domains, if the domains resolve to the same IP address.

According to the documentation¹ and code² it only does MX lookup if explicitly chosen and it adds the found records to the list. I imported the domains by cli and did not use the necessary flag (--with-dns-record). The MX server is also not listed in the blacklist. Therefore MX lookup should not take place. Otherwise this would be a bug.

I will ask the user if i can provide the domain publicly, because it is his own domain and therefore a privacy matter.

¹https://docs.joinmastodon.org/admin/tootctl/#email-domain-blocks ² https://github.com/mastodon/mastodon/blob/main/lib/mastodon/email_domain_blocks_cli.rb#L34

[nightpool]

@svoeth I think you may be misinterpreting that documentation somewhat. The way that --with-dns-records works is that when adding blacklist items, it will resolve the MX and A records that the passed-in domains point to, and add those values to the blacklist as well.

This is entirely separate from the code for checking the blacklist, which always resolves the email domain that the user is signing up with, to check if any of the resolved items are on the blacklist.

[svoeth]

ok, well maybe we are talking past each other. Of course it checks for the resolved domains, but if neither the used domain nor the MX-record are on the list it should not get blocked and neither were on the list.

Thankfully the user came back to me and i am allowed to share the domain: He could not register with @proregiotram.de The MX record is mx00.ionos.de and mx01.ionos.de The A record resolves to an IP Adress

Neither domain, mx-domain nor the ip (or its reverse records rns.ui-dns.com. dnsadmin.ionos.com) are on the blocklist

In my opinion this maildomain should not be blocked. As stated before the blocklist was added by cli without --with-dns-records.

This is the script template which adds the maildomains from the git repo mentionedf in OP: https://codeberg.org/stvo/mastodon-ansible-nodocker/src/branch/main/playbooks/templates/home/mastodon/addmaildomains.sh.j2

[svoeth]

Solved in https://github.com/mastodon/mastodon/pull/18190

Thanks @Gargron