Der Multicastempfänger ist zuständig für den Empfang der mittels verschickten Daten. Die erhaltenen Artikel werden dann via NNTP an einen NTA weitergeleitet, wie dies in 4.5.1 beschrieben wird.
Ist dieser NTA nicht betriebsbereit, werden die Artikel auf einer lokalen Platte abgelegt, so daß sie später, wenn der Server wieder funktionstüchtig ist, nicht noch einmal vom entfernten Newsserver übertragen werden müssen (siehe Abschnitt 4.5.2).
Nach dem Start wird die Liste der bekannten öffentlichen Schlüssel (der sog. Keyring zum Format siehe 4.6.1) geladen. Ist der Keyring nicht vorhanden, terminiert . Danach wird eine Verbindung zum angegebenen NNTP-Server aufgemacht; ist keiner angegeben, wird der auf dem lokalen Host verwendet. War der Verbindungsaufbau erfolgreich, befindet sich im Modus M_NNTP, ansonsten im Modus M_Spool. Nachfolgend wird Mitglied in der Multicastgruppe MCNTP-DIRECTORY.MCAST.NET und wartet auf Ankündigungspakete. Wenn ein Ankündigungspaket erhalten wird, wird es durchsucht, ob es die passenden Newsgruppen enthält. Wenn nicht, wird weiter gewartet. 2
Wird die passende Gruppe gefunden, wird Mitglied in der entsprechenden Multicastgruppe (``Neue Gruppe betreten'' in Abbildung 35) und wartet auf Pakete. Bei Erhalt eines Datenpaketes wird als erstes die digitale Signatur überprüft. Ist diese gut, wird das Paket weiterverarbeitet, wie dies weiter unten beschrieben wird, ansonsten verworfen.
War das empfangene Paket ein Ankündigungspaket, wird geprüft, ob sich die Multicastgruppe, in der die Artikeldaten versandt werden, geändert hat. Wenn dies der Fall ist, wird die Gruppe verlassen, in der Mitglied ist (``alte Multicastgruppe verlassen'' in Abb. 35) und die im Ankündigungspaket angegebene abonniert (``Neue Gruppe betreten'' in Abbildung 35).
Die Überprüfung der Signatur erfolgt, wie schon in Abschnitt 3.7 prinzipiell beschrieben, dadurch, daß der Datenbereich des Paketes (der Wert ``Daten'' in Abbildung 31 ) mit dem zur ``Sender-ID '' passenden Schlüssel entschlüsselt wird (der Schlüssel muß sich im Keyring befinden). Schlägt die Entschlüsselung fehl, wird das Paket weggeworfen. Dann wird über den empfangenen Artikel ein RIPEMD-160 Message-Digest gebildet und mit dem im Paket enthaltenen verglichen. Stimmen die beiden überein, stammt der Artikel von einem bekannten Absender und wurde beim Transport nicht verändert (Dadurch erspart man sich eine extra Prüfsumme über das Paket)..
In ``Zustand prüfen'' wird, wenn sich nicht im Zustand M_Nntp befindet, und eine gewisse konfigurierbare Zeitspanne verstrichen ist (z.B. alle zwei Minuten), überprüft, ob der NNTP-Server wieder in der Lage ist, Artikel anzunehmen. Wenn ja, nimmt den Betriebszustand M_Nntp wieder an. 2
Die weitere Bearbeitung des Pakets ist in Grafik 36 dargestellt. Als erstes wird das Paket, wenn nötig dekomprimiert. Dies geschieht durch Aufruf der Funktion () aus der Bibliothek zlib ;schlägt dies fehl, wird das Paket weggeworfen.
Wenn der Server im Modus M_Nntp ist, d.h. der Newsserver ist in der Lage, Pakete zu empfangen, wird versucht das Paket via NNTP dem NTA abzuliefern (siehe 4.5.1. Falls dies nicht gelingt, wird, falls noch Plattenplatz vorhanden ist, der Artikel als sogenannter Batch auf der Platte abgelegt, wie dies unter 4.5.2 noch näher beschrieben wird und der Server geht in den Betriebszustand M_Spool über. Schlägt auch noch das Ablegen auf der Platte fehl, geht in den Betriebszustand M_None über und verwirft das Paket.
In den Abbildungen nicht dargestellt ist ein zusätzliches Feature: bevor die Ankündigungs- und Datenpakete verarbeitet werden können diese mittels Zugangskontrollisten (ACL) nach Absender gefiltert werden. Diese Zugangskontrollisten bieten nur sehr wenig Schutz gegen die Verfälschung der Daten, da die IP-Adresse des Absenders gefälscht sein kann (deswegen werden die Artikel digital signiert). Die Listen können aber eingesetzt werden, wenn z.B. ein Störenfried Pakete schickt, um so die Last auf dem Client zu erhöhen. Mehr Informationen zu den Zugangskontrollisten gibt es in Abschnitt 4.6.3.