MSC3174: An error code for spam rejections

[Yoric]

Rendered

[erkinalp]

Suggested change

	- `m.reject.spam` -- spam has been detected (e.g. message or username is spam);
	- `m.reject.inappropriate` -- unacceptable content has been detected (e.g. a user attempting to register `@deathtojews:...`);
	- `m.reject.investigation` -- account is suspected of being a spambot and is deactivated pending investigation;
	- `m.reject.server` -- federation with this server has been deactivated (e.g. because server is used to send spam);
	- `m.reject.spam` -- spam has been detected (e.g. message or username is spam);
	- `m.reject.inappropriate` -- unacceptable content has been detected (e.g. a user attempting to register `@deathtojews:...`);
	- `m.reject.investigation` -- account is suspected of illegal activity and is deactivated pending investigation;
	- `m.reject.server` -- federation with this server has been deactivated (e.g. because server is used to send spam);
	- `m.reject.ua` -- disallowed user agent or user agent family (including implicitly detected behavioral patterns)
	If a server does not want to tell the user the reason, it should use `m.reject.ua` as the reason.

Signed-off by: Erkin Alp Güney erkinalp9035@gmail.com

[MTRNord]

Do you mean bots that use specific useragents? That might be dangerous as plenty bots use default User-agents. especially the bad ones do. So I would think that it causes false positives.

[erkinalp]

So I would think that it causes false positives.

Indeed it can. But nowhere in the proposed change tells the user agent detection must, or even should, be based on the User-Agent strings alone. Instead, the kinds of user agents that act similarly to the suspected user agent may be rejected by this error code.

Meaning, habitual offender would get m.reject.spam, and accounts that act like them but not quite would get m.reject.ua instead.

[tulir]

If a server doesn't want to tell the user the reason, it shouldn't include a kind field at all.

[Yoric]

1. The idea is that kind is optional, so as @tulir mentioned, if we don't want to tell the reason, just don't include a kind.
2. For m.reject.investigation, it doesn't have to be illegal activity. The notion of "illegal" is very complicated in Matrix-land, as each country has different laws. This is about any activity that requires investigation, typically a user being suspected of being a member of a spambot family.

[Yoric]

While I don't think that m.reject.ua would cause any issue, I don't see a good use case for it yet. Unless there's a clear and present use case, I would suggest postponing m.reject.ua to another MSC.

[erkinalp]

Add a new error code, and fix the title

[0x1a8510f2]

Seeing as rejections could happen for reasons other than spam (for instance, m.reject.server does not explicitly specify spam to be the reason, only a possible reason), perhaps this should just be more generic, like M_REJECTION?

[Yoric]

The idea to call it M_ANTISPAM_REJECTION is due to the fact that the message is rejected by the antispam filter, even if it's not necessarily spam, but you're right, that's a fine nuance that doesn't bring anything to the table.

I'm ok with M_REJECTION.

[erkinalp]

Required error kind for plausible deniability of rejection reasons

[erkinalp]

Suggested change

	2. Any `M_ANTISPAM_REJECTION` error MAY come with a field `kind`, which may contain any of the following values:
	2. Any `M_ANTISPAM_REJECTION` error MUST come with a field `kind`, which shall have a value of the string type,
	with the recommended set with corresponding below:

Signed-off by: Erkin Alp Güney erkinalp9035@gmail.com

[uhoreg]

How does requiring kind give plausible deniability?