Optional visual warnings for unexpected sender domains on aliases

[sigfridvonshrink]

Proposal: Optional per-alias unexpected sender domains visual warnings

Summary

Unexpected sender warnings: an opt-in, per-alias feature that marks emails from previously unseen sender domains, with one-click trust management and no effect on delivery.

This would be warning-only: no blocking, rejection, quarantine, or delivery change. It should also have zero effect on the existing customer base unless explicitly enabled. If the feature is not enabled for an alias/account, SimpleLogin should behave exactly as it does today.

I have implemented this in my private SimpleLogin clone and have found it very useful. It makes it easy to detect possible alias leaks or unusual sender/alias combinations without continuously reading the full From field and mentally matching it against the alias used.

User value

Many users create one alias per service or context. In those cases, an alias often has a small set of expected sender domains.

If an alias created for one service suddenly receives mail from an unrelated domain, the message may still be legitimate, but it is useful for the user to notice it immediately.

This feature would provide a softer middle ground between:

1. forwarding without any indication; and
2. blocking senders.

It would help users notice possible alias leaks, unexpected reuse of an alias, or suspicious sender/alias combinations while preserving normal forwarding behaviour.

Proposed behaviour

Each alias could have one or more expected sender domains.

If the feature is not enabled, or if no expected sender domain is configured, nothing changes.

If expected sender domains are configured:

1. emails from expected sender domains are forwarded normally, without modification;
2. emails from unexpected sender domains are still forwarded normally, but receive a visual marker.

The domain should be matched at the registered-domain level. For example, mail.example.com, notifications.example.com, and bounce.example.com should all be treated as example.com. Requiring users to mark individual subdomains would add friction and likely provide little practical value.

Suggested user-facing wording:

Warn me when this alias receives mail from a sender domain that is not marked as expected.

I would avoid describing this as a “whitelist”, since the feature is not meant to enforce delivery restrictions.

Warning markers and decay

The feature should use a decaying marker system:

⚠️⚠️  New unexpected sender
⚠️    Recent unexpected sender
〰️    Older unexpected sender, still not marked as expected

Proposed schedule:

1. ⚠️⚠️ during the first 24 hours or for the first 2 emails;
2. ⚠️ during the first week or for the first 5 emails;
3. 〰️ afterwards.

The reason for the decay is to avoid warning fatigue. A new unexpected sender should attract attention. But if the user has already seen several emails from the same domain and has not acted, the marker should become less intrusive while still acting as a reminder that the sender domain has not been explicitly marked as expected.

In practice:

⚠️⚠️ = pay attention now
⚠️ = still recent
〰️ = still unrecognised, but probably already seen before

Marker placement

Users should be able to choose where the marker is inserted.

Option 1: Display From

Insert the marker into the display name of the forwarded From field, replacing the first space.

Example:

Original:
John Smith <john@example.com>

Displayed as:
John ⚠️⚠️ Smith <john@example.com>

This is visible in the inbox and associates the warning directly with the sender. It also avoids modifying the subject. Since SimpleLogin already rewrites the display From for forwarded messages, this seems like a natural placement option.

Option 2: Subject

Insert the marker into the subject by replacing a space, rather than always prefixing the subject.

Suggested strategy:

replace the 3rd space, if it exists;
otherwise replace the 2nd space, if it exists;
otherwise replace the 1st space, if it exists;
otherwise use a fallback for very short subjects.

Example:

Original:
Your monthly account statement is ready

Marked:
Your monthly account ⚠️⚠️ statement is ready

This should be less disruptive than prefixing:

⚠️⚠️ Your monthly account statement is ready

because it mostly preserves the beginning of the subject, which may help with sorting, threading, mobile previews, and visual recognition of recurring emails.

If markers are inserted into the subject, they should be automatically removed from user replies, so that the marker does not leak back to the original sender and does not permanently pollute conversation threads.

Possible UI wording

Alias-level setting:

Expected sender domains

SimpleLogin can warn you when this alias receives mail from a sender domain that is not marked as expected.

Emails are still forwarded normally. This only adds a visual marker to help you notice unusual sender/alias combinations.

Action label:

Mark example.com as expected for this alias

Marker explanation:

Warning markers become less prominent after you have already seen the sender several times:

⚠️⚠️ New unexpected sender
⚠️ Recent unexpected sender
〰️ Older sender, still not marked as expected

Open questions

1. Should the default marker placement be Display From or Subject?
2. Should marker placement be configured globally, per mailbox, or per alias?
3. Are the proposed decay thresholds reasonable?
4. Should decay be based on time, message count, or both?
5. Should the sender domain be derived from the visible From, the envelope sender, or both?

Suggested initial implementation scope

For an initial version, I would suggest keeping the feature conservative:

1. no automatic blocking or quarantine;
2. no automatic bulk migration;
3. no change to existing users unless they explicitly enable the feature;
4. user choice between Display From and Subject placement;
5. automatic removal of subject markers from user replies where Subject placement is used.

NOTE: There are some feature requests for whitelisting domains but mine is materially different from them.

[sigfridvonshrink]

Update: implemented and running in production (on my fork)

I built it and have been running it in production on my self-hosted instance for a while.

What it does: it is a per-alias soft allow-list of trusted sender domains. Mail from a domain that isn't on an alias's list is still delivered, but the forwarded message gets a small escalating marker (⚠️⚠️ → ⚠️ → 〰️) in the From display-name or Subject that fades as a sender becomes familiar. Off by default; entirely invisible until enabled, so zero impact on current users.

How it differs from #2694 (sender-blacklists) and #2384 (block domains): they block; mine warns. I think warn-don't-block is a much safer model for email:

• It can't lose mail. A wrong block will silently drop/bounce legitimate email; a wrong marker just adds a glyph the user can ignore. Zero false-negative cost.
• Decay solves alert fatigue. A static warning on every non-trusted sender becomes noise to tune out of. The marker is loud only when it is important (a brand-new or rare sender) and then decays to a faint 〰️ as that sender becomes familiar, and disappears entirely once the domain is trusted. Attention tracks actual risk instead of firing constantly, and this will keep the signal meaningful over time.
• No domain-rotation arms race. A deny-list is never complete — block x@sub.dom, the sender moves to y@sub.dom (raised in Ability to block domains when receiving emails #2 #2384 itself). An allow-list flags any unexpected/new domain inherently, loudest exactly when a sender is brand-new.
• No delivery-decision change. It injects a marker into already-forwarded mail, so it doesn't touch bounce/quarantine/DMARC handling.
• Low support/liability needs. Nothing is ever blocked, so it won't generate "I'm not receiving emails" reports.
• It's reversible and self-healing: Trusting a domain is one click and the marker is gone; the decay means established senders quiet down on their own.

I implemented it in a single dedicated and tested module (not in the settings/view code), and placed it behind an off by default user flag, and I added with unit + API + validation tests. Default behavior is identical to upstream when disabled.

I'd be happy to open a PR if there's appetite for this direction.

@acasajus — since you reviewed #2694 and #2384, I'd be interested in your thoughts on whether a warn-based (rather than block-based) approach is one you'd consider. Happy to share the branch or a draft PR.