Die hier beschriebenen Methoden beziehen sich auf die wissenschaftliche Arbeitsweise, sowohl auf theoretischer als auch auf praktischer Ebene, welche in dieser Arbeit Anwendung findet.

Dem Geiste nach wird versucht dem wissenschaftstheoretischen Ideal aus der \QuoteM{Logik der Forschung} \RefIt{popper1998karl} von Karl R. Popper zu entsprechen. Demnach ist die Arbeit als Ganzes vor allem ein Diskussionsvorschlag an den wissenschaftlichen Apparat. Sie stellt aber ebenso eine Behauptung auf mit der Erwartung, dass an derselben Falsifikationsversuche durchgeführt werden können.

Das Wesen der Falsifikation ist hier allerdings etwas anders als in klassischen empirischen Wissenschaften wie der Physik. Neben der logischen Falsifikation, die sich vor allem auf Argumentationsfehler und Logikfehler im Allgemeinen bezieht, ist die sogenannte empirische Falsifikation im Kontext der hier aufgestellten Behauptungen weniger exakt und die Trennung beider Formen weniger eindeutig. Konzeptionelle Fehler und Schwächen können sowohl a priori, als auch a posteriori erkannt werden, da die Tauglichkeit des vorgeschlagenen Systems nicht rein formal bestimmt werden kann. Viele in der Praxis relevante Details und Faktoren wirken auf das System als ganzes ein und machen Falsifikationsversuche schwieriger. Mögliche Angriffsvektoren werden häufig erst entwickelt oder entdeckt, wenn ein System bereits eine Weile in Benutzung ist. Gerade deshalb sind weite Teile des vorgeschlagenen Systems nur sehr abstrakt beschrieben. Somit konzentriert sich diese Arbeit mehr auf eine Idee, weniger auf ein vollständig durchdachtes Konzept und kann letzteres auch nicht leisten.

Die genannte Idee wird im Zuge dessen argumentativ unterstützt, sowohl im Rückblick auf das existierende E-Mail System und seine Schwächen, als auch im Hinblick auf Systeme im allgemeinen, die ähnliche algorithmische Methoden erfolgreich verwenden.

Auf dieser Basis wird weiterhin versucht nachzuweisen, dass der Algorithmus im Kern implementierbar ist und die Proof of Concept Implementierung zumindest die wichtigsten Anforderungen aus \autoref{tab:FunctionalRequirements} und \autoref{tab:NonFunctionalRequirements} tatsächlich erfüllen kann.

Die Implementierung wird sich auf den Kern-Algorithmus beschränken und ein minimales Testsystem zur Simulation von MTA-Kommunikation beinhalten.

Bei der Entwicklung der Implementierung wird eine abgewandelte Form des Prototyping Modells \RefIt{swprototyping} angewendet. Dabei ist der erste Schritt die Entwicklung eines Testsystems, das ein verteiltes System simulieren kann. Andernfalls ist es schwierig, in kurzen Abständen Codeänderungen durchzuführen und deren Auswirkungen zu überprüfen. Sobald dieses Testsystem steht, wird eine existierende SMTP Implementierung ausgewählt und diese ins Testsystem integriert. Das Testsystem beschränkt sich hierbei auf sichtbare Laufzeittests. Ist diese grundlegende Funktionalität gegeben, so wird der eigentliche Algorithmus injiziert und ohne weitere Iterationen vervollständigt. Erst nach dieser Phase findet eine Reflexion statt, die Refactoring oder sogar eine vollständige Neuentwicklung zur Folge haben kann. Der Dokumentationsprozess ist ein fortlaufender Prozess, der in jeder Phase der Entwicklung stattfindet.


