R_MIXED_CHARSET too aggressive? (Fixed in v0.11.0)

[andreymal]

I sent a simple email from gmail to Stalwart:

andreymal, hello!

Result:

X-Spam-Status: Yes, score=5.6
X-Spam-Result: DWL_DNSWL_NONE (0),
	DMARC_POLICY_ALLOW (-0.5),
	MID_RHS_MATCH_FROMTLD (1),
	TO_DN_NONE (0),
	TO_MATCH_ENVRCPT_ALL (0),
	FROM_HAS_DN (0),
	RBL_SENDERSCORE (2),
	DKIM_SIGNED (0),
	FROM_EQ_ENVFROM (0),
	RCVD_TLS_LAST (0),
	PREVIOUSLY_DELIVERED (0),
	FREEMAIL_ENVFROM (0),
	RCPT_COUNT_ONE (0),
	RCVD_IN_DNSWL_NONE (0),
	RWL_MAILSPIKE_POSSIBLE (0),
	RCVD_COUNT_ONE (0),
	ARC_NA (0),
	FREEMAIL_FROM (0),
	SPF_ALLOW (-0.2),
	PYZOR (3.5),
	DKIM_ALLOW (-0.2)

(I have no idea what's wrong with MID_RHS_MATCH_FROMTLD and PYZOR, but I don't care right now)

I sent a slightly diffrernt email from gmail to Stalwart:

andreymal, привет!

Result:

X-Spam-Status: Yes, score=7.31
X-Spam-Result: TO_DN_NONE (0),
	ARC_NA (0),
	DKIM_SIGNED (0),
	DKIM_ALLOW (-0.2),
	MIME_BASE64_TEXT (0.1),
	FROM_EQ_ENVFROM (0),
	FROM_HAS_DN (0),
	RCPT_COUNT_ONE (0),
	FREEMAIL_FROM (0),
	DWL_DNSWL_NONE (0),
	RCVD_COUNT_ONE (0),
	SPF_ALLOW (-0.2),
	DMARC_POLICY_ALLOW (-0.5),
	TO_MATCH_ENVRCPT_ALL (0),
	RCVD_TLS_LAST (0),
	FREEMAIL_ENVFROM (0),
	PYZOR (3.5),
	RWL_MAILSPIKE_POSSIBLE (0),
	RCVD_IN_DNSWL_NONE (0),
	R_MIXED_CHARSET (5),
	RBL_SENDERSCORE (2),
	MID_RHS_MATCH_FROMTLD (1),
	PREVIOUSLY_DELIVERED (0)

WHAT.

If the user's native language is not English, it's expected that most emails will contain characters from at least two languages.

So is R_MIXED_CHARSET (5) basically discriminates against everyone who doesn't speak English?

For the new spam filter, I'd suggest leaving this rule disabled by default

[mdecimus]

The Unicode mixed-script rule identifies emails that include characters from different writing systems (scripts), such as combining Cyrillic and Greek characters or Latin and CJK (Chinese, Japanese, Korean) characters. However, it’s important to note that combining standard ASCII English text with another script (e.g., Cyrillic, Greek, or CJK) does not trigger this rule. The detection is focused on scenarios where multiple non-ASCII scripts are mixed, which can sometimes indicate an attempt to bypass spam detection or obscure malicious content.

While the use of mixed scripts can be perfectly legitimate for multilingual communication, spammers often exploit such combinations. For instance, they might use visually similar characters from different scripts (e.g., the Latin "a" and Cyrillic "а") to create deceptive text or hide malicious links. To address this, the spam filter assigns a slightly increased score to such emails as part of its broader analysis.

It’s also important to emphasize that this rule alone does not reject an email outright; it simply contributes to the overall spam score, which considers many other factors. If your emails are being flagged or rejected, you can adjust the score of the R_MIXED_CHARSET tag.

[andreymal]

where multiple non-ASCII scripts are mixed

I was only using Cyrillic (the body is the only difference between these two emails), but R_MIXED_CHARSET is still triggered for some reason. Does this mean there is a bug somewhere? _{(I think I can share both .eml files if needed)}

you can adjust the score of the R_MIXED_CHARSET tag.

Of course I can, but the problem is that the potential recipients I'll be sending my emails to won't do that, which is why I'm concerned about the default behavior _{(assuming that Stalwart will become more popular in the future because Stalwart is cool)}

[mdecimus]

I was only using Cyrillic (the body is the only difference between these two emails), but R_MIXED_CHARSET is still triggered for some reason. Does this mean there is a bug somewhere?

The email probably had a character that was not Cyrillic or ASCII. It won't be triggered by an email that is only Cyrillic or mixes Cyrillic with ASCII (English).

In any case, the score of the R_MIXED_CHARSET tag has been lowered to 2.0 in the new spam filter (not yet released).

[andreymal]

Well, I tried to add some debug prints around text_body.is_single_script:

// ...
TextPart::Html { text_body, .. } => {
    println!("DEBUG: html text_body is {text_body:?}");
    let s = AugmentedScriptSet::for_str(text_body);
    println!("AugmentedScriptSet: {s:?}");
    println!("is_single_script: {:?}", text_body.is_single_script());
    !text_body.is_single_script()
},
// ...

And this is what I got in stdout:

DEBUG: html text_body is "Я R"
AugmentedScriptSet: AugmentedScriptSet {∅}
is_single_script: false

As you can see, there are exactly three characters in this body:

• Cyrillic Я
• ASCII space
• ASCII R

According to your description, MIXED_CHARSET should not be triggered, but it's still triggered because text_body.is_single_script() returns false (and ! transforms it to true).

I'm not familiar with AugmentedScriptSet and don't know what behavior is expected, but according to your description, there is definitely a bug somewhere

[mdecimus]

This has now been fixed.

[andreymal]

It works much better now, thanks!