Antispam Options

SmarterMail comes equipped with a number of antispam features and functions that allow you to be as aggressive as you want when combating spam. Default antispam settings were configured during installation, but these settings can be modified at any time.

Due to the flexible nature of SmarterMail's antispam setup, spam checks can influence the spam decision as much or little as you want. When spam protection runs on a particular message, all enabled spam checks are performed on the message. The total weight of all failed tests is what comprises the ultimate spam weight for the message. A spam probability level is then assigned to the email using the Filtering settings and an action is taken on that message based on its total spam weight.

An added benefit to SmarterMail's antispam administration is the ability to combat both inbound and outbound spam messages. Most mail servers only allow system administrators to keep spam from entering the mail server. However, system administrators can set up global filtering rules, but allow domain administrators to override those settings to help protect their own users. Regardless of who manages the settings, SmarterMail helps protect mail users from inbound spam but also keeps mail servers from actually sending spam, thereby helping to protect the mail servers from being blacklisted.

On the Options tab, the following settings will be available:

Actions (⋮) Button

Import/Export Settings - Import or export a JSON file containing a server's antispam configuration
Reset Antispam Settings - Reset the antispam options and spam checks to the default configuration

Cards

Filtering - Define the weight thresholds and default actions for each spam level.
Trusted Senders - Exempt specific email addresses or domains from spam filtering.
SMTP Blocking - Configure the thresholds for blocking inbound and outbound spam messages
Options - Adjust basic options relating to the processing of spam and the ability for individual domains to override system-level settings.
DMARC - Enable or disable use of DMARC.
Greylisting Options - Temporarily reject email from unrecognized senders.
Remote SpamAssassin Servers - Configure an external SpamAssassin server for identifying and reporting spam.
Remote Rspamd Servers - Configure remote Rspamd servers for identifying and reporting spam.

Import or Export Spam Settings

SmarterMail can export all global spam settings as a single JSON file then allows that JSON file to be imported to other SmarterMail servers as needed. This means system administrators can configure a solid set of antispam rules on one server, then easily move those settings over to any additional SmarterMail servers by importing the antispam JSON. Email administrators can even work together to create and share their antispam JSON files, combining their experience and understanding to create the most reliable settings available.

It's important to note that the spamConfig.json file is not actually part of the SmarterMail system files -- it's generated during export by pulling individual spam settings from the Settings.json file. These settings are then merged with existing Settings.json files when the spamConfig.json file is imported. Therefore, spamConfig.json files can only be shared between servers running the same version of SmarterMail.

To import or export SmarterMail's spamConfig.json file, click on the Actions (⋮) button. Then click on Import Spam Settings or Export Spam Settings accordingly. When importing spam configurations, custom rules in the JSON will be merged with existing rules in SmarterMail; the imported JSON will not replace all existing rules. For example, if you import an JSON from another system, it will simply add any custom spam checks, RBLs and URIBLs that do not exist in SmarterMail. If you prefer that all existing rules are overwritten, you must delete those rules prior to importing.

Reset Antispam Settings

SmarterMail's antispam configuration can easily be reset to the default configuration by clicking on the Actions (⋮) button and selecting Reset Antispam Settings. Note that this reset will impact ALL sections of the Antispam area, with the exception of IP Bypasses. Resetting the antispam options will revert all settings on the Options tab, Spam Checks tab, RBLs tab, URIBLs tab, and Greylist Filters tab to their default configuration. This means all trusted senders and domains, SpamAssassin servers, custom spam checks/RBLs/URIBLs and greylist filters will be deleted. To confirm that you would like to erase all customized antispam options, click Reset on the confirmation modal.

Filtering

Emails are filtered into one of three categories based on their total weight: Low Probability of Being Spam, Medium Probability of Being Spam and High Probability of Being Spam. For example, if an email's spam weight is equal to or higher than a certain category, then it is assigned that probability of being spam. Use this section to define the weight thresholds and the default actions at each level.

Allow domains to override spam settings - Many domain administrators have their own preference of how potential spam email should be handled for their domain. Enable this to allow them to override the spam filtering actions, if they wish. NOTE: Enabling this will NOT allow domain administrators to manage the spam Weights -- they can only manage how they want messages flagged as spam, based on the weights set by the system administrator, to be handled.
Weight - The email is sorted into probability levels based on the weight threshold values. Adjust the weight threshold according to the probability status selected.
Action - The action to take when a message ends up with this level of spam probability: No Action, Delete Message, Move to Junk Email Folder or Add Text to Subject. Note: The Delete Message action will permanently delete messages that match the corresponding weight, preventing them from reaching the user's mailbox. Exercise caution when selecting this action, as messages deleted via spam filtering cannot be recovered.
Text to Add - If the Action is set to Add Text to Subject, enter the text that will be appended to the beginning of a subject when a message reaches a particular level of spam.

Trusted Senders

Use this section to globally exempt specific email addresses (such as jsmith@example.com) or domains (such as example.com) from SmarterMail's spam filtering. This lets the system know that these messages come from a trusted source and can prevent mail from friends, business associates and mailing lists from being blocked or sent to the Junk Email folder. By default, every contact in a user's Contacts list is considered a trusted sender and bypasses spam filtering.

If the system administrator has enabled SPF, DKIM, and/or DMARC, (all of which are strongly recommended), SmarterMail will run those checks on ALL emails, including those from trusted senders, whitelisted IP addresses, and IP bypasses. This "trust but verify" approach is important because anyone can write any return path that they want when sending a message. Therefore, this extra layer of protection helps prevent spammers from flooding users with hundreds of messages that aren't truly from a trusted sender. If an SPF, DKIM, or DMARC check fails on an incoming message, the "trusted sender" is no longer trusted by SmarterMail, and the weights of all enabled spam checks will be applied to that message.

DMARC, specifically, plays an integral part in determining "trusted" status. DMARC is the only check available that can confirm that the From address listed in the email is associated to the SPF record and return path. DMARC, therefore, ensures that the From address wasn't spoofed and the sender automatically trusted just because the From address is listed as a trusted sender. It is an extra step of security to ensure that senders are only 'whitelisted' if SmarterMail can verify the sender.

The specific spam check results that will bypass the trusted sender status are SPF_Fail, SPF_Softfail, SPF_PermError, or DKIM_Fail.

If the trusted sender status of an email was bypassed due to a failed SPF or DKIM check, the TotalSpamWeight line in the email header would appear in the following format:

X-SmarterMail-TotalSpamWeight: {Total Spam Weight} ({Where the trusted sender status originates}, {Reason the trusted sender status was bypassed})

For example:

X-SmarterMail-TotalSpamWeight: 9 (Trusted Sender - Domain, failed SPF)

This example indicates that the sender is in the domain-level Trusted Senders list, but the email received a total spam weight of 9 because the message failed the SPF check.

Regarding DMARC

We evaluate the DMARC results of an incoming email in order to determine whether the From Address or Return Path will be used for the Trusted Sender verification. If DMARC has a passing result, SmarterMail will use the From Address to determine if the email is in the Trusted Sender's list. In most cases, the Return Path and From Address of an email are the same, and users will likely have the sender's From Address in their Trusted Senders list. In these cases, as long as SPF and DKIM don't fail or error, the email should be delivered to the user's Inbox without a spam weight applied. If DMARC doesn't have a passing result, it will use the Return Path to determine if the email is from a Trusted Sender. If the Return Path address is in the Trusted Senders list as well, the email should be delivered to the user's Inbox without a spam weight applied. If the Return Path address isn't in the user's Trusted Sender's list, the full spam weight of the message will be applied, and the email will be filtered / moved according to the user's spam filtering settings. In these situations, the message will likely land in the Junk Email folder, and the X-SmarterMail-TotalSpamWeight header will show why the weight was applied, with something like this:

X-SmarterMail-TotalSpamWeight: 37 (Trusted Sender - User, DMARC: None)

    X-SmarterMail-TotalSpamWeight: 24 (Trusted Sender - User, DMARC: Skipped - DMARC Disabled)

These are the DMARC results that are considered "passing" and will allow the From Address to be considered in the Trusted Sender verification process:

DMARC: [passed]
DMARC: [skipped - Authenticated]
This will appear if the sender is an authenticated domain user or if the sender's IP address is in the whitelist with an SMTP Auth Bypass.
DMARC: [skipped - Bypassed]
This will appear if the sender's IP address is in the IP Bypass with Bypass Spam Checks enabled, and there is only 1 Received line in the email header/delivery.
DMARC: [skipped - Whitelisted]
This will appear if the sender's IP address is in the Whitelist with an SMTP Spam Bypass.

These are the DMARC results that are not considered "passing", and will disallow the From Address from being considered in the Trusted Sender verification process.

DMARC: [none]
DMARC: [failed]
DMARC: [skipped - DMARC Disabled]
DMARC: [skipped - No Return Path]

We also added this logic for adding or removing Trusted Senders from within the Email section:

If Return and From match, then we add/remove the From Address.
If Return and From differ, we look at the DMARC Results of that email.

If DMARC passed (or was skipped due to authentication, bypass or whitelist), we add/remove the From Address.
If DMARC didn't pass, we add/remove the From Address and the Return Path address. (This is done to help ensure that the sender will pass the DMARC Trusted Sender verification process on subsequent messages.)

SMTP Blocking

The idea behind SMTP blocking of inbound and outbound email is to filter out spam messages before they can be delivered. With SMTP Blocking enabled, messages that are rejected don't even hit the spool. That means that they can't be delivered, but it also means they bypass any other function, like content filtering and even message archiving. This is because messages rejected due to SMTP blocks simply don't exist to SmarterMail, so they aren't processed in any way by the server. Therefore, it's important to exercise caution when enabling SMTP Blocking as rejected messages can not be recovered.

Regarding the weight calculation, when setting up your Spam Checks, RBLs and URIBLs you have the ability to enable each of those for Inbound and/or Outbound SMTP. When enabled for either inbound or outbound, SmarterMail uses the weights associated with those various checks when determining whether a message should be blocked at the SMTP level or not.

For example, imagine you have four spam checks enabled for Inbound SMTP blocking and each of those spam checks have a weight of 10. If the Inbound Weight Threshold is set to 30, that means incoming messages will be rejected if they fail at least three of the four spam checks.

Inbound Weight Threshold - By enabling this field, an inbound email must have a total spam weight score of this value or higher in order to be blocked. The score is established by the settings on the Spam Checks, RBLs and URIBLs tabs. (By default, this threshold is set to 50 and is disabled.)
Greylist Weight Threshold - By enabling this field, an inbound email must have a total spam weight score of this value or higher in order to be greylisted. The score is established by the settings on the Spam Checks, RBLs and URIBLs tabs. (By default, this threshold is set to 30 and is disabled.)
Outbound Weight Threshold - By enabling this field, an outbound email must have a total spam weight score of this value or higher in order to be blocked. The score is established by the settings on the Spam Checks, RBLs and URIBLs tabs. (By default, this threshold is set to 30 and is disabled.)
Outbound Block Action - This setting is used in conjunction with the Outbound Weight Threshold and allows administrators to quarantine outgoing messages that have met the specified spam weight threshold or block them entirely. When Quarantine Message is selected, messages are quarantined for 30 days. (The quarantine period cannot be changed.) The quarantine can be found by clicking on the Manage icon, clicking on Spool in the navigation pane, then selecting the Spam Quarantine tab.
Bounce messages when blocked by Outbound SMTP Blocking - Enable this to send a user a bounce email notification when their outbound message has not been sent due to its spam probability.

Options

Autoresponders - This setting allows you to add restrictions to a user's ability to create or send autoresponders outside of the domain. (Autoresponders sent locally, to others on your domain, are not affected by these settings.) Certain antispam organizations will block servers that autorespond to spam traps. To reduce the possibility of this occurring, set the autoresponder option to be as restrictive as your clients will permit:
- Enabled - Users' autoresponder messages will be sent without any restrictions.
- Disabled - Users will not have the ability to configure an autoresponder.
- Require message pass SPF - A user's autoresponder will not be sent if the original sender's message failed the SPF spam check or if the sender's SPF record is not configured. Note that this setting won't impact the ability for an incoming message to be delivered to your users. It will only prevent the user's autoresponder from being sent if the original sender's SPF record is not configured or if the SPF check has failed. Note: The SPF spam check must be enabled for spool filtering in order for this setting to work as intended. If the SPF check is disabled, and this setting is enabled, autoresponder messages will not be sent. (By default, this option is selected.)
- Require message pass SPF if SPF record exists - A user's autoresponder will not be sent if the original sender's message failed the SPF spam check. Note that this setting won't impact the ability for an incoming message to be delivered to your users. It will only prevent the user's autoresponder from being sent if the original sender's SPF check fails. (This option is distinguishable from the option above as it will only impact messages where the SPF record IS configured and fails the check. If the original sender doesn't have SPF configured, the autoresponder message will be sent.) Note: The SPF spam check must be enabled for spool filtering in order for this setting to work as intended. If the SPF check is disabled, and this setting is enabled, autoresponder messages will not be sent.
Content Filter Bouncing - This setting allows you to add restrictions to the content filter action 'Bounce message'. Certain antispam organizations will block servers that send bounce messages back to spam traps. To reduce the possibility of this occurring, set the bounce option to be as restrictive as your clients will permit:
- Enabled - Content Filter bounces are enabled without any restrictions.
- Disabled -Content Filter bounces are disabled.
- Require message pass SPF - An incoming message that triggers the content filter will not have the bounce message sent if the original sender's message failed the SPF spam check or if the sender's SPF record is not configured. Note that this setting won't impact the ability for an incoming message to be delivered to your users. It will only prevent the bounce message from being sent if the original sender's SPF record is not configured or if the SPF check has failed. Note: The SPF spam check must be enabled for spool filtering in order for this setting to work as intended. If the SPF check is disabled, and this setting is enabled, bounce messages via content filtering will not be sent. (By default, this option is selected.)
- Require message pass SPF if SPF record exists - An incoming message that triggers the content filter will not have the bounce message sent if the original sender's message failed the SPF spam check. Note that this setting won't impact the ability for an incoming message to be delivered to your users. It will only prevent the bounce message from being sent if the original sender's SPF check fails. (This option is distinguishable from the option above as it will only impact messages where the SPF record IS configured and fails the check. If the original sender doesn't have SPF configured, the bounce message will be sent.) Note: The SPF spam check must be enabled for spool filtering in order for this setting to work as intended. If the SPF check is disabled, and this setting is enabled, bounce messages via content filtering will not be sent.
Max message size to content scan (KB) - The maximum message size for which content-based spam checks will run. Content-based spam checks include spamAssassin-based Pattern Matching, Remote SpamAssassin, and any custom rules. Note: Increasing this number will also increase the mail server's memory usage. (By default, this limit is set to 4096.)
Max Spam Check Threads - SmarterMail allows administrators to assign the number of threads used when processing spam checks. (Threads will, essentially, match the max number of messages that can be spam checked at one time.) The default is 30, and increasing that number can have an impact on the mail servers's performance.
Enable spool proc folder - Enable this to have SmarterMail place messages into a Spool\Proc folder to be analyzed in the background, usually by third-party products such as Declude or custom-built applications. (By default, the location of the Proc folder is C:\SmarterMail\Spool\Proc.) While the messages are in the Proc folder, .hdr can manipulate elements of the message, such as edit, write, and add headers. Once the scan has been completed, the third-party app is responsible for moving the message back into the spool to be handled by SmarterMail from that point on. This option is most often necessary when using the third-party program, Declude. However, this setting can be used to prevent the disruption of mail flow with any other third-party app that manipulates messages.
Enable catch-all accounts to send autoresponders and bounce messages - Enable this if you rely on autoresponders being sent when a message comes in through a catch-all. In general, this is a bad idea, so it should be left unchecked unless your situation specifically requires it.
Send user spam feedback to antispam providers - When enabled, every time a user marks a message as spam (or unmarks as spam), that information is sent to antispam providers. This type of user feedback helps improve the accuracy of these partnered providers. Reports are aggregated and send every five (5) minutes, so if a message is marked as spam, then unmarked as spam, within that timeframe, no message is sent.
Send user spam feedback to training folder - When enabled, this will temporarily copy .EML files to a separate folder on disk. This allows any third-party products that allow for "training" of their systems to review messages that have been marked as spam. .EML files are stored for approximately one (1) hour before they are deleted.

DMARC

What is DMARC?

Domain-based Message Authentication, Reporting & Conformance (DMARC) is a newer form of email authentication. It makes sure that legitimate email authenticates against 2 DNS record types: DKIM and SPF. Also, it ensures that fraudulent email that tries to look legitimate gets blocked. It's worth noting that, when enabled, all messages will be checked against DMARC (along with SPF and DKIM), including those from Trusted Senders, IP bypasses, and whitelists.

The alignment of these DNS entries, which is the heart of DMARC, prevents spoofing of the return path's "from" address. It matches the return path domain name with the visible From address domain name from the SPF check. Then, it matches the return path domain name with the domain name in the DKIM signature. In order to pass DMARC, an email must pass ONE OR BOTH of the following:

It must pass SFP authentication and SPF alignment.
It must pass DKIM authentication and DKIM alignment.

If one of the above is met, the message will pass the DMARC check.

Why use DMARC?

More and more email providers are using DMARC as a way to authenticate email. Companies like Microsoft (Microsoft 365 (Office)), Google (Google Workspace), and Yahoo! all use DMARC and its associated DNS entries when checking messages. As a result, have valid DKIM and SPF records, and enabling DMARC, can help ensure your emails are accepted with larger email providers. In addition, it helps keep your users from seeing legitimate-looking email.

Disadvantages of Using DMARC

The primary disadvantage is that not all email providers, and not all businesses, know about DMARC, SPF and DKIM. As a result, it's possible it's being implemented improperly, if at all. As a result, legitimate email may be flagged as suspicious, even if it's not.

DMARC Quarantine/Suspicious Weight

This is similar to a spam weight: it's the weight assigned to a message if it "fails" the DMARC check. When enabled, the weight is 10 by default.

Understanding DMARC Header Entries

When viewing an email header, it's possible to see the various scores given to the spam checks that are enabled. However, some scores depend upon how certain checks are interpreted by SmarterMail. DMARC is one of those checks. Therefore, here's a breakdown of what DMARC header entries can show and what they may mean, specifically when you see DMARC [Failed] in the header.

Typically, DMARC [failed]: will indicate that the DMARC check failed, and the score applied is based on your policy. For exampe, when the domain's DMARC policy is set to None, the score will be 0.
DMARC [failed]: "Any Other Number" indicates that the DMARC check failed, and the domain's DMARC policy is set to Quarantine/Suspicious. When this is how DMARC is configured, the weight associated with the DMARC Quarantine / Suspicious Weight is applied. (Which defaults to 10, but can be changed as needed.)
If DMARC fails and the sender's policy is set to Reject, the email will be rejected in SMTP session, before it's even created as an email. Therefore, no score is assigned.

See Trusted Senders for more information on DMARC responses and what they mean.

Enable DMARC - Toggle this to use DMARC as an antispam option.
Quarantine/Suspicious Weight - The weight to use if a DMARC policy uses the "quarantine" option. This weight is then added to the overall spam score. By default, this is set to 10.
Custom Domain Suffixes - SmarterMail, and most mail servers that support DMARC (which is just about all of them), use the Public Suffix List (PSL) to determine "same organization" for DMARC purposes. Previously, if an administrator needed to add a domain to the PSL, they needed to contact the PSL administrators so that SmarterMail, and other mail servers, could identify the new domain as an organization. However, now system administrators can add a domain to this area and it's added to the parsed PSL that SmarterMail uses. This DOES NOT add domains to the PSL directly. Instead, it inserts these domains into the list SmarterMail retrieves from the PSL.

Custom Domain Suffixes

By default, SmarterMail will pull data for standard Top Level Domain extensions from the Public Suffix List, a community managed list of suffixes that can be registered at various domain registrars. Common suffixes include .com, .com.uk, or even pvt.k12.ma.us. While this list is updated automatically within SmarterMail, there may come a time when a system administrator needs to add a suffix before the public list can be updated, and before SmarterMail can update its internal list. This is where these "custom domain suffixes" can be added.

A common need for adding a Custom Domain Suffix is for DMARC policy for domains that are independent organizations from a larger domain. For example, (and solely as an example as this may or may not be true) if Yahoo! had independent domains for geographic locations such as akyahooemail.com for Alaskan Yahoo! email users. In this case, akyahooemail.com may not necessarily pass DMARC policy checks for regional third level additions to the main domain. Therefore, a system administrator would add akyahooemail.com as a Custom Domain Suffix so that DMARC checks would treat regional Alaskan domains (e.g., juneau.akyahooemail.com) as an organizational domain.

Greylisting Options

What is greylisting and how does it work?

Greylisting has proven itself to be an effective method of spam prevention. When enabled, the system will keep track of the sending IP address, sending email address and recipient's email address for every message received. If an incoming message has a combination of a sending IP, sending address and recipient address that has not previously been seen, it will return a temporary failure to the sending server, effectively saying, “Try again later.” Valid servers will retry the email a short time later, which would be permitted. Spammers, on the other hand, typically create scripts that bombard your server with emails, and they rarely retry on temporary failures. When these messages are bounced back because of greylisting, they are typically not retried, therefore reducing the amount of spam that your customers receive. (Emails sent from whitelisted and authenticated senders will automatically bypass greylisting and are delivered directly to the spool.)

For those messages that are sent from valid email servers, the sending server should retry at least four times. If the first retry is beyond the block period (default 15 minutes) and within the pass period (default 6 hours), the message is passed to the spool and it goes through its normal processing without a delay. A record is also created that says this is a valid email address from that server to the given recipient and keeps it for 36 days (default). If another email from the same email address is received from the same server to the same recipient within the 36 days, the clock is reset for an additional 36 days and delivered directly to the spool.

Why use greylisting?

Greylisting is a very effective method of spam blocking that comes at a minimal price in terms of performance. Most of the actual processing that needs to be done for greylisting takes place on the sender's server. It has been shown to block upwards of 95% of incoming spam simply because so many spammers don't use a standard mail server. As such, spam servers generally only attempt a single delivery of a spam message and don't reply to the "try again later" request.

Disadvantages of greylisting

The biggest disadvantage of greylisting is the delay of legitimate email from servers not yet verified. This is especially apparent when a server attempts to verify a new user's identity by sending them a confirmation email. Some email servers will not attempt to re-deliver email or the re-delivery window is too short. Whitelisting can help resolve this.

Greylisting configuration options

Block Period (Minutes) - The period of time that mail will not be accepted. The default 15 minutes.
Pass Period (Minutes) - The period of time in which the sender's mail server has to retry sending the message. The default 360 minutes.
Record Expiration (Days) - The period of time that the sender will remain immune from greylisting once it has passed. The default 36 days.
Enable Greylisting - Select this option to enable greylisting.
Allow users to override greylisting - Select this option to allow users to selectively turn off greylisting. This is useful if you have a user who receives time sensitive mail.

Note: The following cases are exempt from greylisting: SMTP Whitelisted IPs, IP Bypasses that are specified to skip greylisting, anyone who authenticates (includes SMTP Auth Bypass list), trusted senders (includes users' contacts), anyone who has already sent you an email (this list generates only after greylisting has been enabled), any IP address or country code specified as being exempt in the Greylist Filters tab.

Remote SpamAssassin Servers

SpamAssassin is a powerful, free mail filter used to identify spam. It utilizes a wide array of tools to identify and report spam, including header and text analysis, Bayesian filtering, DNS blocklists and collaborative filtering databases. While SmarterMail includes SpamAssassin by default, it's also possible for system administrators to set up an external SpamAssassin server. To set up an external server, simply click New Server. The following options will be available:

Name - The name of the SpamAssassin server.
IP Address - The IP address of the server running SpamAssassin.
Port - The port on which the SpamAssassin server should listen. By default, the port is 783.

Remote Rspamd Servers

Rspamd is a very popular and advanced spam filtering system that uses various methods, such as regular expressions, statistical analysis, and custom services like URL blacklists, to evaluate email messages. It assigns each message a spam score that can be used by system administrators as another way to mark potential spam and then handle it appropriately before it reaches end users. More information can be found at https://rspamd.com/doc/index.html

NOTE: When using a Remote Rspamd server, it's best to disable SpamAssassin-Based Pattern Matching and/or Remote SpamAssassin. This is because both use the same engine, so you run the risk of double scoring messages, and could, therefore, falsely increase the spam score of messages.

For information on setting up a remote Rspamd server, see this knowledgebase article: Deploying Rspamd For Use With SmarterMail.

Name - The name given to the Rspamd server.
Rspamd Server Address - The complete URL for the remote server. This can be a FQDN (e.g., rspamd01.mail-domain.com), but generally will be an IP address and port. E.g., https://127.0.0.1:11335
Checkv2 Endpoint - This is the endpoint used for checking messages and returning an action. By default, it's /checkv2
Learnspam Endpoint - This is the endpoint for messages "marked as junk" by users, or messages moved by the user into the Junk Email folder. By default, it's /learnspam.
Learnham Endpoint - This is the endpoint for messages moved out of the Junk Email folder and into another folder. By default, it's /learnham.