How can I prevent unneccessary duplication of the spam-scoring process in a multi-tier environment?

Issue

How can I prevent unnecessary duplication of the spam-scoring process in a multi-tier environment?

Solution

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.

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 "" "" ""

You can verify the key, and the parameters associated with it, with the command

CLI>key getpublic mta ""

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 anotherhost.example.com http:

(If your firewall blocks HTTP connetions 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.

Notes

• 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.