Why is the X-Junkmail header removed when any content filter is configured?

Issue

Why is the X-Junkmail header removed when any content filter is configured?

Solution

This is by design. The specification was changed in MOS 4.1.9 or higher. The X-Junkmail header is removed to avoid spoofing. To avoid deleting the X-Junkmail header, remove all content filters. Or establish a relationship with the other Mirapoint system by using the trustedhost command.

Removing the content filters

To remove the content filter, please perform as follows:

1. Log on to GUI as administrator

2. Click "Content Filtering" link, then "Advanced"

3. If the "Advanced Content Filters" has any filter, delete the filters.  NB: you will need to check all Destination Domains, Primary, Any, Local and Non-local.

The impact of removing any Content filters must be clearly understood prior to performing this step as this may impact other components of the mail system.

Establishing a Trust Relationship

When messages pass through multiple tiers of Mirapoint appliances, there is rarely any benefit to recalculating message spam scores at each hop, and many reasons to avoid this duplicated effort. However, the mere presence of spam-scoring headers is not sufficient reason to skip the scoring process, since the headers might have been forged, might have come from a different Mirapoint customer, etc. The solution is to set up explicit trust relationships among hosts, so that the recipient accepts the sending host's reporting of the message processing state. The trust relationships described here only affect whether a spam score generated on one system is accepted by another. For other forms of trust, please refer to the documentation of the Relay Add command.

Create Keys on Scoring Systems

Think about all of the places in your installation where messages are spam-scored. This is not just the incoming mail routers, but also potentially mailstores (where messages originate), outgoing routers, JMM hosts, etc, depending on how your systems are configured and how your users' mail clients submit messages. In most cases, every system should accept spam-scoring done by any of the other systems; the examples below assume that to be the case.

To establish a trust relationship with another MOS system, use the trustedhost command..

1.On every system that scores messages, create a public key pair for encryption/verification of message statuses with the following command:

CLI>key new MTA "" "" ""

[Note] SMTP service restart during generating the key.

2. Verify the generated key

CLI> key get MTA ""

3. Generate the public key for use on the Mailhost.

CLI> key getpublic MTA ""

MTA public "rg.xxx.com" "" "" {1028}

#@Mirapoint-Key-1.0

VHlwZT1NVEENCkhvc3RuYW1lPXJnMTAwYi00LnN2Zy5uaXNzaG8t

ZWxlLmNvLmpwDQpQRU06DQotLS0tLUJFR0lOIFBVQkxJQyBLRVkt

-------------------

RVktLS0tLQo=

#@Mirapoint-Key-End 

OK Completed

4. Install Trust keys on Receiving Systems.

In the most common case, you want each of your Mirapoint appliances to accept scores calculated by any of the others. For each host, install the public half of the key for each other host:

CLI> trustedhost add mtagroup <IP address or FQDN>

After entering above command, the key is required.

Example

CLI> trustedhost add mtagroup 192.168.0.1

Enter trustedhost data, finish with a '.' on a line by itself:

#@Mirapoint-Key-1.0

VHlwZT1NVEENCkhvc3RuYW1lPXJnMTAwYi00LnN2Zy5uaXNzaG8t

ZWxlLmNvLmpwDQpQRU06DQotLS0tLUJFR0lOIFBVQkxJQyBLRVkt

-----------------

RVktLS0tLQo=

#@Mirapoint-Key-End

.

OK Completed

(If your firewall blocks http between these systems you can use the key getpublic command to export the public half of each key to import onto the other systems, but generally the HTTP method is easier.)

If you have five systems, you will be issuing the trustedhost add mtagroup command twenty times, to add four trusted peers to each of the five systems.

5. Verify the registered key

CLI> trustedhost list mtagroup

Note:

If mail travels between two Mirapoint appliances by way of a non-Mirapoint host, or if a user forwards their mail offsite, the trust chain will be broken.

IMPORTANT: In MOS versions prior to 4.1.6 or 3.10.6, trust relationships affected other phases of message processing, including domain filters, domain whitelists, etc. If you are using an older MOS version, make sure that you understand the full implications of a trust relationship before implementing it.

IMPORTANT: The keys created with Key Add apply to all of the system's current network interfaces, but will not be accepted if the mail arrives with a different apparent IP address, as may happen in some complex network configurations, or if the system's IP address changes.

Administrators can remove any configuration, so please be aware that the changing configuration will impact the entire system.