Anstelle eines zweistufigen Inbound-Filters, ist Gate-Suite mit einem vierstufigen Filter ausgerüstet. Inbound und Outbound werden zusätzlich getrennt implementiert, da Inbound DDoS-Attacken auf den Outbound-Verkehr keine Auswirkungen haben dürfen.

Der Filterung ist wie folgt aufgebaut:

Stufe 1: Kernel Firewall

Eine Firewall hat generell den Zweck Verbindungen zuzulassen oder zu sperren. Die hier eingesetzte Firewall kann zusätzlich mittels passivem OS-Fingerprinting  und anhand des Verbindungsverhaltens die Verbindungen an verschiedene Sendmail-Instanzen mit jeweils anderen QoS und Timeing-Parametern zuweisen. Damit wird schon auf Kernel Ebene versucht, die guten Verbindungen von den schlechten Verbindungen zu trennen.
Kommerzielle Schutz-Software in diesem Bereich gibt es ausserhalb von Komplett-Systemen / Antispam-Appliances praktisch keine. Eine Ausnahme ist hier Traffic Control , dessen Hauptmerkmal ein Multiplexed-Proxy-Server für SMTP-Verbindungen ist. Das Proxy-Programm nimmt dabei die Verbindungen entgegen  und   leitet diese erst nach dem SMTP-Protokoll-Handshake an den MTA weiter. Die im Proxy getroffenen Massnahmen sind fast identisch mit den hier vorgestellten Massnahmen, allerdings gibt es einen grossen Unterschied: Traffic Control arbeitet bereits auf Betriebssystem-Ebene, das hier vorgestellte QoS-System findet 100% im Kernel statt und spart gerade bei vielen gleichzeitigen Verbindungen massiv an Ressourcen.
Bei Traffic Control werden alle verdächtigen E-Mails getrennt von den unverdächtigen E-Mails behandelt, zwei eingehende E-Mail-Queues trennen dabei die zwei Datenströme. Während die unverdächtigen E-Mails sofort bearbeitet werden, werden die verdächtigen E-Mails sequentiell nach und nach an den MTA weitergegeben. Der Vorteil dieses Systems ist der geringe Ressourcen-Verbrauch, da das Proxy-Programm von Traffic Control
gegenüber Sendmail Multithreaded ist, und daher mehrere 1000 Verbindungen gleichzeitig handhaben kann und diese nebeneinander bedient. Bewusst wird hier nicht Greylisting eingesetzt, sondern alle verdächtigen Verbindungen verzögert.

Stufe 2: Kernel Accept Filter

Genau so wichtig wie der Einsatz einer Firewall ist der im Kernel implementierte Accept-Filter. Dessen Aufgabe besteht darin, nur komplette, korrekte SMTP-Verbindungen an die Applikations-Software weiterzugeben und bei einem DDoS-Angriff die Kontinuität der E-Mail Zustellung weiter gewährleisten zu können. Ebenfalls implementiert ist im Kernel Accept-Filter eine Greet-Pause Funktionalität, die
sehr effektiv ist. Denn Spammer stehen unter Zeitdruck. Es ist ihre Aufgabe möglichst viele E-Mails innerhalb kurzer Zeit loszuwerden. Dabei können Sie oft nicht auf SMTP-Protokoll spezifische Eigenheiten achten, was Ihnen mit der Greet-Pause zum Verhängnis wird. Denn bevor der SMTP-Client, resp. die SMTP-Gegenseite Daten senden darf, schickt der Server diesem ein Begrüssungs-Banner, das meist einen Versions-String und manchmal auch eine Datumsangabe enthält. Nach RFC-2821 darf der SMTP-Client erst jetzt seine Daten senden. Erhält der Server aber schon vorher Daten von der Client-Seite, so handelt es sich mit Sicherheit nicht um eine konforme, normale SMTP-Verbindung und sie kann – ohne dass die Server-Applikations-Software etwas davon mitbekommt – beendet werden.

Stufe 3: Vorfilter Inbound

Neben der SMTP-Firewall ist auch diese Filterstufe entscheidend für die Stabilität des
Systems. Die Vorfilterung umfasst alle SMTP-Befehle vom eigentlichen Verbindungsaufbau her bis zu der Empfängerangabe und hat die schwierige Aufgabe die Spreu vom Weizen zu trennen, das heisst anhand von bestimmten Merkmalen zu erkennen, ob es sich um Spam oder normale E-Mails handelt, die dann von der Ressourcen-Intensiven normalen Inhalts-Filterung bearbeitet werden können. Dabei ist es wichtig die Filter-Instanzen von unnötigem Balast zu befreien. SpamAssassin fehlt daher in dieser Konfiguration. Zudem kann der Vorfilter bei entsprechender Last auf dem MX-Server oder auf dem Filter-System selbst die zu anwendenden Regeln und ihre zugehörigen Massnahmen verstärken.

Stufe 4: Inhaltsfilter Inbound

Die Inhaltsfilterung ist wie schon erwähnt sehr Ressourcen intensiv. Im Gegensatz zur Vorfilterung ist diese Instanz auch mehrere Sekunden mit der Analyse eines einzelnen E-Mails beschäftigt. Je nach Grösse der E-Mail und der Anhänge und ihrer Inhalte kann die Filterung bis zu 30 Sekunden oder mehr andauern. Daher ist es wichtig dass die Kernel-Firewall und die Vorfilterung einen Grossteil der Junk-Emails schon herausgefiltert haben, bevor die Vorfilterung greift. Um die Inhaltsfilterung zu entlasten, ist es notwendig die
Shortcircuit-Plugin-Funktionalität auszunutzen um möglichst viele gute E-Mails von der Filterung auszunehmen und schneller zuzustellen können.

Filterung Outbound

Werden alle Kunden-E-Mails via Smarthost auch über den Outbound-Server der Shared-Umgebung versendet, so kann pro Kunde eine Sendmail-Instanz mit zugehöriger separierter Queue verwendet werden. Pro Kunde ist daher eine IP-Adresse notwendig, da die entsprechenden Dienste an diese IP-Adresse gebunden werden müssen. Durch diese strikte Trennung ist ein beeinflussen der Kunden gegenseitig ausgeschlossen. Ein Blacklisting eines Kunden führt zu keinerlei Beeinträchtigung anderer Kunden.   Allerdings sollten Hochrisiko-Kunden in einem anderen Netz-Bereich (nicht das gleiche C-Netz) aufgeschalten werden.
Diverse Relay-Kontrollen gewährleisten, dass der Outbound-Server nicht zum spammen missbraucht werden kann.  Falls gewünscht wird bei auffälligem Mailaufkommen eine Stichprobe gemacht. Ist diese Stichprobe auffällig, so wird die sendende IP geblockt.