Sieve: include for global/system scripts fails when the target script name has uppercase characters

Issues
1

Issue Description

When trying to include a system sieve script that has uppercase letters in its name from another system sieve script, stalwart can’t find it.

Expected Behavior

Included system scripts with uppercase letters are found

Actual Behavior

script is not found, error log suggesting it tries to find a script with a lowercase name

Reproduction Steps

  1. Create a Sieve System Script named “UPPER”
  2. Create a second System Script named “lower”
  3. from a third System script try to include “UPPER”, which will fail with a log message that the script “upper” is not found, same with a include for “lower” will work

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

This appears to be a genuine bug in the sieve include logic, not a configuration issue. Looking at the server source: system scripts are stored in memory keyed by their original name as saved (untrusted_scripts.insert(script.object.name, ...) in mailstore/scripts.rs), but when a script is included via Event::IncludeScript for a Global script, the lookup calls get_untrusted_sieve_script(&name_.to_lowercase(), ...) in network/mta.rs, which force-lowercases the name before searching the map.

So any global/system script whose stored name contains uppercase characters will never match on lookup, since the map key retains the original case but the include lookup always searches for the lowercased version. Scripts with all-lowercase names work by coincidence, since the lowercased search key happens to match the stored key.

This is a genuine mismatch between how names are stored and how they’re looked up during include, confirmed in the current source, and matches your reproduction exactly. A staff/dev follow-up will be needed to fix the lookup (or normalize storage) so it’s consistent.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Fixed in v0.16.18 (yet to be released).