Valid messages from LinkedIn and Facebook going to Rejects folder.

[x8x]

I am assuming this two big companies follows best practice when sending messages. Both notifications from LinkedIn and Facebook group activities goes to the Rejects folder for a newly created account. After moving them to Inbox, further such messages may still go to Junk, after moving them from Junk to Inbox, some further such messages still go to Junk.

[mjl-]

What does the X-Mox-Reason header say for the message delivered to the Rejects mailbox? If there's anything without "pass" in the top-most Authentication-Results header, that would also be good to know.

It could be that the other problem you were seeing, with moving messages from Rejects to Inbox, is causing the reputation-based junk analysis to come the to wrong conclusion.

[x8x]

Regrettably, the user who encountered the issue has already deleted the pertinent emails. I'm updating to the latest version for further observation and may try to reproduce the issue. I suggest leaving this open for a bit to see if other users experience similar challenges.

[x8x]

Given that this was a one-off issue potentially related to other resolved problems, it's best to close this specific issue now for the sake of clarity. If it recurs, we can revisit it.

[x8x]

Just noticed a valid Facebook notification message in a user's Rejects folder, here its sanitised headers:

X-Mox-Reason: junk-content
Delivered-To: user@domain.com
Return-Path: <notification@facebookmail.com>
Authentication-Results: ..; iprev=pass
    policy.iprev=..; dkim=pass (1024 bit rsa)
    header.d=facebookmail.com header.s=.. header.a=rsa-sha256
    header.b=..; spf=pass smtp.mailfrom=facebookmail.com; dmarc=pass
    header.from=facebookmail.com
Received-SPF: pass (domain facebookmail.com) client-ip=..;
    envelope-from="notification@facebookmail.com";
    helo=...mail-mail.facebook.com; mechanism="ip4:../24";
    receiver=..; identity=mailfrom
Received: from ...mail-mail.facebook.com ([..]) by
    .. ([..]) via tcp with ESMTPS id
    .. (TLS1.3 TLS_AES_128_GCM_SHA256) for <user@domain.com>;
    25 Sep 2023 00:00:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=facebookmail.com;
    s=..; t=..;
    bh=..;
    h=Date:To:Subject:From:MIME-Version:Content-Type;
    b=..
X-Facebook: from .. ([..]) 
    by www.facebook.com with HTTPS (ZuckMail);
Date: Mon, 25 Sep 2023 00:00:00 +0000
To: <user@domain.com>
Subject: ..
X-Priority: 3
X-Mailer: ZuckMail [version 1.00]
Return-Path: notification@facebookmail.com
From: "Facebook" <notification@facebookmail.com>
Reply-to: noreply <noreply@facebookmail.com>
Errors-To: notification@facebookmail.com
X-Facebook-Notify: onthisday; mailid=..
List-Unsubscribe: <https://www.facebook.com/o.php?..>
Feedback-ID: 0:onthisday:Facebook
X-FACEBOOK-PRIORITY: 0
X-Auto-Response-Suppress: All
Require-Recipient-Valid-Since: user@domain.com; Monday, 25 Sep 2023 00:00:00 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary=".."
Message-ID: <..@facebookmail.com>
..

The user operates macOS Mail.app with the Junk feature activated. It's conceivable the user manually moved the message to the Rejects folder.

Or, could the user's previous actions, such as marking similar messages as Junk, influence mox's decision to categorize subsequent emails into Rejects?

A feature to consider is allowing only mox to move messages to the Rejects folder, while marking them as "mox rejected". Users should have the flexibility to move these 'rejected' messages out of the Rejects folder and back in. Messages not flagged as 'mox rejected' should not be manually movable to the Rejects folder. Attempting to do so could instead move the messages to the Junk folder, though this could pose a UX challenge.

[mjl-]

Thanks for the details!

With the current mox, only the incoming SMTP server can truly mark a message as "IsReject". If a user moves a message to Rejects, it doesn't get the same special status (when it is moved out again).

The X-Mox-Reason header gives the reason for the rejection (at the SMTP level): junk-content (more reasons at https://github.com/mjl-/mox/blob/main/smtpserver/analyze.go#L52), which indicates:

1. The message is rejected based on its content looking like junk. I.e. the bayesian filter looked at the words and they look like other messages that were marked as junk. Is this is a new account with few messages? It could be that the junk filter is making decisions on too little data. I think I still need to implement skipping the junk filter if fewer than N messages were used for training. Of course, there can always be false positives, though I don't remember having had any.
2. No previous messages from this sender were found, so there is no existing reputation for this sender, and this message is treated as if from a first-time sender. This should indicate that no other messages from this sender are in a mailbox in the account. This can happen if the user permanently deletes these messages. I would recommend to store messages like this in the Trash folder (and not empty it, or at least not for a long time (e.g. year)). That will cause it to work as a positive reputation signal for future deliveries from this sender. Storing messages in the Archive mailbox also gives it a positive signal for future deliveries from that sender (and its content for the bayesian junk filter), and storing it in the Junk folder is a negative signal for that sender. Moving a message from Rejects to Inbox does not mark it as non-junk with the current default AutomaticJunkFlags config, because Inbox is a "neutral" mailbox. If users keep all email in their inbox, they won't get non-junk classifications with most email clients (because they have no easy way to mark a message as non-junk).

It could be something else. If there are existing messages from this sender (that are marked as non-junk, either by moving to trash/archive with the default AutoJunkFlags config option on, or by explicitly marking them as such, or by keeping the message open for 5 seconds in the webmail), the reputation-based analysis may be doing something wrong. But the above is my first guess.