Reject disposable email domain

[tassoman]

Summary

When email registration is mandatory, as administrator, I get many people using disposable email services, who brings my mailing into spamlists.

You can make use of this mantained Public Domain list, they have examples in their documentation.

Purpose

As administrator, I want to decline account creation using disposable email domains so that I don't risk to get caught into spamlists while mailing them as described before, into privacy policy they accepted (GDPR compliant).

Do you want to implement this feature yourself?

• [ ] Yes, I will implement this by myself and send a pull request

[kakkokari-gtyih]

Domains to be blocked can already be configured (Control Panel > Security > Banned Email Domains), so you may wish to add the relevant list there yourself.

[tassoman]

There are nearly 5000 domains in the list. Do the banned domains field can store so many items?

[kakkokari-gtyih]

I believe it is possible and should make it possible if it's impossible right now.

You may be considering embedding that domain list as a preset within Misskey, but this creates the problem that the list can only be updated through Misskey version upgrades. Since disposable email domains are rapidly increasing, this is not an appropriate approach. Additionally, I believe the method of fetching the list periodically from somewhere should be avoided, as it could cause devastating effects if the list were hijacked.

[samunohito]

off-topic:

実装を見ていて気になったので、この設定を扱う際の技術的な注意点として共有です。 現在 Misskey では、禁止メールドメインは instance meta に varchar[] として保持されています。

@Column('varchar', {
	length: 1024,
	array: true,
	default: '{}',
})
public bannedEmailDomains: string[];

このカラムに、外部リスト由来の 数千件規模（～5,000件）のドメインを入れる場合、以下の点は意識しておいた方がよさそうです。

• 1レコード内の可変長データがかなり大きくなる

  • 更新時に物理的な書き換えコストが読みにくい

• 部分更新・差分管理ができない

  • 配列全体を差し替える形になるため、変更履歴の追跡や運用時の可観測性が下がる

• 参照・シリアライズコスト

  • 管理者APIや設定取得時に、意図せず「巨大な設定値」を毎回扱うことになる（そして、この巨大な設定値をメモリに持ち続けることになる）

即座に問題になるという話ではありませんが、実際に数千件単位のドメインを入力・運用する場合は、こうした性質を念頭に置いておくと安全だと思います。

[kakkokari-gtyih]

You can also make use of external APIs at your preference for email protection (including disposable emails)

[tassoman]

Thank you everyone for pointing at concerns and alternative solutions.

Verify Mail io looks like an easy solution but can't fit, because too expensive costs. When I opened this issue, I was also concerned about adding 5000 items in a memory array (coming from the DB?). This is probably stealing resources. So my question was about adding into "core" as static scripting, as you said before maybe is not effective. Source code deployments maybe are not contemporary to blacklist growth.

Finally, I guess the TrueMail-RB solution, self hosted, can be a solution. I just need to load the blacklist in the configuration. https://truemail-rb.org/#/architecture

This kind configuration would be the most effective.