DE19741238A1 - System und Verfahren zur Filterung elektronischer Post - Google Patents

Description

Ein Abschnitt der Offenbarung dieses Patentdokuments beinhaltet Material, welches urheberrechtlichem Schutz unterliegt. Der Urheber hat keine Einwände gegen eine Reproduktion durch eine beliebige Person per Kopie der Patentoffenbarung, wenn sie in den Patent- und Markenamts-Patent-Akten oder -Listen erscheint, behält sich jedoch alle Urheberrechte vor.

Hintergrund der Erfindung Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich auf die Computersicherheit und insbesondere auf eine Vorrichtung und ein Verfahren zur Steuerung der Verarbeitung von Nachrichten der elektronischen Post.

Hintergrund der Erfindung

Elektronische Post wird ein zunehmend integrales Mittel der Kommunikation für beliebige Dinge, angefangen von Studenten, die miteinander und mit ihren Lehrern Nachrichten austauschen, bis zu hochsensiblen Geschäfts- und Re­ gierungs-Kommunikationswegen. Die Kommunikationstechnologie hat sich bis dorthin ausgedehnt, wo jedermann mit einem Personalcomputer, minimaler Software und einem Modem sich an das Internet anschließen kann und Post zu jedem beliebigen anderen Computer senden kann, ob er nun auf der gegenüberliegenden Straßenseite oder irgendwo in der Welt sich befindet. Da jedermann Post zu jedem beliebigen anderen senden kann, haben viele Standorte begonnen, Sicherheitsverfahren zu etablieren, die spezifizieren, wie Post, welche an externe Orte gesandt oder von diesen empfangen wird, behandelt werden soll. Diese Standorte verwenden Postnachrichtensysteme, um ankommende und ausgehende Nachrichten zu analysieren und zu bestimmen, ob Information, die die Nachricht betrifft, aufgezeichnet oder überprüft werden soll, oder ob es der Nachricht erlaubt werden soll, an alle verteilt zu werden.

Jeder Nutzer hat unterschiedliche Bedürfnisse. Kommerzielle Sicherheitsverfahren sind unterschiedlich bei verschiedenen Geschäftszweigen und Installationen und sind verschieden bei Bedürfnissen der Regierung oder schulischer Einrichtungen. Bis heute haben jedoch herkömmliche Systeme implizite Voraussetzungen bezüglich der Sicherheit, die notwendigerweise miteingebaut ist, basierend auf den Regeln des notwendigen Sicherheitsverfahrens. Daher muß, wenn ein Standort groß genug ist, um Abteilungen mit verschiedenen Wünschen aufzuweisen, oder, wenn ein Filter für eine Anzahl von Anschlüssen entwickelt wird, entweder ein separates System entwickelt und für jeden Standort bzw. jede Abteilung installiert werden oder es muß das System so geschrieben werden, daß der kleinste gemeinsame Nenner von Regeln, die durch jeden Standort bzw. jede Abteilung spezifiziert werden, in Kraft gesetzt wird.

Zusätzlich benötigen die bis zum heutigen Tage konstruierten Systeme oftmals ein unabhängiges Computersystem, welches derart lokalisiert ist, daß die gesamte Post, die zwischen externen und internen Standorten wechselt, durch das Filtersystem hindurchtreten muß. Derartige Systeme sind typischerweise darauf beschränkt, auf einen bestimmten Satz von Schlüsselwörtern zu achten und abhängig von der Regel Verarbeitungsentscheidungen zu treffen, die darauf basieren, ob das Schlüsselwort vorhanden ist oder fehlt.

Schließlich sind die bis zum heutigen Tage zur Verfügung gestellten, herkömmlichen Systeme nur in der Lage, eine Ja/Nein-Entscheidung zu fällen, wobei sie nur eine Option an jedem Entscheidungspunkt zur Verfügung stellen. Die Nachricht (oder die Antwort auf die Nachricht) muß nur einen Weg hinunterlaufen - in Richtung des Zielortes, zurück zu der Quelle oder umgeleitet zu einem anderen Bestimmungsort. Benötigt wird eine Ausrüstung, die verschiedene Adressen für eine einzige Nachricht unterstützt. Es ist daher schwierig, ein Verfahren zu implementieren, welches beispielsweise verdächtige Nachrichten an ihren Ursprungsort befördert aber auch eine Kopie an ein internes Beobachtungs- oder Aufzeichnungssystem weiterleitet. Herkömmliche Systeme können diese Anforderung nicht unterstützen.

Was benötigt wird, ist ein Weg der Strukturierung eines Nachrichtensystems für elektronische Post, der flexibel genug ist, eine Vielzahl von Sicherheitsverfahren zu implementieren, welcher aber ebenfalls für einen Netzwerkadministrator einfach zu konfigurieren ist. Ein solches System würde bevorzugterweise eine Vielzahl von Weiterleitungswegen von jedem Entscheidungspunkt aus zur Verfügung stellen.

Zusammenfassung der Erfindung

Die vorliegende Erfindung ist ein System und ein Verfahren zur Filterung von Nachrichten der elektronischen Post. Eine Nachricht wird empfangen und durch einen oder mehrere Filterabläufe verarbeitet. Jeder Filterablauf schließt einen oder mehrere autonome Knoten ein, welche in der Reihenfolge kombiniert werden können, welche benötigt wird, um ein vorgegebenes Sicherheitsverfahren in Kraft zu setzen. Die Unabhängigkeit der Knoten liefert eine verfahrensneutrale Umgebung für den Aufbau von Filterabläufen. Ein Filterablauf kann einfach darin bestehen, daß die Post dem gewünschten Empfänger überbracht wird, oder kann ein oder mehrere Prüfungen ausführen, in welchen er entscheidet, ob er die Nachricht weiterleitet, ablehnt oder zurückleitet (oder eine Kombination dieser Möglichkeiten). Bestimmte Knotentypen sind ebenfalls in der Lage, an eine Postnachricht Information anzuhängen, während andere in der Lage sind, bestimmte Teile einer Postnachricht zu modifizieren. Bestimmte Knotentypen sind in der Lage, Prüf- oder Protokoll­ nachrichten zusammen mit einer Postnachricht zu verarbeiten.

Das Ergebnis ist ein generalisiertes, modulares System zum Aufbau von Postfilter­ abläufen. Das Filtersystem der vorliegenden Erfindung ist verfahrensneutral - es wird jeder beliebige Ablauf wenn nötig aufgebaut, welcher ein bestimmtes Sicherheitsverfahren in Kraft setzt. Die gleichen Komponenten können neu angeordnet werden, um ein anderes Verfahren in Kraft zu setzen, ohne daß auch nur eines der individuellen Module neu programmiert werden muß.

Gemäß einem Aspekt der vorliegenden Erfindung werden Nachrichten der elektronischen Post gefiltert, indem eine Nachricht empfangen wird, analysiert wird, ob sie die Filterkriterien erfüllt und die Nachricht an den Filter weitergeleitet wird, wenn sie die Kriterien des Filters erfüllt. Die Nachricht wird zugestellt, wenn sie die Kriterien nicht erfüllt.

Gemäß einem weiteren Aspekt der vorliegenden Erfindung analysiert der Filter die Nachricht der elektronischen Post und stellt die Nachricht zu oder lehnt die Nachricht ab, basierend auf ihren Eigenschaften. Zusätzlich kann der Filter eine Prüfnachricht in Verbindung mit den Ergebnissen der Analyse erzeugen.

Gemäß einem weiteren Aspekt der vorliegenden Erfindung schließt ein Filter für elektronische Post ein Analysemodul zur Analyse der Postnachricht ein, unter Verwendung eines oder mehrerer individueller Filterknoten, und ein Ausgangsmodul zum Erzeugen einer Vielzahl von Ausgangsnachrichten, basierend auf der Analyse des Analysemoduls. Die verfügbaren Filterknoten schließen einen Filter, ein Modifikationsmittel oder ein Endglied ein. Der Postfilter kann auch eine graphische Benutzerschnittstelle zum Erzeugen und Erhalten des Filters für elektronische Post einschließen.

Kurze Beschreibung der Zeichnungen

Fig. 1 zeigt ein Beispiel einer Ablaufkonfiguration,

Fig. 2 ist ein Blockdiagramm, welches eine Ausführungsform eines Postfilters zeigt, welcher in einem Post-Framework enthalten ist,

Fig. 3 zeigt die Hauptkomponenten eines Postfilterknotens gemäß einer Aus­ führungsform der vorliegenden Erfindung,

Fig. 4 ist eine graphische Darstellung eines erweiterbaren Datenobjektbaums,

Fig. 5 zeigt ein einfaches Beispiel eines Endausgangsmoduls,

Fig. 6 zeigt ein Beispiel eines Filtermoduls,

Fig. 7 zeigt ein Beispiel, wie Komponenten miteinander verbunden werden können, um einen Filterablauf in dem Post-Framework der vorliegenden Erfindung zu kreieren,

Fig. 8A ist eine Darstellung des Verwaltungsfensters für die Postfilterkarte, welches von der Benutzerschnittstelle dargestellt wird,

Fig. 8B ist eine Darstellung von Optionsfenstern, welche durch die Benutzer­ schnittstelle dargestellt werden,

Fig. 9 zeigt ein Beispiel der Spezifikation eines Filterablaufs, welcher die Ablauf­ sprache verwendet,

Fig. 10 ist eine graphische Darstellung von musterhaften Ablaufregeln,

Fig. 11 stellt eine Filterkarte dar, in der eine separate Prüfstelle für jeden Filter vorhanden ist,

Fig. 12 illustriert eine Filterkarte, in welcher zwei verschiedene Filter die gleiche Prüfstelle verwenden,

Fig. 13 zeigt eine Ausgangsform, in welcher Zurückweisungen von verschiedenen Filtern über einen einzigen Anschluß an die gleiche Prüfstelle gesandt werden,

Fig. 14 zeigt eine Instanz, in welcher Zurückweisungen weitergereicht werden und Prüfvorgänge an eine gemeinsame Prüfstelle gehen,

Fig. 15 zeigt eine Ausführungsform eines Filterablaufs, in welcher getrennte Prüfstellen verwendet werden und Zurückweisungen weitergereicht werden,

Fig. 16 stellt ein Kartenbeispiel dar, welches die gleiche Prüfstelle verwendet und Zurückweisungen weiterleitet,

Fig. 17 zeigt eine Filterkarte, welche die in den Fig. 11-16 dargestellten Ideen kombiniert,

Fig. 18 zeigt ein Beispiel eines herkömmlichen Verfahrens des Hinzufügens eines Zurückweisungsgrundes an Nachrichten,

Fig. 19 zeigt ein Beispiel eines erweiterten Verfahrens des Hinzufügens eines Zurückweisungsgrundes an Nachrichten gemäß einer Ausführungsform der vorliegenden Erfindung.

Detaillierte Beschreibung der bevorzugten Ausführungsformen

In der folgenden detaillierten Beschreibung der bevorzugten Ausführungsformen wird Bezug genommen auf die begleitenden Zeichnungen, welche einen Teil hiervon bilden und in welchen durch Illustration bestimmte Ausführungsformen, in denen die Erfindung verwirklicht werden kann, gezeigt sind. Es ist klar, daß andere Ausführungsformen verwendet werden können und strukturelle Veränderungen gemacht werden können, ohne den Bereich der vorliegenden Erfindung zu verlassen.

Es gibt zwei Aspekte des Filterns von Post. Der erste ist, was zu Filtern ist, der zweite ist, wie es zu Filtern ist. Die erste Frage wird beantwortet durch eine Ausführungsform der vorliegenden Erfindung in der "Postfilterverfahren"-Datei. Diese listet einfach "Burb"-Paare ("Burb" englisch für "Region", "Bereich", "Sektion") auf, welche gefiltert werden sollen. Ein Burb bezieht sich auf einen Protokollstapel in einer Umgebung, die eine Netzwerktrennung zur Verfügung stellt, indem sie getrennte Protokollstapel oder Regionen für jede Seite des Systems aufrechterhält. Eine detailliertere Beschreibung der Burbs wird in dem Aufsatz "System and Method for Achieving Network Separation" von Gooderum et al. (PCT, veröffentlichte Anmeldung Nr. WO 97/29413, veröffentlicht am 14. August 1997) gegeben, dessen Beschreibung hiermit durch Bezugnahme mit einbezogen wird. Unter der Netzwerktrennung wird eine Vielzahl von Burbs oder Regionen definiert. Jedes Burb schließt einen Protokollstapel ein. Jede der Vielzahl von Netzwerk­ schnittstellen ist einer der Vielzahl der Burbs zugeordnet und mehr als eine Netzwerkschnittstelle kann einem bestimmten Burb zugeordnet sein. Prozesse sind an bestimmte Burbs gebunden, wenn sie versuchen, zu dem Protokollstapel dieses Burbs Zutritt zu erlangen, und die Kommunikation zwischen den Prozessen, die verschiedenen Burbs zugeordnet sind, ist unterbunden. Die Weiterleitung zu einem gegebenen Stapel kann darauf begrenzt sein, am Anfang oder am Schluß des Datenflusses ausgeführt zu werden, so daß ein gegebenes Paket, ein gegebenes Datenstück, eine gegebene Steuernachricht usw. an einen bestimmten, sich im Aufbau befindenden Stapel gebunden ist.

Die Postfilterverfahren-Datei wird von einem Postverteilungsagenten dazu verwendet zu bestimmen, ob Post in den nächsten Burb übergeben wird oder in eine Warteschleife gesetzt wird. Aufgelistete Burb-Paare werden gefiltert und nicht aufgelistete Paare werden dem Ziel-Burb übergeben. Diese Datei wird durch ein Post-Warteschlangenprogramm bei jedem Verteilschritt gelesen, so daß sie bewußt kleingehalten wird, um möglichen Überschuß zu reduzieren. Das Filterverfahren wird im folgenden genauer beschrieben.

Die zweite Frage, wie Postnachrichten gefiltert werden, ist für die Programme, welche die Post-Warteschlangen bearbeiten, relevant. Diese sind lang laufende Dämonen, so daß es kein Problem ist, wenn sie am Anfang einigen zusätzlichen Überschuß aufweisen. Im folgenden wird auch die Filterkonfiguration genauer diskutiert.

Die Ablaufkonfiguration befindet sich in einer Datei und enthält eine einfache Listung von Burb-Paaren und einen Kartennamen. Dies ist durch den Postadmini­ strator und den Systemadministrator unter dem operationellen Systemkern kon­ figurierbar. Diese Datei muß zum Zeitpunkt der Installation vorhanden sein und muß hinzugefügt werden, wenn ein System einen Upgrade erfährt. Am Anfang werden keine Abläufe gelistet, sie können jedoch zu jedem Zeitpunkt durch den Administra­ tor hinzugefügt werden. Wenn die Datei fehlt, wird das Postwarteschlangenpro­ gramm keine Post ausliefern und wird einen Fehler an die Postsendeapplikation zurückmelden, die ihn verursacht hat. Die Konvention, das Read-Only-Skelettdateien (engl.: "read-only skeleton files") in der Umgebung gehalten werden, sollte auch für diese Datei angewendet werden. Ein Beispiel einer Ablaufkonfiguration ist in der Fig. 1 gezeigt, in der jede Filterablaufzeile 10 ein Burb-Paar einem Karten-Namen (engl.: "map name") 12 zuordnet (mapped).

In einer Ausführungsform ist der Filter-Elterndämon ein kleines Programm, welches eine Pid-Lock-Datei kreiert und dann Filterwarteschlangenlaufprogramme ausführt und immer wenn eines der Konfigurationsdateien in der höchsten Stufe verändert wird, sollte dieser Prozeß signalisiert werden. Er wird dann seinen Kindern ent­ sprechende Signale zukommen lassen oder diese neu starten.

Ein Programm, welches für das Verbringen der Post in die Warteschlange ver­ antwortlich ist, wird durch das Sendeprogramm für die Post mit Quellen- und Bestimmungsort-Burbparametern in der Befehlszeile laufen gelassen. Der War­ teschlangenagent ist ein ausführbares Gate. Seine effektive Domain (mque) wird es erlauben, daß die Datei in das Warteschlangenverzeichnis geschrieben wird. Durch die Eigenschaft eines Gates wird er in der Lage sein, die tatsächliche Domain zu prüfen, welche diejenige des elterlichen Postsendeprozesses ist. Er wird prüfen, daß der Quellen-Burbparameter zu dem Quellen-Burb des Postsenders paßt. Wenn sie nicht übereinstimmen, tritt ein Konfigurationsfehler auf oder der Postsender wurde vernichtet. In jedem Fall wird der Warteschlangenagent eine Prüfung durchführen und das Programm verlassen. Wenn keine Startprobleme auftreten, wird der Warte­ schlangenagent die Nachricht über SMTP über stdin/stdout empfangen. Die SMTP-Unterstützung wird das mindeste sein, was notwendig ist, um die Nachricht von einem sorgfältig konfigurierten Postsendeprozeß auf dem lokalen System zu empfangen.

Ein langlaufender Dämon ist für die Verarbeitung der Nachricht für einen bestimm­ ten Ablauf verantwortlich. Der Dämon wird durch den elterlichen Filter kontrolliert. Er liest nicht die Verfahrensdatei sondern guckt sich nur ihre Befehlszeile für die zu verwendenden Burbs an (für den Sender und für den Empfänger), die zu gebrau­ chende Karten-Datei (engl.: "map file") und das Warteschlangenverzeichnis, in welchem er funktionieren soll. In einer Ausführungsform ist die Befehlszeile auf die folgende Art und Weise formatiert.

/usr/libexec/mfil_queue_runner<src_burb<<dest_burb<<queue_dir< <map_file<[-d"high"|"low"]

Die Filterkonfiguration muß so flexibel wie möglich sein, um ein zu künftiges Wachstum zu erlauben. Dies ist jedoch gut, da die Filterkonfiguration eines der Eigenschaften werden kann, die viele Facetten aufweisen, welche sichtbar sind und für nichttechnische Leute leicht zu verstehen sind. Die Filteradministration beginnt mit einer Konfigurationsdatei, welche die Filterkomponenten identifiziert, wie sie miteinander verkettet sind und wo sich die Konfigurationsinformation für jede Stufe befindet. Die Komponenten schließen Endgliedmodule, Datenmodifikationsmittel und Filtermodule ein.

Das System für elektronische Post oder das "Post-Framework" ist eine Sammlung von unabhängigen Objekten oder "Knoten", welche in einem oder mehreren Filterabläufen (oder Filtern) angeordnet werden können, um ein beliebiges Sicherheitsverfahren zu beschreiben bzw. in Kraft zu setzen. Die Fig. 2 ist ein Blockdiagramm, welches eine Ausführungsform eines solchen Filters 220 zeigt, welcher Teil eines Post-Frameworks 200 ist. Der Filter 220 kann als eine miteinander verbundene Serie von Knoten ausgedrückt werden. In einer Aus­ führungsform befinden sich drei allgemeine Typen von Knoten: Ein Filter, ein Modifikationsmittel (engl.: "modifier") und einAusgang/Endglied (engl.: "terminal"). Die Knotentypen sind im folgenden genauer beschrieben. Jeder Knoten in dem Filter 220 enthält drei Komponenten: Initialisierung, Nachrichtenverarbeitung und Knotenleerung. Entsprechend einer Ausführungsform gemäß Fig. 3 besteht jeder Knoten aus drei Basissektionen 310, 320, 330, welche alle innerhalb desselben Prozesses existieren. Jede Sektion liefert einen bestimmten Satz von Funktionen. Das Initialisierungsmodul 310 liefert die Initialisierungsfunktionen, einschließlich dem Laden einer Konfigurationsdatei, welche alle konfigurierbaren Einstellungen für den Knoten enthält. Beispiele von verschiedenen Konfigurationsdateien werden später bei der Diskussion jedes Knotentypus vorgestellt. Das Nachrichtenanalyse­ modul 320 liefert die operationellen Funktionen des Knotens. Diese Funktionen können einschließen, die Nachricht zu empfangen, den Filteralgorithmus auf die Nachricht anzuwenden und die Ergebnisse der Knotenverarbeitung zu präparieren und zu übertragen. Das Modul 330, welches zur Leerung des Knotens dient, das sogenannte Clean-Up-Modul 330, enthält Funktionen, welche den Knoten leeren und schließen, wenn er mit der Verarbeitung aufhört. Diese Funktionen stellen sicher, daß das System, in welchem der Knoten ausgeführt wird, in einem guten Zustand verbleibt. Dies stellt eine wohldefinierte Verbindung zwischen zwei beliebigen Knoten zur Verfügung, wodurch maximale Sicherheit sichergestellt wird.

Das Post-Framework 200 ist dazu gedacht, die Entwicklung eines Mische- und Passe-Satzes (engl.: "mix-and-match set") von Filtern zu unterstützen, welche je nach Laune des Administrators miteinander verkettet werden können. Zur gleichen Zeit müssen die Datenstrukturen flexibel und ausdrucksstark sein, so daß anspruchsvolle Filter konstruiert werden können. In einer Ausführungsform wird die Implementierung weiter ausgeführt, wobei C verwendet wird, anstelle einer ausdrucksstärkeren Sprache wie etwa C++ oder Sather, um eine größere Verarbeitungsgeschwindigkeit zu erzielen. Die erweiterbare Datenstruktur (edo), die in Fig. 4 gezeigt ist, ist ein Versuch, eine solche Datenstruktur zu kreieren. Das edo kreiert im wesentlichen eine flache Klassenhierarchie mit einer gemeinsamen Basisklasse und einer einfachen hoch/runter-Einstufung.

Ein edo ist eine standardisierte, einfache Datenstruktur mit bestimmten garantierten Eigenschaften, welche für applikationsspezifische Verwendungen erweitert werden können. Ein Basissatz von edos ist immer verfügbar und passend für einfache Text- oder Bytedatenfilter. Anspruchsvollere Filter können konstruiert werden, um spezialisierte edos mit besonderer applikationsspezifischer Information zu verwenden.

Der Type edo-t ist vom Konzept her eine abstrakte Basisklasse. Er liefert eine gemeinsame Schnittstelle für alle edo-Datenstrukturen. Die Fig. 4 zeigt die konzeptionelle Klassenhierarchie. Das erste Feld der edo-Basis 410, welche den edo_t-Tpy enthält, ist ein abgezählter, ganzzahliger Wert, welcher den Datentyp anzeigt. Alle edos müssen dieselben drei Felder beim Start der Struktur aufweisen. Diese Gruppen von Feldern können teilweise als eine Byte-Maske interpretiert werden. Byte 1 ist kompatibel mit edo-Bytes und wird gesetzt, wenn es ein "Byte- Bucket" ist. Die Byte-Maskeninterpretation ist nicht völlig konsistent bezüglich der Einstufung, aufgrund der Einschränkungen beim Versuch, dieses in der Program­ miersprache C zu tun. Das zweite Feld der edo-Basis ist ein Status-Feld, welches durch die Filterfunktionen gefüllt ist. Das Statusfeld zeigt an, ob das edo durch einen vorigen Filter zurückgewiesen wurde. Andere Bytes zeigen an, ob das edo als verdächtig angesehen wurde oder ob es durch einen Filter editiert wurde. Weder die verdächtigen noch die editierten Zustände tragen exklusiv das Bucket, welches als "korrekt" (engl.: "okay") oder "zurückgewiesen" (engl.: "rejected") angesehen wird. Eine Byte-Maske kann dazu verwendet werden, die Teile herauszuziehen, welche für die Filter- oder Modifikationsknotenverarbeitung als wichtig angesehen werden.

Filter- und Modifikationsmittelknoten können das Zustandsfeld ignorieren oder die von der Verarbeitung zurückgewiesenen Datenknoten überspringen, in Abhängigkeit von ihrem Zweck. Das dritte Feld von jedem edo-Knoten ist ein Zeiger auf einen "Kopie-Konstrukteur" (engl.: "copy constructor"). Dies ist eine Funktion, welche den Knoten duplizieren kann, einen Zeiger auf sich selbst setzend. Das vierte Feld ist ein Zeiger auf eine Lösch-Funktion, welche den Knoten löschen kann und jeden dynamisch verbundenen Speicher leeren kann. Komfort-Macros werden zum Aufrufen dieser Mitgliedsfunktionen zur Verfügung gestellt. Als Beispiel würde für ein gegebenes edo "e" dies dargestellt als:

copy_edo(e);

und

delete_edo(e).

Die Bytes-edo-Sektion 420 ist ein einfaches "Bucket aus Bytes", welches für viele Filteroperationen geeignet ist. Es ist eine dynamisch zugeordnete Reihe von Bytes, welche durch Filter- oder Modifikationsmittelknoten gesucht oder hinzugefügt werden kann. Hier findet sich die tatsächliche Nachricht. Einem Filter- oder Modifikationsmittelknoten, welcher die Daten verändert, wird erlaubt, Standardsy­ stemaufrufe (wie etwa "realloc()") zu verwenden, um - wenn nötig - die Bytes-edo- Reihe 420 in der Größe zu verändern.

Die Daten-edo-Sektion 430 ist eine Metadaten-Sektion, welche es Annotations- und zusätzlichen Daten erlaubt, der ursprünglichen Nachricht hinzugefügt zu werden. Es ist ein Byte-Bucket mit einer Sammlung von edos, welches durch Filter- oder Modifikationsmittelknoten gesucht oder hinzugefügt werden kann. Das Daten-edo 430 wird von einem Bytes-edo 420 abgeleitet und enthält die Annotationen, die durch die Filter- oder Modifikationsmittelknoten angehängt wurden. Derartige Annotationen können Informationen einschließen, welche analysierte Daten (engl.: "parsed data") (welche beispielsweise den Nachrichtensender oder -empfänger identifiziert) tragen, oder möglicherweise den Zurückweisungsgrund, wenn die Nachricht an einem Filter gescheitert ist. Filter- oder Modifikationsmittelknoten, die die verschiedenen Typen von optionalen Daten (welche ebenfalls als EDOs dargestellt werden) kennen, können aufbauend auf diesem Wissen zusätzlichen Kontext erzeugen. Einfachere Filter können die Sammlung ignorieren und können sogar eine Daten-edo-Sektion 430 als eine Bytes-edo-Sektion 420 verarbeiten, welche wirksam ihre Basisklasse bildet.

Das Netzwerk-edo 450 ist ein Daten-EDO mit einigem zusätzlichen Kontext, welcher die Daten beschreibt, welche durch den Filter- oder Modifikationsmittel­ knoten verarbeitet werden. Es schließt die Quellen- und Bestimmungsadresse der Daten ein. Beide, eine oder keine der Adressen können eine Adresse der Maschine sein, auf welcher sich das Post-Framework befindet, abhängig davon, wo die Client/Server-Prozesse angeordnet sind. Diese Information wird von dem Sockel erhalten, welcher die Quelle der Daten war (getpeername(), getsockname()). Indizes für andere physikalische und logische Abschnitte sind ebenfalls in der Adresse enthalten. Die Verwendung der zusätzlichen Informationen in dem Netzwerk EDO 450 kann eine bessere Filterung bewirken; es werden jedoch nicht alle Datenquellen mit einem Netzwerk assoziiert. Darüber hinaus kann eine Filterung der elek­ tronischen Post auch auf Dateien anstelle auf Netzwerkverbindungen stattfinden.

Der Sammel-EDO 440 wird von dem Basis-EDO 410 abgeleitet, welchem er Zeiger zu drei zusätzlichen Funktionen hinzufügt. Diese Funktionen liefern eine einfache Random-Access-Datenstruktur zum Speichern von EDO-Zeigern und zum Indizieren derselben durch ein Schlüsselwort. Eine Funktion wird ein (edo, keyword)-Paar (tuple) der Sammlung hinzufügen. Schlüsselwörter müssen innerhalb einer Sammlung einzigartig sein. Die zweite Funktion wird ein EDO in der auf dem Schlüsselwort basierenden Sammlung finden und die dritte Funktion wird, basierend auf dem Schlüsselwort, ein EDO aus der Sammlung entfernen. Eine EDO-Sammlung wird in den Daten- und Netzwerk-EDO-Typen 430, 450 als ein Feld verwendet. Die antizipierte Verwendung der EDO-Sammlung 440 dient als Mittel zum Tragen eines Satzes von Annotationen zusammen mit dem Datenabschnitt der Nachricht. Beispielsweise kann ein Filter die Köpfe einer Nachricht der elektronischen Post abtrennen. Andere Filter könnten dann die Köpfe der Annotation sehen und die Köpfe einstufen, ohne in der Lage zu sein, sie aus dem Rest der Nachricht zu löschen. Dies unterstützt die Verwendung von Filtersequenzen für ein stromförmi­ ges, verarbeitungsbasiertes Programmierparadigma.

Der binäre Filter erwartet den gesamten Inhalt der Nachricht innerhalb der Bytes- Sektion 410 des EDO 400. Der aktuelle, binäre Filter wird einmal für jede EDO- Bytes-Sektion 410 aufgerufen. Der gesamte Inhalt der Bytes-Sektion 410 wird durch den binären Filter als eine einzelne Nachricht behandelt. Dieser Weg kann nicht garantieren, daß jede spezielle E-mail-Nachricht erfaßt werden wird, wird jedoch die größte Vielzahl von Eindringlingen mit einem einzigen Algorithmus erfassen. Dieser verallgemeinerte Weg ist auch bezüglich anderer Aspekte gegenüber herkömmlichen Systemen verbessert. Da der Weg des binären Filters nicht formatspezifisch ist, ist er viel schwieriger zu durchbrechen. Formatspezifische Systeme folgen den Regeln des Formats und es ist viel einfacher, durch Imitation des Formats die Erkennung zu vermeiden. Darüber hinaus werden zuvor nicht aufgetretene Dateiformate in einem binären Filtersystem immer noch detektiert.

Die Programmierschnittstelle identifiziert ebenfalls den möglichen Bereich des Knotenverhaltens. In einer Ausführungsform ist es die Programmierschnittstelle, welche die Regel des "einen Eingang, einen/zwei Ausgänge", die von jedem Filterknoten befolgt wird, in Kraft setzt. Diese Regel wird streng befolgt, um die Gründlichkeit des Systems aufrechtzuerhalten. Ein solcher Weg limitiert jedoch die Funktionalität des Systems nicht besonders. Wenn ein komplexerer Entscheidungs­ baum benötigt wird, um eine bestimmte Regel in Kraft zu setzen, kann der Baum durch Aneinanderketten einer Serie von Modulen aufgebaut werden. Dies ist aus zwei Gründen dem Aufbau von komplexen Knoten vorzuziehen. Der eine Grund, daß der individuelle Knoten seine Unabhängigkeit behält und verfahrensneutral bleibt. Der andere Grund ist der, daß der Ablauf bei zukünftigen Änderungen des Verfahrens leichter zu pflegen und zu modifizieren ist. Es ist die Programmier­ schnittstelle, welche ebenfalls die Eigenschaft unterstützt, daß jeder Ausgang an einen oder zwei Eingänge geleitet werden kann. Die Programmierschnittstelle ist in der Programmiersprache C++ implementiert, aber die Filterknoten können in C implementiert sein. Die oben beschriebene EDO-Datenstruktur ermöglicht die Flexibilität in den Filterknoten, welche sonst in einer in C geschriebenen Prozedur nicht verfügbar wäre.

Jeder der Knoten erlaubt zusätzliche Interaktionen mit Anwendungen, die extern bezüglich des Postsystems angeordnet sind, für andere Funktionen als die der Postverarbeitung. Beispielsweise kann ein Filterknoten Initialisierungsdaten von einer externen Datei lesen, oder eine Nachricht in eine Protokoll- oder Prüfdatei schreiben. Die durch die Programmierschnittstelle gegebenen Eingang/Ausgang- Begrenzungen beziehen sich nur auf die direkten Interaktionen zwischen den Filterknoten.

Postfilterknoten werden auf eine von drei Arten betriebsfertig gemacht. In einer Ausführungsform werden alle Knoten in eine einzige Bibliothek kompiliert. In dieser Ausführungsform wird die Subroutine in der Bibliothek ausgeführt, wenn ein Knoten aufgerufen wird. Dies ist die Form, welche am besten funktioniert. Sie erzeugt jedoch einige Sicherheitsbedenken, da alle Knoten sich in der gleichen Bibliothek befinden. Um das Postfiltersystem besser abzusichern, können die Knoten jeweils einzeln kompiliert werden. Diese Form verliert etwas Ausführungsgeschwindigkeit, da jedes Filterknotenmodul in den Speicher gebracht wird, wenn es aufgerufen wird, statt daß sich alle im Speicher befinden, nachdem das System initialisiert ist. Die Trennung ist jedoch maximiert, wodurch der beste Schutz gegen die Möglich­ keit zur Verfügung gestellt wird, ein Modul über ein weniger geschütztes Modul anzugreifen. Die dritte Ausführungsform ist ein Kompromiß zwischen den beiden zuvor beschriebenen. In dieser Ausführungsform wird eine Shell in eine gemeinsame Bibliothek für jeden Filterknoten kompiliert; anstatt daß die Bibliotheks-Subroutine den Filtermodulcode ausführt, ruft sie ein externes Programm auf. Dies gibt einiges an Geschwindigkeit zurück, die verloren wird, wenn die Module vollständig voneinander unabhängig sind, ohne daß das Konzept der Isolation der Module vollständig geopfert wird.

Das Postfilter-Framework der vorliegenden Erfindung behandelt Post in ver­ schiedenen Formaten nicht vollständig. Der gleiche Programmierschnittstellencode kann für die Struktur verwendet werden, welche hinter Filterabläufen für ver­ schiedene Formate steht. In einer anderen Ausführungsform kann ein herkömm­ liches Postfiltersystem als ein Vorverarbeitungsschritt verwendet werden, um eine gemeinsame Verarbeitung zu ermöglichen. In dieser Ausführungsform wird der Filterablauf/werden die Filterabläufe dazu verwendet, den zu verwendenden Teil der Nachricht zu identifizieren und/oder die Nachricht der richtigen Anwendung zur weiteren Verarbeitung zuzuleiten. Diese Begrenzung kann akzeptiert werden, da es wünschenswert ist, bei einem konfigurierbaren Signal zu bleiben, welches universell verwendet werden kann. Wenn das Signal einem speziellen Protokoll (beispiels­ weise SMTP, X.400, etc.) zugeordnet wird, ist das Postfiltersystem implizit nicht mehr in der Lage, andere Protokolle zu verarbeiten.

Filtermodule akzeptieren einen Eingang und erzeugen zwei Ausgänge. Ein Ausgang ist, möglicherweise mit Modifikationen, der Eingangs-EDO. Dieser Ausgang wird dem nächsten, auf dem EDO-Filter-Filterergebnis-Feld basierenden Modul zugeleitet. Ein Filtermodul wird mit zwei Ausgängen visualisiert, einer für hindurchgekommene EDOs (engl.: "PASSed EDOs") und einer für abgewiesene EDOs (engl.: "REJECTed EDOs"), wobei jeder getrennt zu anderen Komponenten geleitet werden kann. Die Fig. zeigt ein Beispiel eines Endausgangsmoduls 500 und die Fig. 6 zeigt ein Beispiel eines Filtermoduls 600. Ein Filterknoten akzeptiert den Eingang als Darstellung einer vollständigen Gesamtheit. Die Filterkomponenten können kombiniert werden, um ein Verbundobjekt zu bilden, welches dann als ein Filtermodul oder als ein Endausgangsmodul verwendet werden kann.

Die Konfigurationsdatei sollte sehr flexibel und erweiterbar sein. Die Warte­ schlangenausführungsprogramme sollten in der Lage sein, dieses mitzumachen. Es ist wünschenswert aber nicht notwendig, diese Flexibilität dem Benutzer verfügbar zu machen. Die Fig. 7 zeigt ein Beispiel, wie Komponenten miteinander verdrahtet werden können, um einen Filterablauf in dem Post-Framework der vorliegenden Erfindung zu kreieren. Die graphische Benutzerschnittstelle (GUI) sollte von Programmen wie LabView®, Khoros®, IRIS®, ExpIorer®, AVS® o. dgl. Inspirationen erhalten. Beispiele dieser Produkte sind im Internet unter den folgenden URLs verfügbar:

Khoros screen shot:
http://www.khoros.unm.edu/khoros/screen.jpg
Allgemeine Information über Khoros:	http://www.khoros.unm.edu/khoros/khoros2/home.htme
AVS screen shot:	http://www.avs.com/products/remsense2.gif
Allgemeine Information über AVS:	http://www.avs.com/

Eine andere Ausführungsform der vorliegenden Erfindung enthält eine graphische Schnittstelle zum Aufbau und zur Pflege von Postabläufen innerhalb des Post- Frameworks. Die Fig. 8A ist eine Darstellung einer Ausführungsform des Ablauf­ editierschirms 800. Der Ablaufeditierschirm schließt eine Liste zum Holen der Knotentypen, eine sogenannte Picklist, ein (Verbinder 801 , Anschluß/Endglied 802, Modifikationsmittel 803 und Filter 804), welche verfügbar sind, um in die Filterabläufe eingeschlossen zu werden, und ein Fenster oder ein "Netz" 805 zum graphischen Konstruieren jedes Filterablaufs. Der Administrator selektiert einen oder mehrere Filterknoten 802-804 und lokalisiert sie auf dem "Netz" 805 in der Reihenfolge, in der die Nachrichten verarbeitet werden sollen. Die Knoten werden dann unter Verbindung des Verbindungsikons 801 miteinander verbunden, um die Kanäle 841, 843, 845, 847, 849 für den Eingang und den Ausgang/die Ausgänge für jeden Knoten zu zeigen. Ein zusätzliches Menüfenster, in der Fig. 8B gezeigt, stellt beispielsweise ein Fenster zum Definieren und Pflegen von individuellen Knoten 860 und Filterkarten 862 zur Verfügung. Jeder Knoten erhält einen einzigartigen Namen und seine Eigenschaften (etwa wie er jede eingehende Nachricht verarbeitet) werden unter Verwendung dieser Menüs und Fenster 801 definiert oder modifiziert.

Bezugnahmen in der Beschreibung der Post-Frameworks der vorliegenden Erfindung schließen Annahmen ein, darüber, wie die Information dargestellt und manipuliert werden wird. Dies ist nicht als Notwendigkeit zu interpretieren, sondern als eine Reflexion einer Ausführungsform, die zeigt, wie das Post-Framework und die damit verbundenen Schnittstellen implementiert sind.

Ein Filterablauf ist in einer einfachen Sprache aufgebaut. Er besteht aus einfachen Objekttypen, Konfigurationen dieser Typen, zusammengesetzten Objekte und Objekten, welche Verbindungen zwischen anderen Objekten bilden. In der aktuellen Implementierung ist all dies durch eine Konfigurationsdatei dargestellt, wird aber zu diesem Zeitpunkt auf einer abstrakteren Ebene beschrieben.

Einige der Objekte (oder deren Bezeichner), die hier beschrieben werden, werden durch das GUI für den Administrator direkt sichtbar und manipulierbar. Andere Objekte, welche weniger direkt sichtbar sind, werden über eine graphische Metapher manipuliert und "on the fly" durch den GUI kreiert und zerstört - wie benötigt - um die Objekte zu organisieren. Das visuelle Programm, welches aus diesen Objekten aufgebaut wird, kann als Karte (engl.: "map") bezeichnet werden.

Alle sichtbaren Objekte in einem GUI-Karten-Editor sind "Senken" (engl.: "drains"). Senkenobjekte und ihre Bezeichner werden dynamisch kreiert (ausgenommen konfigurierte Anschlüsse, die so wie sie sind, verwendet werden können), wenn der Benutzer ein konfiguriertes Objekt auswählt und es auf das Netz setzt. Bei einer Ausweitung des Systems werden zusätzliche Arten von Filtern, Modifikationsmitteln und Anschlüssen/Endgliedern auftreten, die darunterliegende, logische Struktur sollte sich jedoch nicht verändern. Das GUI ist derart aufgebaut, daß es ausgewei­ tet werden kann, um die konfigurierten Instanzen von neuen Grundelementen zu unterstützen, aber es wird die Programmierung der neuen Grundelemente in eine neue Karte ohne jegliche Änderungen unterstützen.

Die Fig. 9 stellt ein Beispiel der Spezifikation eines Filterablaufs dar, welcher die Ablaufsprache verwendet. Die Spezifikation schließt derartige Informationen ein, wie etwa die verfügbaren Knotentypen 910, 920, 930. In der Praxis wird eine Filterablaufspezifikation mit einer Syntax geschrieben, die mit den Konfigurations­ dateiformaten konsistent ist, welche von dem System verwendet werden, auf welchem die Post-Struktur arbeitet. Die unten gezeigte Tabelle 1 stellt die musterhaften Ablaufregeln dar, die graphisch in der Fig. 10 gezeigt sind.

Tabelle 1 Musterhafte Ablaufregeln

Knoten
Anweisung
L
userterminalid
K	userterminalid
J	drainfilter (userfilterid, [K], [L])
I	userterminalid
H	drainfilter (userfilterid, [I], [J])
G	drainlist (H)
F	userterminalid
E	userterminalid
D	userterminalid
C	userterminalid
B	drainfilter (userfilterid, [C], [C, G])
A	drainfilter (userfilterid, [B], [D, E, F]).

Wenn versucht wird, einen Graph in eine symbolische Darstellung zu konvertieren, ist es am einfachsten, alle Knoten zu bezeichnen und sich dann von den Blättern nach oben in Richtung der Wurzel vorzuarbeiten. Um beispielsweise die Fig. 7 zu konvertieren, würden wir zuerst die Figur mit Bezeichnungen versehen, wie in Fig. 10 geschehen. Man beachte, daß der Knoten G 1030 tatsächlich überflüssig ist und weggelassen werden könnte, wenn man die Knoten minimieren möchte. Er ist jedoch gültig und möglicherweise nützlich, um die Karte durch die Schichten aufzubauen. Eine Nachricht kommt in den Knoten A 1010, welcher ein Filter ist. Wenn die Nachricht den Filter passiert, wird sie zu dem Knoten B 1015 wei­ tergeleitet, welcher ebenfalls ein Filter ist. Wenn die Nachricht an dem Knoten A 1010 scheitert, wird ein Prüfvorgang den Anschlüssen D 1025, E 1040 und F 1045 zugeleitet. Wenn die Nachricht den Knoten B 1015 passiert, wird sie an den Knoten C 1020 weitergeleitet, welcher in diesem Beispiel ein Endglied ist. Wenn die Nachricht an dem Filter B 1015 scheitert, wird sie jedoch weiterhin an den Knoten C 1020 weitergeleitet. Zusätzlich wird auch ein Prüfvorgang an den Knoten G 1030 weitergeleitet, welcher in einer Ausführungsform einfach ein Endglied ist. In einer anderen Ausführungsform ist der Knoten G 1030 tatsächlich ein weiterer Filterablauf. Der von dem Knoten G 1030 empfangene Prüfvorgang gelangt in den Knoten H 1032, welcher ein Filter ist. Wenn die Information, die den Prüfvorgang enthält, den Filter passiert, dann wird die Information an den Endknoten I 1031 weitergeleitet; anderenfalls wird ein Prüfvorgang an den Filterknoten J 1033 weitergeleitet. Wenn die Prüfvorgangsinformation den Filter 1033 passiert, wird die Information an den Endknoten K 1034 weitergeleitet. Anderenfalls wird ein Prüfvorgang an den Endknoten L 1035 weitergeleitet. Wie dieses Beispiel zeigt, können die verschiedenen Knoten kombiniert werden, um Filterabläufe jeder möglichen Stufe der Komplexität zu bilden. Die obigen Beispiele dienen der Illustration und sind nicht als ausschließliche oder begrenzende Beispiele gedacht.

Für eine gegebene Nachricht wird jedes Endglied in einer Karte nur einmal aktiviert. Dieses Prinzip reagiert, wenn Prüfungsvorgangsnachrichten in eine zusammen­ gesetzte Zurückweisungsnachricht eingebaut werden und wenn verschiedene Meldungen an den gleichen Bestimmungsort gesandt werden. Fehler- und Zurückweisungsgründe werden nicht durch die Filter weitergeleitet. Die Fig. 11 stellt eine Filterkarte dar, in der eine separate Prüfstelle für jeden Filter vorgesehen ist. In der in Fig. 11 gezeigten Karte werden die Zurückweisungen des Schlüssel­ wortsuchfilters 1110 an die Prüfstelle A 1140 gesandt. Die Nachrichten, welche den Schlüsselwortsuchfilter 1110 passieren, gehen zu dem Binärfilter 1120. Zurückweisungen des Binärfilters 1120 werden an die Prüfstelle B 1150 gesandt. Nachrichten, die den binären Filter 1120 passieren, werden nach 1130 wei­ tergeleitet.

Die Fig. 12 illustriert eine Filterkarte, in welcher zwei verschiedene Filter die gleiche Prüfstelle verwenden. In der Karte der Fig. 12 werden Zurückweisungen des Schlüsselwortsuchfilters 1110 an die Prüfstelle A 1140.1 gesandt. Nachrichten, die den Schlüsselwortsuchfilter 1110 passieren, gehen zu dem Binärfilter 1120. Zurückweisungen des Binärfilters 1120 werden auch an die Prüfstelle A 1140.2 gesandt. Nachrichten, die den Binärfilter 1120 passieren, werden nach 1130 weitergeleitet. Man beachte, daß die Prüfstellen-A-Knoten 1140.1 und 1140.2 individuelle Endglieder sind, welche Zurückweisungen dem gleichen Bestimmungsort zuleiten. Die Fig. 13 zeigt eine Ausführungsform, in der Zurückweisungen von verschiedenen Filtern 1110, 1120 über ein einziges Endglied 1140 an die gleiche Prüfstelle gesandt werden. In der Karte der Fig. 13 werden Zurückweisungen des Schlüsselwortsuchfilters 1110 an die Prüfstelle A 1140 gesandt. Nachrichten, die den Schlüsselwortsuchfilter 1110 passieren, gelangen zu dem Binärfilter 11 20. Zurückweisungen des Binärfilters 1120 werden auch an die Prüfstelle A 1140 gesandt. Nachrichten, die den Binärfilter 1120 passieren, werden nach 1130 weitergeleitet. Dies ergibt im Endeffekt die gleichen Ergebnisse wie in der in Fig. 12 gezeigten Karte. Es sei angemerkt, daß, um exakt die gleichen Ergebnisse zu erhalten, eine durch den Filter 1120 hindurchtretende Nachricht mit sich die Zurückweisungsnachricht, welche durch den Filter 1110 erzeugt wurde, tragen müßte.

Die Fig. 14 zeigt eine Instanz, in welcher Zurückweisungen weitergereicht werden und Prüfvorgänge an eine gemeinsame Prüfstelle gehen. Gemäß der Karte in der Fig. 14 werden Zurückweisungen des Schlüsselwortsuchfilters 1110 und des Binärfilters 1120 an die Prüfstelle A 1140 gesandt. Alle Nachrichten gehen zu dem Binärfilter 1120, unabhängig davon, ob sie den Schlüsselwortsuchfilter 1110 passieren oder von diesem zurückgewiesen werden. Wenn eine Nachricht von dem Schlüsselwortsuchfilter 1110 und dem Binärfilter 1120 zurückgewiesen wird, werden zwei Meldungen abgeschickt. Die eine, die an die Prüfstelle B 1150 gesendet wird, wird nur den Zurückweisungsgrund des Binärfilters 1120 enthalten. Die eine, die an die Prüfstelle A 1140 gesendet wird, wird nur den Zurückweisungs­ grund des Schlüsselwortsuchfilters 1110 enthalten. Eine Nachricht muß den Binärfilter 1120 passieren, um zugestellt zu werden aber die Zustellung hängt nicht davon ab, ob sie den Schlüsselwortsuchfilter 1110 passiert hat oder nicht.

Die Fig. 16 stellt ein Kartenbeispiel dar, welches doppelte Prüfstellen verwendet und Zurückweisungen weiterreicht. In der Karte in der Fig. 16 werden Zurückwei­ sungen des Schlüsselwortsuchfilters 1110 an die Prüfstelle A 1140.1 gesandt. Zurückweisungen des Binärfilters 1120 werden auch an die Prüfstelle A 1140.2 gesandt. Wenn eine Nachricht den Schlüsselwortsuchfilter 1110 und den Binärfilter 1120 nicht passiert, werden zwei getrennte Meldungen abgesandt, wobei jede einen einzelnen Zurückweisungsgrund enthält.

Dies liegt darin begründet, daß getrennte Endglieder zum Senden der Meldungen an die Prüfstelle A vorhanden sind. Eine Nachricht muß dem Binärfilter 1120 passieren, um zugestellt zu werden; die Zustellung hängt jedoch nicht davon ab, ob sie den Schlüsselwortsuchfilter 1110 passiert hat oder nicht.

Die Filterkarte gemäß Fig. 17 ist einfach eine Kombination der oben dargestellten Ideen. Die Prüfstelle A 1140 wird nur Meldungen für Nachrichten empfangen, die an dem Schlüsselwortsuchfilter 1110 scheitern. Die Prüfstelle B 1150 wird Meldungen empfangen für Nachrichten, welche an dem Schlüsselwortsuchfilter 1110, dem Binärfilter 1120 oder an beiden scheitern. Wenn eine Nachricht an beiden scheitert, wird die Prüfstelle B 1150 eine einzige Meldung empfangen, welche beide Zurückweisungsgründe enthält. Die Prüfstelle C 1710 wird nur Meldungen für Nachrichten empfangen, die an dem binären Suchfilter 1120 scheitern. Sogar wenn eine Nachricht an beiden scheitert, wird die an die Prüfstelle C 1710 gesandte Meldung nur den Zurückweisungsgrund des binären Filters enthalten. Bei diesem Beispiel werden alle Nachrichten zugestellt.

Die Filterkonfiguration wird tatsächlich durch eine einfache Sprache ausgedrückt, welche in der Syntax der Konfigurationsdatei des Systems dargestellt ist, auf welchem das Post-Framework arbeitet. Der Anhang 1 enthält ein Beispiel einer Ausführungsform einer solchen Filterkonfigurationsdatei. Die Konfiguration teilt sich in drei Teile. Der erste Teil ist die Filterverfahrensdatei, die zuvor beschrieben wurde. Der zweite Teil ist die Filterkonfigurationsdatei, welche alle Teile auflistet, die dazu verwendet werden, die Filterverfahrensdiagramme (Karten genannt) zusammenzustellen. Die konfigurierten Teile und die Dateiregeln werden unten beschrieben. Schließlich enthält der dritte Teil die Kartendateien. Es existiert eine Kartendatei pro konfiguriertem Ablauf, wie später genauer erklärt werden wird.

Als erstes werden kurz die in einer Ausführungsform der vorliegenden Erfindung verwendeten Grundelemente beschrieben. Die Liste der Endgliedmodule in dem Terminal[ ]-Eintrag sind primitive Objekte, die aufgelistet sind, um die Menge des Wissens, welche in der Programmierschnittstelle dauerhaft codiert ist, zu minimieren. Es folgt ein Beispiel von Filterkonfigurationsregeln.

Filterkonfigurationsregeln

Es ist möglich, daß nur ein Terminal[ ]-Eintrag in der Konfigurationsdatei enthalten ist. Die Modifikationsmittelobjekte sind in Modifier[ ] aufgelistet. Dies sind primitive Objekte und sie sind gelistet, um die Menge des Wissens, welche dauerhaft in der Programmierschnittstelle codiert ist, zu minimieren. Es ist möglich, daß sich nur ein Modifier[ ]-Eintrag in der Konfigurationsdatei befindet. Das dritte Grundelement ist ein Filter. Eine Filterliste ist eine Liste aller Filtertypen, welche das System kennt. Indem die Filterliste in die Konfigurationsdatei gesetzt wird, weist die Filter­ programmierschnittstelle so wenig wie möglich dauerhaft codierte Informationen auf. Genau wie bei den zuvor beschriebenen Grundelementen kann sich auch nur ein Filter[ ]-Eintrag in der Konfigurationsdatei befinden.

Die Konfigurationsinformation für Endglieder, Modifikationsmittel und Filter (engl.: "terminals", "modifiers", "filters") sind alle auf die gleiche Art und Weise unter Verwendung der "conf_info"-Regel spezifiziert. Diese Regel schließt einen Pfad zu einer Konfigurationsdatei und einen Token ein. Für einfache Objekte kann der Token alleine ausreichend sein. Für andere kann die Datei alles enthalten und der Token nicht verwendet werden. Wenn verschiedene Objekte eine Konfigurationsdatei teilen, dann kann die Datei durch den Pfad spezifiziert werden und der Token kann einen speziellen Eintrag in der Datei anzeigen. Wenn ein Token oder ein Pfadfeld ungenutzt ist, dann muß es auf den String "none" gesetzt werden. Dies bedeutet, daß "none" für keines dieser Felder als gültiger Wert verwendet werden kann. Ein konfiguriertes Endglied wird mit der "conf_terminal"-Regel gesetzt. Dies verbindet einen Bezeichner mit dem Endgliedtyp und diesem Satz der Konfigurations­ information. Für viele Endglieder wird es keine konfigurierbaren Variablen geben, so daß sie vorkonfiguriert sein können und der Benutzer nicht in der Lage sein wird, zusätzliche zu konfigurieren. Das Endglied-Feld muß ein gültiges Feld der Terminal[ ]- Liste enthalten. Ein konfiguriertes Modifikationsmittel wird mit der "con_modifier"- Regel gesetzt. Dies verbindet einen Bezeichner mit dem Modifikationsmittel-Typ und diesem Satz der Konfigurationsinformation. Das Modifikationsmittel-Feld muß ein gültiges Feld der Modifier[ ]-Liste enthalten. Ein konfigurierter Filter wird mit der "con_filter"-Regel gesetzt. Dies verbindet einen Bezeichner mit dem Filter-Typ und diesem Satz der Konfigurationsinformation. Das Filterfeld muß einen gültigen Wert der Filter[ ]-Liste enthalten.

Die "Senken"-Objekte sind Verbindungen zwischen einem konfigurierten Objekt und Verbindungen zu anderen Senken-Objekten. Diese Objekte definieren die Ver­ bindungen in den Ablaufdiagrammen. Ein konfiguriertes Endglied wird ebenfalls als ein Senken-Objekt angesehen, da es aufgrund des Fehlens von Ausgängen vollstän­ dig isoliert ist. Bei komplexen Objekten sind die Ausgangsfelder Listen von Senken- IDs (IDs = Bezeichner). Konfigurierte Objekte weisen IDs auf, die der Benutzer eingegeben hat und dazu benutzt, das Objekt zu identifizieren bzw. zu bezeichnen. Senken weisen ebenfalls Bezeichner auf, aber diese Bezeichner dienen - ausgenom­ men für konfigurierte Endglieder - einem vollständig internen Zweck und können auf beliebige, dem Admininistrationswerkzeug angepaßte Weise gewählt werden.

Eine Senken-Liste ist eine Liste von gültigen Senkenbezeichnern. Dies ist einfach ein Organisationsobjekt. Ein Senkenmodifikationsmittel (engl.: "Drain Modifier") ist eine Verbindung eines konfigurierten Modifikationsmittels mit einer Liste von Ausgangssenken. Dieser Verbindung wird ein Senkenbezeichner gegeben, so daß er mit dem Ausgang eines stromaufwärts liegenden Knotens verbunden werden kann. Ein Senkenfilter ist eine Verbindung eines konfigurierten Filters mit einem Senkenbezeichner (did). Dieser Verbindung wird ein Senkenbezeichner gegeben, so daß der Senkenfilter ebenfalls mit dem Ausgang eines stromaufwärts liegenden Knotens verbunden werden kann. Schließlich muß für jeden Ablauf ein einzelner Eintrag für das Quellen/Bestimmungsort-(engl.: "Source/Destination")-Burbpaar erfolgen. Dieser Eintrag enthält die Burb-Namen und einen einzelnen Senkenbezeich­ ner. Durch Vorbelegung (und möglichst in der Skelettdatei) sollten alle Standard­ abläufe so konfiguriert werden, daß sie das Zuliefer-Senkenobjekt verwenden.

Für jeden Ablauf existiert eine Konfigurationsdatei, die den Ablauf beschreibt. Wenn sich ein Ablauf in der Verfahrensdatei befindet, aber keine Karte existiert, dann gelangt die Post in die Warteschleife, wird jedoch nicht verarbeitet. Die Karte besteht aus Verbindungen der konfigurierten Filterobjekte, wie es in Fig. 19 dargestellt ist. In einer Ausführungsform sind Kartendateien in einem Kartenunter­ verzeichnis gespeichert und jeweils individuell bezeichnet. Beispielsweise kann eine Kartendatei mit dem Namen "kws_only.conf" versehen sein. In diesem Fall ist der Kartenname nur "kws_only". Es folgen Beispiele einer Ablaufkonfigurationsdatei und einer Kartenkonfigurationsdatei.

Ablaufkonfigurationsdatei

Kartenkonfigurationsdatei

Filterablaufmodule sollten so einfach wie möglich sein. Neue oder weniger technisch versierte Benutzer sollten in der Lage sein, die Filter auf einfache Art und Weise zu benutzen und nicht durch zu viele Optionen und zuviel Intellektualismus überwältigt werden. Wenn sich eine komplizierte Fähigkeit in dem System befindet, kann es angemessen sein, eine einfachere Version zur Verfügung zu stellen, welche leichter zu verwenden ist. Beispielsweise basiert der Schlüsselwortsuchfilter auf regulären Ausdrücken; reguläre Ausdrücke sind jedoch zu abschreckend für die unvorbereiteten Benutzer und komplexer als das, was viele Benutzer benötigen. Die Schlüsselwortsuche macht daher nur eine Teilmenge der Funktionalität sichtbar: Token mit optionalen Wildcards am Anfang und am Ende. Für diejenigen, die mit den vollständigen, regulären Ausdrücken arbeiten wollten, kann diese Funktionalität in einem logischen, wenn nicht gar physikalisch abgetrennten Filter zur Verfügung gestellt werden, welchen die weniger technisch versierten Benutzer völlig ignorieren können.

Wo immer möglich, sollten die Filter eine Schwelle pro Nachricht aufweisen, anstelle von Boolschen Alles-Oder-Nichts-Zurückweisungskriterien. Für ein Schlüsselwort oder einen regulären Textfilter kann dies eine gegebene Anzahl von Übereinstimmungen sein. Für etwas wie ein binärer Filter kann dies eine bestimmte Empfindlichkeit sein. Es ist klar, daß Filter, wie etwa die PGP-Unterschrifts­ verifikation, ein streng Boolsches Verhalten aufweisen.

Wenn ein Filter eine Nachricht zurückweist, muß er zwei Arten von Prüfnachrichten an das Edo anhängen. Diese sollten in der Reihenfolge vom kleinsten zum größten angehängt werden, da, wenn der Speicher während der Verarbeitung erschöpft ist, die kleinere Nachricht anstelle der größeren verwendet werden kann, während das umgekehrte nicht immer wahr ist. Im folgenden einige Beispiele für solche Nachrichten:

• 1. Eine kurze Prüfnachricht.
  Dies ist eine kurze, beschreibende Nachricht, welche den Fehler so gut wie möglich beschreiben soll, aber ausreichend knapp ist, um in einem Prüf­ protokoll aufgenommen zu werden. In einer Ausführungsform ist die kurze Prüfnachricht bevorzugterweise kürzer als 160 Byte.
• 2. Eine detaillierte Prüfnachricht.
  Dies ist eine detaillierte Nachricht, die versucht, genau zu beschreiben, warum die Nachricht zurückgewiesen wurde. Beispielsweise würde ein Schlüsselwortfilter die Wörter auflisten, die mit Einträgen in der Wortliste übereinstimmen.
• 3. Eine allgemeine Prüfnachricht.
  In einer Ausführungsform ist dies eine Nachricht, die für alle Zurückweisun­ gen die gleiche ist. In einer anderen Ausführungsform ist diese Nachricht konfigurierbar, so daß der Standort Informationen über die Sicherheitsver­ fahren des Standorts und über die Art und Weise, wie die verantwortlichen Administratoren bei der Verletzung behilflich sein können, einschließt. In einer weiteren Ausführungsform wird ein allgemeines Begründungsmodul kreiert, welches in Verbindung mit einem beliebigen Filter verwendet werden kann.

Eine Vielzahl von Filtertypen ist in der Poststruktur der vorliegenden Erfindung konfigurierbar. Ein Typ ist ein Schlüsselwortsuchfilter, welcher in seiner einfachsten Form die Nachricht auf eine Übereinstimmung mit einem der Wörter, die sich in einer vordefinierten Liste befinden, absucht. Ein anderer Filtertyp ist ein binärer Filter, welcher dazu dient, Post aufzufangen, welche keinen "normalen" Text aufweist oder Anhänge einschließt, die kein Text sind. Dies ist ein nebulöses Mustererkennungsziel. Dinge die erfaßt werden sollten schließen ein: MIME-Anhänge, nicht-kodierte Dateien, btoa-kodierte Dateien, binhex-kodierte Dateien sowie unbearbeitet binäre, verschlüsselte Post- und Share-Dateien. Normale elektronische Post, welche in einer natürlichen menschlichen Sprache geschrieben ist, wie etwa in englisch, sollte passieren.

Ein dritter Filtertyp ist ein Größenfilter. Es ist wünschenswert, einen Filter zu haben, der basierend auf der Nachrichtengröße Nachrichten zurückweist. Die Schwelle (T) würde konfigurierbar sein und in Byte spezifiziert sein. Die Nachricht würde zurückgewiesen, wenn die Nachrichtengröße (M) größer oder gleich zu der Größenschwelle ist:

M T (1)

In einer Ausführungsform ist die Schwelle etwas unscharf. Wenn die Eigenschaft der Unschärfe implementiert wird, wird sie ein konfigurierbarer Wert (F) in Byte. Einen beliebigen Wert (R) angenommen, der gleichförmig zwischen Null und Eins verteilt ist, würde die Schwellenfunktion machen zu:

Wenn der Überschuß an Filterung als zu exzessiv angesehen wird, könnte ein Filter konstruiert werden, welcher Filter auf zufällig ausgewählte Nachrichten anwendet. Die Frequenz der Filterung könnte als ein Kompromiß zwischen Durchsatz und Vollständigkeit der Abdeckung aller Nachrichten ausgewählt werden. Dies würde einfach ein einzelner, konfigurierbarer Wert sein, welcher den Prozentsatz der Nachrichten, die gefiltert würden, darstellt. Der Durchschnittsfachmann wird erkennen, daß eine große Vielzahl von Filtertechniken vorhanden ist, welche hier eingearbeitet werden können, ohne daß der Bereich und der Geist der vorliegenden Erfindung verlassen wird.

Modifikationsmittel sind Kartenobjekte, die einen einzelnen Eingang aufnehmen können und zu einem einzelnen Ausgang führen. Modifikationsmittel werden für Handlungen verwendet, die nicht das Weiterleiten der Nachricht selektieren, wie etwa das Hinzufügen von Anhängen oder eine gewisse Art von gleichförmiger Modifikation der Nachricht. Ein Beispiel des ersteren würde die Hinzufügung eines allgemeinen Zurückweisungsgrundes sein. Ein Beispiel für das zweite würde das Löschen der Nachrichtenköpfe sein.

Bei einer Implementierung eines Schlüsselwortsuchfilters war der Hintergedanke, einen konfigurierbaren "allgemeinen" Zurückweisungsgrund zu haben, welcher für alle Nachrichten, die den Filter verletzen würden, der gleiche sein würde. Bei dieser Annäherung bestehen drei Probleme. Erstens, der Zurückweisungsgrund wird immer hinzugefügt, auch wenn er niemals gebraucht wird, was einen unerwünschten Überschuß darstellt, insbesondere, wenn Filter aneinander gekettet werden. Zweitens - aus der Konstruktionsperspektive gesehen - ist es bei allen Filtern notwendig, daß der Code zur Unterstützung dieser Fähigkeit in diese eingebaut ist. Drittens - aus der Anwenderperspektive gesehen - stellt diese Annäherung keinen einfachen Weg dar, eine einzigen allgemeinen Zurückweisungsgrund zu haben, welcher von vielen Filtern geteilt wird.

Im Ergebnis werden Filter, die als Teil des Post-Frameworks der vorliegenden Erfindung konstruiert sind, keine allgemeinen Zurückweisungsgründe an Nachrichten anhängen. Statt dessen wird ein einfaches Eins-Hinein-, Eins-Hinaus-Daten­ modifikationsmittel (engl.: "one-in, one-out data modifier") kreiert, welcher einen allgemeinen Zurückweisungsgrund an alle Nachrichten, die hindurchtreten, anhängt. Das Funktionalitäts-Äquivalent zum herkömmlichen Design ist in der Fig. 18 dargestellt. Eine alternative Anwendung ist in der Fig. 19 dargestellt.

Die Konfigurationsinformation für das Modifikationsmittel 1830 für den allgemeinen Zurückweisungsgrund ist einfach der Text des Zurückweisungsgrundes. Der Text wird in einer einfachen ASCII-Datei gehalten, welche wörtlich an die Nachricht angehängt wird. Da keine andere Information konfigurierbar ist, wird das Systemkonfigurationsdateiformat nicht verwendet. Die conf_info-Einträge der Filter.conf-Dateien werden den Pfad zu der Datei einschließen; das Token-Feld wird nicht verwendet. Beispiel:

Man beachte, daß die Dienstfunktionen der Filterbibliothek hinzugefügt werden sollten, um das Öffnen und Lesen von Textdateien zu unterstützen, mit der gleichen Dateiverriegelungssemantik, die auch von der Konfigurationsbibliothek verwendet wird, so daß Deadlock- und Race-Bedingungen vermieden werden.

Eine andere Funktion, welche durch ein Modifikationsmittel zur Verfügung gestellt werden kann, ist das Löschen der Nachrichtenköpfe. Das Löschen der Nachrichten­ köpfe bedeutet, die Information von den Köpfen, die möglicherweise Information über das interne Netzwerk offenbart und welche von dem Postzustellsystem nicht benötigt wird, um die Post zuzustellen zu entfernen. Anfänglich beinhaltet dies die Entfernung von "Empfangen durch"-Zeilen (engl.: "received-by lines") in Out-Bound- Post (engl.: "out-bound mail"). Viele andere Modifikationsmittel sind ebenfalls möglich, wie etwa jene, die auf der Bestimmungsadresse basierende, digitale Signaturen oder verschlüsselte Nachrichten anfügen. Die in der Diskussion der Funktionalität des Modifikationsmittels gegebenen Beispiele dienen der Illustration und sind keine ausschließlichen oder begrenzenden Beispiele.

Endgliedobjekte ("Senken") sind im allgemeinen einfach und möglicherweise nicht dynamisch konfigurierbar. Die folgende Diskussion zeigt detailliert verschiedene Typen von Endgliedern und ihre Konfigurationsinformation. Die meisten Bezeichner und Token-Namen können angepaßt werden, um zu den Bedürfnissen der Benutzerschnittstelle zu passen. Die Beispiele dienen als Illustration und sind nicht dazu gedacht, ausschließlich oder auf irgendeine Art und Weise beschränkend zu wirken.

Ein Typ ist das "stelle an den Empfänger zu"-Endglied (engl.: "deliver to recipient terminal"). Diese Handlung dient dazu, die Nachricht zu den von dem Sender geplanten Empfängern zuzustellen. Dieses Endglied ist normalerweise am Ende einer Filterkette angeordnet, als Einwirkung auf Nachrichten, die alle Filter passiert haben. Es kann auf zurückgewiesene Nachrichten auch angewendet werden, wenn das Standortverfahren eine schnelle Verteilung gegenüber einer sehr genauen Prävention bevorzugt. Es gibt keine konfigurierbaren Optionen für dieses Endglied. Ein einfacher Eintrag wird in dem Konfigurationsfile filter.conf vorkonfiguriert:

Das "zurück zum Sender"-Endglied (engl.: "return to sender terminal") schickt die Nachricht an den Sender zurück. Die zurückgewiesene Nachricht kann den detaillierten Zurückweisungsgrund, den allgemeinen Zurückweisungsgrund oder den kurzen Zurückweisungsgrund enthalten. Wenn der Filter derart konfiguriert ist, daß er den allgemeinen Zurückweisungsgrund zurückschickt, jedoch keiner angefügt wurde, wird er statt dessen den kurzen Zurückweisungsgrund verwenden. Die einzige konfigurierbare Option ist der Typ der Zurückweisungsnachricht. Diese Information wird in dem Token-Feld der Konfigurationsinformation enthalten sein. Die Einträge werden keine separaten Konfigurationsdateien aufweisen. Bei der Ausführungsform, in welcher nur drei mögliche Konfigurationen vorhanden sind, sollten alle drei bei der Vorbelegungsinstallation vorkonfiguriert werden.

Das "Post zum Prüfer"-Endglied (engl.: "mail to reviewer terminal") kapselt die Nachricht ein und sendet sie zu einer Prüfstelle. Die Nachricht muß als ein MIME-Anhang eingekapselt werden oder einfach als ein beabsichtigter Textblock. In einer Ausführungsform ist diese Auswahl konfigurierbar. In einer alternativen Aus­ führungsform ist diese Auswahl nicht konfigurierbar und sie ist vorkonfiguriert, um einen einzelnen Entwurf (wie etwa einen gewünschten Textblock) zu unterstützen. Es ist wichtig, daß die Nachricht auf eine Weise eingekapselt werden kann, so daß übliche Attacken gegen Postzustellungsprogramme ineffektiv sind, wenn die Nachricht zu dem Prüfer gesandt wird. Andererseits könnte man einen Filter konstruieren, welcher den Angriff detektiert und ihn weiterleitet, um die Prüfstelle anzugreifen. Dies ist eine angebrachte Methode, um Informationen zu der Prüfstelle zu bringen; aber auf diese Weise weitergeleitete Post kann durch den Prüfer nicht richtig weitergeleitet werden. Wenn das Senden von dem Prüfer abhängt, dann wird der Prüfer ein manuelles Prüfwerkzeug verwenden müssen. Die konfigurierbaren Optionen dieses Endglieds sind die E-mail-Adresse des Empfängers der Nachricht, der Burb-Name, dort wo die elektronische Postadresse ist, die Auswahl der einzuschließenden (wenn überhaupt) Zurückweisungsnachricht und ob die Nachricht oder nur die Zurückweisungsnachricht eingeschlossen werden soll oder nicht. Eine einzige Konfigurationsdatei wird existieren, um die Konfigurationsinformation für alle Endglieder dieses Typs aufzunehmen. Die Information in config.info wird der Pfad zu der Konfigurationsdatei und der Endgliedbezeichner sein. Beispiel:

Ein Beispiel der Inhalte der entsprechenden Postprüfkonfigurationsdatei (mailaudit.conf) ist in dem folgenden Beispiel dargestellt.

Postprüfkonfigurationsdatei

Postnachrichten können sehr groß sein, insbesondere für einen binären Filter oder einen Größenfilter für Nachrichten. Das "log to file"-Endglied protokolliert Nachrichten in eine Datei in einem Verzeichnis. Das Verzeichnis ist konfigurierbar. Es befindet sich eine einzelne Instanz eines solchen Verzeichnisses vorkonfiguriert auf dem System. Wenn eine neue Instanz konfiguriert wird, ist es notwendig, das Verzeichnis zu kreieren, zu schreiben und der Einrichtung hinzuzufügen, die die Prüf- und Protokoldateien zurückstellt. Wenn ein manuelles Prüfwerkzeug vorhanden ist, wird es in der Lage sein, die Nachrichten von diesem Verzeichnis zu verarbeiten. Dies könnte auf eine Weise, analog zu Strikeback-Berichten verwendet werden: Sende eine einfache Notiz und speichere das ganze in einer Datei. Der zuvor beschriebene Postmelder würde in diesem Szenario verwendet, um eine kurze oder eine allgemeine Zurückweisungsnotiz zu versenden. Die konfigurierbaren Optionen schließen das zu verwendende Verzeichnis ein, wenn eine Nachricht geschrieben wird, die Wahl der Zurückweisungsnachricht, die einzuschließen ist (wenn überhaupt) und ob oder ob nicht die Nachricht oder nur die Zurückweisungs­ nachricht eingeschlossen werden soll. Es existiert eine einzelne Konfigurationsdatei, um die Konfigurationsinformationen für alle Endglieder dieses Typs aufzunehmen. Es werden zwei Einträge vorkonfiguriert; einer für jeden der Standardabläufe. Die Information in config_info wird der Pfad zu der Konfigurationsdatei und der Endgliedbezeichner sein. Beispiel:

Ein Beispiel der Inhalte der entsprechenden Dateiprüfkonfigurationsdatei ist in dem folgenden Beispiel dargestellt.

Postprüfkonfigurationsdatei

Ein anderer Endgliedtyp ist das "Prüf"-Endglied (engl.: "audit terminal"). Dieses Endglied sendet eine Nachricht zu der Prüfeinrichtung. Diese wird einen der Filterung angepaßten Typ aufweisen und das Quellen-Burb, das Bestimmungs-Burb und die kurze Prüfnachricht umfassen. In diesem Endglied ist nichts konfigurierbar. Ein einzelner Eintrag wird in filter.conf vorkonfiguriert.

Die Entgliedbeispiele, welche oben beschrieben sind, sind nur beispielhaft und dienen nicht dazu, etwas auszuschließen oder zu beschränken. Der Durchschnitts­ fachmann wird erkennen, daß andere Endgliedtypen konstruiert werden können, ohne daß der Geist und der Umfang der vorliegenden Erfindung überschritten wird.

Obwohl die vorliegende Erfindung mit Bezug auf die bevorzugten Ausführungs­ formen beschrieben wurde, wird der Durchschnittsfachmann erkennen, daß Änderungen in der Form und im Detail gemacht werden könne, ohne daß der Geist und der Bereich der vorliegenden Erfindung verlassen wird.

ANHANG I

Filterkonfigurationsbeispielsdatei

Claims (26)

1. Verfahren zur Filterung von Nachrichten der elektronischen Post, mit den Schritten:
eine Vielzahl von Knoten wird definiert, wobei jeder Knoten eine Operation identifiziert und einer der Knoten ein Filterknoten ist, welcher zu filternde Nachrichten identifiziert;
aus der Vielzahl von Knoten werden Knoten verbunden, so daß die verbundenen Knoten ein Sicherheitsverfahren beschreiben; und
eine Nachricht der elektronischen Post wird durch den Filterknoten hindurchgeleitet,
wobei der Schritt, eine Nachricht der elektronischen Post durch den Filterknoten hindurchzuleiten die Schritte enthält:
Bestimmen, ob die Nachricht der elektronischen Post eine ist, welche zu filtern ist;
die Nachricht der elektronischen Post wird durch einen oder mehrere Filterabläufe verarbeitet, wenn die Nachricht der elektronischen Post als zu filtern identifiziert ist; und
ansonsten die Nachricht der elektronischen Post ohne Filterung weiterzuleiten.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt der Verarbeitung der Nachricht der elektronischen Post die Schritte aufweist:
die Nachricht wird analysiert, um zu bestimmen, ob sie eine bestimmte Eigenschaft aufweist; und
die Nachricht der elektronischen Post wird basierend auf dem Ergebnis der Analyse abgefertigt.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß der Schritt des Abfertigens der Nachricht der elektronischen Post den Schritt des Zustellens der Nachricht beinhaltet.

4. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß der Schritt des Abfertigens der Nachricht der elektronischen Post den Schritt des Zurückweisens der Nachricht umfaßt.

5. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß der Schritt des Abfertigens der Nachricht der elektronischen Post den Schritt des Übertragens einer Prüfnachricht umfaßt.

6. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß der Schritt des Abfertigens der Nachricht der elektronischen Post die Schritte umfaßt:
die Nachricht wird zugestellt;
die Nachricht wird zurückgewiesen; und
eine Prüfnachricht wird übertragen.

7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt des Abfertigens der Nachricht der elektronischen Post den Schritt des Modifizierens der ersten Nachricht der elektronischen Post umfaßt.

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß der Schritt des Abfertigens der Nachricht der elektronischen Post den Schritt des Veränderns der Adresse der ersten Nachricht der elektronischen Post umfaßt.

9. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß der Schritt des Abfertigens der Nachricht der elektronischen Post den Schritt des Veränderns des Kopfes der ersten Nachricht der elektronischen Post umfaßt.

10. Filter für elektronische Post, welcher aufweist:
ein Analysemodul zum Analysieren einer Nachricht der elektronischen Post, wobei das Analysemodul einschließt:
Knotendefinitionsmittel zum Definieren einer Vielzahl von Knoten, wobei jeder Knoten eine Operation identifiziert und einer der Knoten ein Filterknoten ist, welcher zu filternde Nachrichten identifiziert; und
Verbindungsmittel zum Verbinden von Knoten der Vielzahl von Knoten, so daß die verbundenen Knoten ein Sicherheitsverfahren beschreiben; und
ein Ausgangsmodul, welches mit dem Analysemodul verbunden ist, um eine Vielzahl von Ausgangsnachrichten zu erzeugen, wobei eine der Vielzahl von Nachrichten als eine Funktion der Analyse der Nachricht der elektronischen Post durch das Analysemodul erzeugt wird.

11. Filter für elektronische Post nach Anspruch 10, dadurch gekennzeichnet, daß die Knotendefinitionsmittel Mittel zum Erzeugen einer Vielzahl von individuellen, unabhängigen Filter-, Modifikations- und Endglied-Knoten umfaßt; und
wobei die Verbindungsmittel Mittel zum Verbinden der Vielzahl von individuellen Filter-, Modifikations- und Endglied-Knoten umfassen.

12. System zum Filtern elektronischer Post, welches aufweist:
Mittel zum Empfangen von Nachrichten elektronischer Post, mit einer ersten Nachricht, aus einer oder mehreren Quellen; und
ein Analysemodul zum Bestimmen, ob die erste Nachricht gefiltert werden soll, wobei das Analysemodul aufweist:
eine Vielzahl von Filtern, einschließlich einem ersten Filter, zum Analysieren von Eigenschaften der ersten Nachricht; und
ein oder mehrere Endglieder, einschließlich einem ersten Endglied, zum Zustellen der ersten Nachricht an einen oder mehrere Bestimmungsorte.

13. System nach Anspruch 12, dadurch gekennzeichnet, daß das Analysemodul weiterhin eine Vielzahl von Modifikationsmitteln, einschließlich einem ersten Modifikationsmittel, enthält, wobei jedes aus der Vielzahl von Modifikationsmitteln arbeitet, um die erste Nachricht zu modifizieren.

14. Verfahren zum Verwalten einer Filterkarte, mit den Schritten:
ein oder mehrere in die Karte aufzunehmende Knoten werden identifiziert, wobei jeder Knoten eine Operation definiert, welche mit einer Nachricht auszuführen ist, wobei der Schritt des Identifizierens den Schritt der Definition eines Sicherheitsver­ fahrens enthält;
eine Reihenfolge wird definiert, in welcher die Operationen mit der Nachricht auszuführen sind;
jeder der Knoten wird gemäß der definierten Ordnung graphisch positioniert; und
zwischen den Knoten werden graphisch Verbindungen identifiziert, als eine Funktion eines oder mehrerer Leitungspfade, welche an einem beliebigen Knoten verfügbar sind.

15. Verfahren zum Aufbau eines Filters für elektronische Post, mit einem oder mehreren Nachrichtenleitungspfaden, mit den Schritten:
ein Verfahren wird identifiziert, welches den einen oder mehrere Nachrichtenlei­ tungspfade beschreibt;
eine Vielzahl von Filterknoten zum Analysieren der Nachrichten der elektronischen Post wird definiert;
eine Vielzahl von Modifikationsknoten zum Modifizieren der Nachrichten der elektronischen Post wird definiert;
ein oder mehrere Endgliedknoten zum Zustellen der Nachrichten der elektronischen Post und anderer elektronischer Information werden definiert; und
die Vielzahl der Filterknoten, Modifikationsknoten und Endgliedknoten wird verbunden, um somit das Verfahren zu implementieren.

16. System für elektronische Post, welches aufweist:
einen Postfilter (220) mit einer Vielzahl von Filterobjekten (802, 803, 804), wobei die Filterobjekte in einem Ablauf angeordnet sind, welcher ein Sicherheitsverfahren in Kraft setzt; und
ein Postzustellagent (210), welcher mit dem Postfilter (220) verbunden ist, wobei der Postzustellagent eine Nachricht der elektronischen Post empfängt und die Nachricht der elektronischen Post basierend auf einem Postfilterverfahren weiterleitet, wobei das Postfilterverfahren die Post bestimmt, die in eine Warte­ schleife zu bringen ist und die Post bestimmt, die weiterzuleiten ist;
wobei der Postfilter die Nachrichten der elektronischen Post, welche durch den Postzustellagenten in eine Warteschlange verbracht wurden, wiedergewinnt und die wiedergewonnenen, elektronischen Nachrichten gemäß dem Sicherheitsverfahren filtert.

17. System gemäß Anspruch 16, dadurch gekennzeichnet, daß die Vielzahl der Filterobjekte einen Endgliedknoten­ typus (802) enthält.

18. System nach Anspruch 16, dadurch gekennzeichnet, daß die Vielzahl der Filterobjekte einen Modifikations­ knotentyp (803) enthält.

19. System nach Anspruch 16, dadurch gekennzeichnet, daß die Vielzahl von Filterobjekten einen Filterknotentyp (804) enthält.

20. System nach Anspruch 16, dadurch gekennzeichnet, daß die Vielzahl von Filterobjekten eine Vielzahl von Knotentypen (802, 803, 804) enthält, wobei jeder Knotentyp eine Initialisierungs­ sektion, eine Nachrichtenverarbeitungssektion und eine Knotenlöschsektion enthält.

21. System nach Anspruch 16, dadurch gekennzeichnet, daß die Vielzahl von Filterobjekten eine Vielzahl von Knotentypen (802, 803, 804) enthält, wobei einer der Vielzahl von Knotentypen Information an die Postnachricht anhängt.

22. System nach Anspruch 16, dadurch gekennzeichnet, daß die Vielzahl von Filterobjekten eine Vielzahl von Knotentypen (802, 803, 804) enthält, wobei einer der Vielzahl von Knotentypen Prüfnachrichten erzeugt.

23. System nach einem der Ansprüche 16 oder 20, dadurch gekennzeichnet, daß das Postfilterverfahren in einer Postfilterverfahrens­ datei als ein Satz von Burb-Paaren gespeichert ist, wobei jedes Burb-Paar einen ersten und einen zweiten Burb enthält, wobei Nachrichten von dem ersten zu dem zweiten Burb durch den Postzustellagenten in eine Warteschlange verbracht werden.

24. Verfahren zur Filterung von Nachrichten der elektronischen Post, mit den Schritten:
eine Vielzahl von Knotentypen wird zur Verfügung gestellt;
die Vielzahl von Knotentypen wird gemäß einem Sicherheitsverfahren verbunden;
eine Nachricht der elektronischen Post wird empfangen; und
die Nachricht der elektronischen Post wird als eine Funktion der Nachricht der elektronischen Post analysiert.

25. Verfahren nach Anspruch 24, dadurch gekennzeichnet, daß der Schritt des Verbindens die Schritte einschließt:
eine Vielzahl von Knotentypen werden als Ikons innerhalb eines visuellen Mediums dargestellt;
Kopien der Ikons werden auf dem visuellen Medium in Abhängigkeit einer Eingabe eines Benutzers plaziert; und
die auf dem visuellen Medium plazierten Ikons werden verbunden.

26. Verfahren nach Anspruch 24, dadurch gekennzeichnet, daß der Schritt des Verbindens den Schritt des Kon­ figurierens der Vielzahl von Knotentypen einschließt, um eine Funktion eines Satzes von Funktionen, welcher Weiterleiten, Zurückweisen und Zurückleiten der Nachricht umfaßt, auszuführen.