hasufell/bachelorthesis
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity

First commit

Browse Source
This commit is contained in:
Julian Ospald 2016-06-15 14:40:15 +02:00
commit c05745a3de
No known key found for this signature in database
GPG Key ID: 511B62C09D50CD28
258 changed files with 168267 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
.gitignore vendored Normal file
View File

@ -0,0 +1,29 @@
_minted-*
*.aux
*.log
*.out
*.pdf
*.gz
*.toc
*.nav
*.snm
*.vrb
*.mintedcmd
*.mintedmd5
*.dvi
*.cdb
*.cdm
*.pdb
*.pdm
*.bak
*.directory
*.bbl
*.blg
*.lof
*.lot
*.swp
*.lol
*.idx
*.ilg
*.ind
*~

44
Bachelorthesis/Appendix.tex Normal file
View File

@ -0,0 +1,44 @@
\begin{appendix}
\chapter{Beiliegende Datenträger}
Dieser Arbeit liegt eine CD bei. Nachfolgend wird der Inhalt aufgelistet und beschrieben.
\section{Inhaltsliste}
\begin{itemize}
\setlength\itemsep{\Itemizespace}
\item CD 1
\begin{itemize}
\setlength\itemsep{\Itemizespace}
\item Thesis
\begin{itemize}
\setlength\itemsep{\Itemizespace}
\item Binary
\item Source
\end{itemize}
\item Webseiten
\item RFCs in Textform
\item Implementierung
\begin{itemize}
\setlength\itemsep{\Itemizespace}
\item Dockerfiles
\item Source
\item Konfigurationsdateien
\end{itemize}
\item Dokumentation
\begin{itemize}
\item Handbuch
\end{itemize}
\end{itemize}
\end{itemize}
\clearpage
\section{Inhaltsbeschreibung}
Die Implementierung befindet sich im Unterordner \verb#Implementierung# und beinhaltet dort auch den Quellcode für die Docker Images \verb#alpine-haraka#, \verb#alpine-haraka-gateway# und \verb#alpine-swaks#. Die Haraka Plugins sind also jeweils in den Ordnern \\ \verb#Implementierung/alpine-haraka/plugins# und \\ \verb#Implementierung/alpine-haraka-gateway/plugins#.
Der Latex Quellcode befindet sich im Unterordner \verb#LaTeX# und ein Symlink zur PDF existiert im Root-Ordner als \verb#Bachelorthesis.pdf#.
Alle RFCs sind in Textform im Unterordner \verb#RFCs# aufzufinden. Ebenso sind alle referenzierten Webseiten statisch im Unterordner \verb#Webseiten# verfügbar.
\end{appendix}

161
Bachelorthesis/Bachelorthesis.tex Executable file
View File

@ -0,0 +1,161 @@
\documentclass[ %draft, % To display over/unterfull hboxes
a4paper, % use DIN A4 Paper
onecolumn, % Only one Column of text
oneside, % Pint only right sides
titlepage, % Print a titlepage
openany, % Open new chapter on any page
12pt] % Text size
{report}
\include{Content/Settings}
\begin{document}
\thispagestyle{empty}
\input{Content/TitlePage}
\input{Content/Abstract}
\setcounter{page}{3}
\tableofcontents
\chapter{Einleitung}
\input{Content/Intro}
\section{E-Mail Format (IMF)}
\input{Content/Intro/Format}
\section{E-Mail Protokolle}
\input{Content/Intro/Protokolle}
\subsection{SMTP}
\input{Content/Intro/Protokolle/SMTP}
\subsection{POP3}
\input{Content/Intro/Protokolle/POP3}
\subsection{IMAP4}
\input{Content/Intro/Protokolle/IMAP4}
\section{E-Mail als Gesamtsystem}
\input{Content/Intro/Gesamtsystem}
\chapter{Motivation und Problematik}
\input{Content/Problematik}
\section{Betrachtung von Datenschutz in aktuellen E-Mail Systemen}
\input{Content/Problematik/BetrachtungDatenschutz}
\subsection{Verschlüsselung von E-Mail-Verkehr}
\input{Content/Problematik/BetrachtungDatenschutz/Verschluesselung}
\subsubsection{GPG}
\input{Content/Problematik/BetrachtungDatenschutz/Verschluesselung/GPG}
\subsubsection{TLS}
\input{Content/Problematik/BetrachtungDatenschutz/Verschluesselung/TLS}
\subsubsection{STARTTLS}
\input{Content/Problematik/BetrachtungDatenschutz/Verschluesselung/STARTTLS}
\subsection{Anonymität von E-Mail-Verkehr}
\input{Content/Problematik/BetrachtungDatenschutz/Anonymitaet}
\subsubsection{TorBirdy}
\input{Content/Problematik/BetrachtungDatenschutz/Anonymitaet/TorBirdy}
\subsection{Bewertung}
\input{Content/Problematik/BetrachtungDatenschutz/Bewertung}
\section{Anforderungen an eine adäquate Lösung}
\input{Content/Problematik/Anforderungen}
\chapter{Alternative Lösungen bzw. E-Mail Systeme}
\input{Content/AlternativeLoesungen}
\section{Dark Mail}
\input{Content/AlternativeLoesungen/DarkMail}
\section{Bewertung}
\input{Content/AlternativeLoesungen/Bewertung}
\chapter{Entwicklung eines SMTP-basierten Anonymisierungs-Algorithmus}
\input{Content/Entwicklung}
\section{Idee \& Konzept}
\input{Content/Entwicklung/IdeaConcept}
\subsection{Algorithmus}
\input{Content/Entwicklung/IdeaConcept/Algorithmus}
\section{Methoden}
\input{Content/Entwicklung/Methoden}
\section{Realisierung}
\input{Content/Entwicklung/Realisierung}
\subsection{Testsystem}
\input{Content/Entwicklung/Realisierung/Testsystem}
\subsection{Implementierung}
\input{Content/Entwicklung/Realisierung/Implementierung}
\subsubsection{Wahl der SMTP-Software}
\input{Content/Entwicklung/Realisierung/Implementierung/Wahl}
\subsubsection{Übersicht über Haraka}
\input{Content/Entwicklung/Realisierung/Implementierung/Haraka}
\subsubsection{Wahl des Einsprungpunktes}
\input{Content/Entwicklung/Realisierung/Implementierung/Einsprungpunkt}
\subsubsection{Implementierung MTA-Entscheider}
\input{Content/Entwicklung/Realisierung/Implementierung/MTA-Entscheider}
\subsubsection{SMTP-Gateway und MystMail Erstellung}
\input{Content/Entwicklung/Realisierung/Implementierung/SMTP-gateway}
\subsubsection{Haraka Konfiguration}
\input{Content/Entwicklung/Realisierung/Implementierung/Konfiguration}
\chapter{Evaluation \& Validation}
\input{Content/EvaluationValidation}
\chapter{Ausblick}
\input{Content/LookOut}
\section{Theoretische Probleme}
\input{Content/LookOut/TheoretischeProbleme}
\subsubsection{Verschlüsselungsalgorithmus}
\input{Content/LookOut/TheoretischeProbleme/Verschluesselung}
\subsubsection{Public-Key System}
\input{Content/LookOut/TheoretischeProbleme/PublicKey}
\subsubsection{Routing-Algorithmus}
\input{Content/LookOut/TheoretischeProbleme/RoutingAlgo} \subsubsection{Kryptografie-System insgesamt}
\input{Content/LookOut/TheoretischeProbleme/KryptografieSystem}
\subsubsection{Fehlen einer Spezifikation}
\input{Content/LookOut/TheoretischeProbleme/Spezifikation}
\section{Praktische Probleme}
\input{Content/LookOut/PraktischeProbleme}
\subsubsection{Professionelle Implementierung}
\input{Content/LookOut/PraktischeProbleme/Implementierung}
\subsubsection{Fehlerbehandlung}
\input{Content/LookOut/PraktischeProbleme/Fehlerbehandlung}
\subsubsection{Verifizierung und Authentizität}
\input{Content/LookOut/PraktischeProbleme/Verify}
\subsubsection{Spam-Abwehr und Traffic}
\input{Content/LookOut/PraktischeProbleme/Spam}
\subsubsection{Directory Server}
\input{Content/LookOut/PraktischeProbleme/DirectoryServer}
\subsubsection{Zuverlässigkeit}
\input{Content/LookOut/PraktischeProbleme/Zuverlaessigkeit}
\subsubsection{Gesamtsystem}
\input{Content/LookOut/PraktischeProbleme/Gesamtsystem}
% appendix
\input{Appendix}
\cleardoublepage
\phantomsection
\addcontentsline{toc}{chapter}{\listfigurename}
\listoffigures
\cleardoublepage
\phantomsection
\addcontentsline{toc}{chapter}{\listtablename}
\listoftables
\cleardoublepage
\phantomsection
\addcontentsline{toc}{chapter}{\lstlistlistingname}
\lstlistoflistings
\cleardoublepage
\phantomsection
\markboth{\uppercase{\ListOfAbbreviations}}{}
\chapter*{\ListOfAbbreviations}
\addcontentsline{toc}{chapter}{\ListOfAbbreviations}
\input{Content/ListOfAbbreviations/ListOfAbbreviations}
\cleardoublepage
\phantomsection
\addcontentsline{toc}{chapter}{\bibname}
\bibliography{BachelorthesisLiterature}
\end{document}

719
Bachelorthesis/BachelorthesisLiterature.bib Executable file
View File

@ -0,0 +1,719 @@
@misc{rfc196,
author="R.W. Watson",
title="{Mail Box Protocol}",
series="Request for Comments",
number="196",
howpublished="RFC 196",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1971,
month=jul,
note="Obsoleted by RFC 221",
url="http://www.ietf.org/rfc/rfc196.txt",
}
@misc{rfc2045,
author="N. Freed and N. Borenstein",
title="{Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies}",
series="Request for Comments",
number="2045",
howpublished="RFC 2045 (Draft Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1996,
month=nov,
note="Updated by RFCs 2184, 2231, 5335, 6532",
url="http://www.ietf.org/rfc/rfc2045.txt",
}
@misc{rfc2046,
author="N. Freed and N. Borenstein",
title="{Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types}",
series="Request for Comments",
number="2046",
howpublished="RFC 2046 (Draft Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1996,
month=nov,
note="Updated by RFCs 2646, 3798, 5147, 6657",
url="http://www.ietf.org/rfc/rfc2046.txt",
}
@misc{rfc2047,
author="K. Moore",
title="{MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text}",
series="Request for Comments",
number="2047",
howpublished="RFC 2047 (Draft Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1996,
month=nov,
note="Updated by RFCs 2184, 2231",
url="http://www.ietf.org/rfc/rfc2047.txt",
}
@misc{rfc2049,
author="N. Freed and N. Borenstein",
title="{Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples}",
series="Request for Comments",
number="2049",
howpublished="RFC 2049 (Draft Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1996,
month=nov,
url="http://www.ietf.org/rfc/rfc2049.txt",
}
@misc{rfc4288,
author="N. Freed and J. Klensin",
title="{Media Type Specifications and Registration Procedures}",
series="Request for Comments",
number="4288",
howpublished="RFC 4288 (Best Current Practice)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2005,
month=dec,
note="Obsoleted by RFC 6838",
url="http://www.ietf.org/rfc/rfc4288.txt",
}
@misc{rfc4289,
author="N. Freed and J. Klensin",
title="{Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures}",
series="Request for Comments",
number="4289",
howpublished="RFC 4289 (Best Current Practice)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2005,
month=dec,
url="http://www.ietf.org/rfc/rfc4289.txt",
}
@misc{rfc1521,
author="N. Borenstein and N. Freed",
title="{MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies}",
series="Request for Comments",
number="1521",
howpublished="RFC 1521 (Draft Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1993,
month=sep,
note="Obsoleted by RFCs 2045, 2046, 2047, 2048, 2049, updated by RFC 1590",
url="http://www.ietf.org/rfc/rfc1521.txt",
}
@misc{rfc1522,
author="K. Moore",
title="{MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text}",
series="Request for Comments",
number="1522",
howpublished="RFC 1522 (Draft Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1993,
month=sep,
note="Obsoleted by RFCs 2045, 2046, 2047, 2048, 2049",
url="http://www.ietf.org/rfc/rfc1522.txt",
}
@misc{rfc2183,
author="R. Troost and S. Dorner and K. Moore",
title="{Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field}",
series="Request for Comments",
number="2183",
howpublished="RFC 2183 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1997,
month=aug,
note="Updated by RFCs 2184, 2231",
url="http://www.ietf.org/rfc/rfc2183.txt",
}
@misc{rfc5322,
author="P. Resnick",
title="{Internet Message Format}",
series="Request for Comments",
number="5322",
howpublished="RFC 5322 (Draft Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2008,
month=oct,
note="Updated by RFC 6854",
url="http://www.ietf.org/rfc/rfc5322.txt",
}
@misc{rfc2822,
author="P. Resnick",
title="{Internet Message Format}",
series="Request for Comments",
number="2822",
howpublished="RFC 2822 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2001,
month=apr,
note="Obsoleted by RFC 5322, updated by RFCs 5335, 5336",
url="http://www.ietf.org/rfc/rfc2822.txt",
}
@misc{rfc5321,
author="J. Klensin",
title="{Simple Mail Transfer Protocol}",
series="Request for Comments",
number="5321",
howpublished="RFC 5321 (Draft Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2008,
month=oct,
note="Updated by RFC 7504",
url="http://www.ietf.org/rfc/rfc5321.txt",
}
@misc{rfc6376,
author="D. Crocker and T. Hansen and M. Kucherawy",
title="{DomainKeys Identified Mail (DKIM) Signatures}",
series="Request for Comments",
number="6376",
howpublished="RFC 6376 (INTERNET STANDARD)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2011,
month=sep,
url="http://www.ietf.org/rfc/rfc6376.txt",
}
@misc{rfc4035,
author="R. Arends and R. Austein and M. Larson and D. Massey and S. Rose",
title="{Protocol Modifications for the DNS Security Extensions}",
series="Request for Comments",
number="4035",
howpublished="RFC 4035 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2005,
month=mar,
note="Updated by RFCs 4470, 6014, 6840",
url="http://www.ietf.org/rfc/rfc4035.txt",
}
@misc{rfc1939,
author="J. Myers and M. Rose",
title="{Post Office Protocol - Version 3}",
series="Request for Comments",
number="1939",
howpublished="RFC 1939 (INTERNET STANDARD)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1996,
month=may,
note="Updated by RFCs 1957, 2449, 6186",
url="http://www.ietf.org/rfc/rfc1939.txt",
}
@misc{rfc3501,
author="M. Crispin",
title="{INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1}",
series="Request for Comments",
number="3501",
howpublished="RFC 3501 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2003,
month=mar,
note="Updated by RFCs 4466, 4469, 4551, 5032, 5182, 5738, 6186, 6858",
url="http://www.ietf.org/rfc/rfc3501.txt",
}
@misc{rfc822,
author="D. Crocker",
title="{STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES}",
series="Request for Comments",
number="822",
howpublished="RFC 822 (INTERNET STANDARD)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1982,
month=aug,
note="Obsoleted by RFC 2822, updated by RFCs 1123, 2156, 1327, 1138, 1148",
url="http://www.ietf.org/rfc/rfc822.txt",
}
@misc{rfc821,
author="J. Postel",
title="{Simple Mail Transfer Protocol}",
series="Request for Comments",
number="821",
howpublished="RFC 821 (INTERNET STANDARD)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1982,
month=aug,
note="Obsoleted by RFC 2821",
url="http://www.ietf.org/rfc/rfc821.txt",
}
@misc{rfc2821,
author="J. Klensin",
title="{Simple Mail Transfer Protocol}",
series="Request for Comments",
number="2821",
howpublished="RFC 2821 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2001,
month=apr,
note="Obsoleted by RFC 5321, updated by RFC 5336",
url="http://www.ietf.org/rfc/rfc2821.txt",
}
@misc{rfc6409,
author="R. Gellens and J. Klensin",
title="{Message Submission for Mail}",
series="Request for Comments",
number="6409",
howpublished="RFC 6409 (INTERNET STANDARD)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2011,
month=nov,
url="http://www.ietf.org/rfc/rfc6409.txt",
}
@misc{rfc2487,
author="P. Hoffman",
title="{SMTP Service Extension for Secure SMTP over TLS}",
series="Request for Comments",
number="2487",
howpublished="RFC 2487 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1999,
month=jan,
note="Obsoleted by RFC 3207",
url="http://www.ietf.org/rfc/rfc2487.txt",
}
@misc{rfc1730,
author="M. Crispin",
title="{Internet Message Access Protocol - Version 4}",
series="Request for Comments",
number="1730",
howpublished="RFC 1730 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1994,
month=dec,
note="Obsoleted by RFCs 2060, 2061",
url="http://www.ietf.org/rfc/rfc1730.txt",
}
@misc{rfc2595,
author="C. Newman",
title="{Using TLS with IMAP, POP3 and ACAP}",
series="Request for Comments",
number="2595",
howpublished="RFC 2595 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1999,
month=jun,
note="Updated by RFC 4616",
url="http://www.ietf.org/rfc/rfc2595.txt",
}
@misc{rfc974,
author="C. Partridge",
title="{Mail routing and the domain system}",
series="Request for Comments",
number="974",
howpublished="RFC 974 (Historic)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=1986,
month=jan,
note="Obsoleted by RFC 2821",
url="http://www.ietf.org/rfc/rfc974.txt",
}
@misc{rfc4880,
author="J. Callas and L. Donnerhacke and H. Finney and D. Shaw and R. Thayer",
title="{OpenPGP Message Format}",
series="Request for Comments",
number="4880",
howpublished="RFC 4880 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2007,
month=nov,
note="Updated by RFC 5581",
url="http://www.ietf.org/rfc/rfc4880.txt",
}
@misc{rfc5246,
author="T. Dierks and E. Rescorla",
title="{The Transport Layer Security (TLS) Protocol Version 1.2}",
series="Request for Comments",
number="5246",
howpublished="RFC 5246 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2008,
month=aug,
note="Updated by RFCs 5746, 5878, 6176, 7465, 7507, 7568, 7627, 7685",
url="http://www.ietf.org/rfc/rfc5246.txt",
}
@misc{rfc7457,
author="Y. Sheffer and R. Holz and P. Saint-Andre",
title="{Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)}",
series="Request for Comments",
number="7457",
howpublished="RFC 7457 (Informational)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2015,
month=feb,
url="http://www.ietf.org/rfc/rfc7457.txt",
}
@misc{rfc3207,
author="P. Hoffman",
title="{SMTP Service Extension for Secure SMTP over Transport Layer Security}",
series="Request for Comments",
number="3207",
howpublished="RFC 3207 (Proposed Standard)",
publisher="IETF",
organization="Internet Engineering Task Force",
year=2002,
month=feb,
url="http://www.ietf.org/rfc/rfc3207.txt",
}
% ssmtps
@misc{ssmtps,
Title = {Regularizing Port Numbers for SSL},
Author = {Christopher Allen},
HowPublished = {\url{https://lists.w3.org/Archives/Public/ietf-tls/1997JanMar/0079.html}},
Month = {1},
Year = {1999},
Note = {[Online; geprüft 10.03.16]},
Owner = {Christopher Allen},
Timestamp = {2016.02.12},
Urldate = {2016.02.12},
}
% email statistics report
@misc{erep,
Title = {Email Statistics Report, 2013-2017},
Author = {Sara Radicati, PhD and
Justin Levenstein},
HowPublished = {\url{http://www.radicati.com/wp/wp-content/uploads/2013/04/Email-Statistics-Report-2013-2017-Executive-Summary.pdf}},
Month = {4},
Year = {2013},
Note = {[Online; geprüft 14.03.16]},
Owner = {The Radicati Group, Inc.},
Timestamp = {2016.02.12},
Urldate = {2016.02.12},
}
@misc{torbirdyhp,
author = {{The Tor project}},
title = {TorBirdy Homepage},
month = 7,
year = 2015,
HowPublished = {\url{https://trac.torproject.org/projects/tor/wiki/torbirdy}},
Note = {[Online; geprüft 14.03.16]},
urldate = {2015-12-26}
}
@misc{torbrowserhp,
author = {{The Tor project}},
title = {Tor Browser Homepage},
month = 7,
year = 2015,
HowPublished = {\url{https://www.torproject.org/projects/torbrowser.html.en}},
Note = {[Online; geprüft 14.03.16]},
urldate = {2015-12-26}
}
@misc{thunderbirdhp,
author = {{Mozilla}},
title = {Thunderbird Homepage},
month = 2,
year = 2016,
HowPublished = {\url{https://www.mozilla.org/en-US/thunderbird/}},
Note = {[Online; geprüft 14.03.16]},
urldate = {2015-12-26}
}
@misc{gnupghp,
author = {{The GNU Privacy Guard Team}},
title = {The GNU Privacy Guard Homepage},
month = 12,
year = 2015,
HowPublished = {\url{https://www.gnupg.org}},
Note = {[Online; geprüft 14.03.16]},
urldate = {2015-12-26}
}
@misc{dockerhp,
author = {{Docker}},
title = {Docker Homepage},
month = 02,
year = 2016,
HowPublished = {\url{https://www.docker.com/}},
Note = {[Online; geprüft 14.03.16]},
urldate = {2016-02-12}
}
@misc{sendmailhp,
author = {{Sendmail, Inc.}},
title = {Sendmail Homepage},
month = 02,
year = 2016,
HowPublished = {\url{http://www.sendmail.com/sm/open_source/}},
Note = {[Online; geprüft 14.03.16]},
urldate = {2016-02-12}
}
@misc{opensmtpdhp,
author = {{OpenBSD}},
title = {OpenSMTPD Homepage},
month = 02,
year = 2016,
HowPublished = {\url{https://www.opensmtpd.org/}},
Note = {[Online; geprüft 14.03.16]},
urldate = {2016-02-12}
}
@misc{opensmtpdrel,
author = {{OpenBSD}},
title = {OpenSMTPD first release Website},
month = 02,
year = 2016,
HowPublished = {\url{http://www.openbsd.org/53.html}},
Note = {[Online; geprüft 14.03.16]},
urldate = {2016-02-12}
}
@misc{harakahp,
author = {{Unbekannt}},
title = {Haraka Homepage},
month = 02,
year = 2016,
HowPublished = {\url{https://haraka.github.io/}},
Note = {[Online; geprüft 14.03.16]},
urldate = {2016-02-12}
}
@incollection{apopinsec,
year={2008},
isbn={978-3-540-79262-8},
booktitle={Topics in Cryptology – CT-RSA 2008},
volume={4964},
series={Lecture Notes in Computer Science},
editor={Malkin, Tal},
doi={10.1007/978-3-540-79263-5_1},
title={Security of MD5 Challenge and Response: Extension of APOP Password Recovery Attack},
url={http://dx.doi.org/10.1007/978-3-540-79263-5_1},
publisher={Springer Berlin Heidelberg},
keywords={APOP; Challenge and Response; Password Recovery; Hash Function; MD5; Collision Attack; Message Difference},
author={Sasaki, Yu and Wang, Lei and Ohta, Kazuo and Kunihiro, Noboru},
pages={1-18},
}
@INPROCEEDINGS{Syverson97anonymousconnections,
author = {Paul F. Syverson and David M. Goldschlag and Michael G. Reed},
title = {Anonymous connections and onion routing},
booktitle = {In IEEE Symposium on Security and Privacy},
year = {1997},
pages = {44--54}
}
@techreport{mitm,
title = {{Active Man in the Middle Attacks}},
author = {Roi Saltzmann and Adi Sharabani},
group = {IBM Rational Application Security
Group},
year = {2009},
month = {02},
institution = {IBM Rational Application Security Group}
}
@misc{torbirdy,
Title = {Towards a Tor-safe Mozilla Thunderbird},
Author = {{The Tor project}},
HowPublished = {\url{https://trac.torproject.org/projects/tor/raw-attachment/wiki/doc/TorifyHOWTO/EMail/Thunderbird/Thunderbird%2BTor.pdf}},
Month = {7},
Year = {2011},
Note = {[Online; geprüft 14.03.16]},
Owner = {The Tor project},
Timestamp = {2016.02.12},
Urldate = {2016.02.12},
}
@inproceedings{torpaper,
author = {Dingledine, Roger and Mathewson, Nick and Syverson, Paul},
title = {Tor: The Second-generation Onion Router},
booktitle = {Proceedings of the 13th Conference on USENIX Security Symposium - Volume 13},
series = {SSYM'04},
year = {2004},
location = {San Diego, CA},
pages = {21--21},
numpages = {1},
url = {http://dl.acm.org/citation.cfm?id=1251375.1251396},
acmid = {1251396},
publisher = {USENIX Association},
address = {Berkeley, CA, USA},
}
@ARTICLE{onionrouting1,
author = {David Goldschlag and Michael Reed and Paul Syverson},
title = {Onion Routing for Anonymous and Private Internet Connections},
journal = {Communications of the ACM},
year = {1999},
volume = {42},
pages = {39--41}
}
@INPROCEEDINGS{onionrouting2,
author = {Roger Dingledine and Nick Mathewson and Paul Syverson},
title = {Tor: The Second-Generation Onion Router},
booktitle = {IN PROCEEDINGS OF THE 13 TH USENIX SECURITY SYMPOSIUM},
year = {2004},
publisher = {}
}
@book{popper1998karl,
title={Karl Popper: Logik Der Forschung},
author={Popper, K.R. and Keuth, H.},
isbn={9783050030210},
lccn={99516156},
series={Klassiker Auslegen},
url={https://books.google.de/books?id=cAbXAAAAMAAJ},
year={1998},
publisher={Akademie Verlag GmbH}
}
@ARTICLE{swprototyping,
author={Luqi},
journal={Computer},
title={Software evolution through rapid prototyping},
year={1989},
volume={22},
number={5},
pages={13-25},
keywords={medical computing;software engineering;deliverable version;evolution activities;hyperthermia system;incremental implementation effort;rapid prototyping;requirements analysis;requirements errors;software evolution;software systems;Buildings;Computer bugs;Concrete;Costs;Production systems;Prototypes;Software prototyping;Software systems;Software tools;Virtual prototyping},
doi={10.1109/2.27953},
ISSN={0018-9162},
month={May},}
@article{Chaum:1981:UEM:358549.358563,
author = {Chaum, David L.},
title = {Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms},
journal = {Commun. ACM},
issue_date = {Feb. 1981},
volume = {24},
number = {2},
month = feb,
year = {1981},
issn = {0001-0782},
pages = {84--90},
numpages = {7},
url = {http://doi.acm.org/10.1145/358549.358563},
doi = {10.1145/358549.358563},
acmid = {358563},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {digital signatures, electronic mail, privacy, public key cryptosystems, security, traffic analysis},
}
@misc{darkmail,
Title = {Dark Internet Mail Environment: Architecture and Specifications},
Author = {Ladar Levison},
HowPublished = {\url{https://darkmail.info/downloads/dark-internet-mail-environment-march-2015.pdf}},
Month = {03},
Year = {2015},
Note = {[Online; geprüft 14.03.16]},
Owner = {},
Timestamp = {2016.02.12},
Urldate = {2016.02.12},
}
@misc{libdime,
Title = {The DIME resolver library and command line utilities},
Author = {Dark Mail Alliance},
HowPublished = {\url{https://github.com/lavabit/libdime}},
Month = {02},
Year = {2016},
Note = {[Online; geprüft 14.03.16]},
Owner = {},
Timestamp = {2016.02.12},
Urldate = {2016.02.12},
}
@techreport{bitmessage,
address = {New York, NY, USA},
author = {Warren, Jonathan},
day = {27},
institution = {Bitmessage},
keywords = {authentication, bitmessage, cryptography, email, p2p, privacy, security},
month = nov,
posted-at = {2013-06-26 07:42:26},
title = {Bitmessage: A {Peer-to-Peer} Message Authentication and Delivery System},
url = {http://bitmessage.org/bitmessage.pdf},
year = {2012}
}
@techreport{bitcoin,
abstract = {A purely peer-to-peer version of electronic cash would allow online
payments to be sent directly from one party to another without going through a
financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending.
We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of {CPU} power. As long as a majority of {CPU} power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort
basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.},
author = {Nakamoto, Satoshi},
citeulike-article-id = {8496220},
citeulike-linkout-0 = {http://fastbull.dl.sourceforge.net/project/bitcoin/Design\%20Paper/bitcoin.pdf/bitcoin.pdf},
keywords = {bitcoin, cryptographic\_protocols, cryptography, electronic\_cash\_system, electronic\_commerce, hashcash, peer\_to\_peer\_network, proof\_of\_work},
posted-at = {2011-01-01 14:24:54},
priority = {0},
title = {Bitcoin: A {Peer-to-Peer} Electronic Cash System},
url = {https://bitcoin.org/bitcoin.pdf},
institution = {Bitcoin},
year = {2009}
}
@TechReport{Berjon:14:H,
author = "Robin Berjon and Steve Faulkner and Travis Leithead and Silvia Pfeiffer and Edward O'Connor and Erika Doyle Navara",
title = "{HTML5}",
month = jul,
note = "http://www.w3.org/TR/2014/CR-html5-20140731/",
year = "2014",
bibsource = "http://w2.syronex.com/jmr/w3c-biblio",
type = "Candidate Recommendation",
institution = "W3C",
}
@book{Ferguson:2003:PC:862106,
author = {Ferguson, Niels and Schneier, Bruce},
title = {Practical Cryptography},
year = {2003},
isbn = {0471223573},
edition = {1},
publisher = {John Wiley \& Sons, Inc.},
address = {New York, NY, USA},
}

21
Bachelorthesis/Content/Abstract.tex Executable file
View File

@ -0,0 +1,21 @@
\begin{abstract}
\thispagestyle{empty}
Im Angesicht globaler Überwachung durch Regierungen, %toref
schwer kontrollierbarer Sammlung und Speicherung von Benutzer-Daten durch Anbieter von Internetdiensten %toref
und fehlender Aufklärung über Konsequenzen internetbasierter Kommunikation soll diese Arbeit sowohl einen Überblick über aktuelle Probleme von E-Mail-Kommunikation, die die Privatsphäre des Benutzers betreffen, als auch eine Untersuchung möglicher Lösungen leisten.
Die Vielzahl möglicher Kommunikationsmittel im Internet erlaubt uns nicht, dieses Thema abstrakt zu behandeln. Oft unterscheiden sich diese fundamental: in der Art der Benutzung, dem verwendeten Protokoll, den zugrunde liegenden kryptografischen Algorithmen, den aktuellen Implementierungen und inhärenten Problemen.
Deshalb konzentriert sich diese Arbeit auf eines der ältesten digitalen Nachrichten- Übertragungsverfahren, welches schon im Arpanet %toref
erste Anwendung fand: die E-Mail. Dabei wird die E-Mail sowohl als Technologie aber auch als Kommunikationsform betrachtet und ihre Bedeutung aufgezeigt.
Der Überblick über aktuelle Probleme wird alle Aspekte behandeln, die relevant für die Privatsphäre des Benutzers sind. Dies beinhaltet konkrete Daten der Kommunikation wie Inhalt, aber auch Metadaten. %toexp: Meta-Daten
Bei der Betrachtung möglicher Lösungen werden zunächst bereits existierende aufgeführt, seien sie experimentell, schon implementiert oder nur konzeptionell. Nachfolgend wird ein alternativer Vorschlag inklusive Konzeption, rudimentärer Protokollbeschreibung, beinhaltender Algorithmen und Proof of Concept Implementierung der wissenschaftlichen Gemeinschaft zur Falsifikation unterbreitet.
Dieses Konzept soll als Idee, weniger als vollständige Lösung angesehen werden. Viele daraus folgende Probleme werden nicht ausreichend gelöst werden können. Diese werden jedoch nachfolgend untersucht und Vorschläge zur Weiterentwicklung unterbreitet.
Abschließend wird diskutiert, ob das vorgeschlagene Konzept ausreichend Potenzial hat, um bei entsprechender Weiterentwicklung eine angemessene Lösung sein zu können.
\end{abstract}

5
Bachelorthesis/Content/AlternativeLoesungen.tex Normal file
View File

@ -0,0 +1,5 @@
Zur Lösung der Datenschutzprobleme auf SMTP-Ebene existieren wenig wissenschaftliche Arbeiten. Eine etwas theoretische Arbeit ist \QuoteM{Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms} \RefIt{Chaum:1981:UEM:358549.358563}, welche allerdings nicht auf konkrete E-Mail Protokolle eingeht, da sie auch ca. 1 Jahr vor dem ersten SMTP Standard \RefIt{rfc821} veröffentlicht wurde.
Allerdings existieren alternative E-Mail Systeme, die das Problem des Datenschutzes auf ihre eigene Weise lösen ohne an SMTP gebunden zu sein. Dazu gehören beispielsweise Dark Mail \RefIt{Chaum:1981:UEM:358549.358563}, aber auch Bitmessage \RefIt{bitmessage}, welches auf der Bitcoin \RefIt{bitcoin} Technologie basiert.
Nachfolgend wird Dark Mail kurz besprochen.

1
Bachelorthesis/Content/AlternativeLoesungen/Bewertung.tex Normal file
View File

@ -0,0 +1 @@
Alternative Lösungen wie Dark Mail \RefIt{Chaum:1981:UEM:358549.358563} oder Bitmessage \RefIt{bitmessage} sind zum Teil sehr elegant und durchdacht, entfernen sich aber deutlich von den weitverbreiteten Protokollen wie SMTP oder IMAP. Dies mag zwar notwendig sein, um diverse Spezifikationsfehler in den genannten Protokollen zu überwinden, ist aber gleichzeitig auch ein Problem. Denn die neuen vorgeschlagenen Protokolle müssen mit den bestehenden Protokollen konkurrieren, da sie mit diesen inkompatibel sind. Ob diese Ideen genügend Penetrationspotenzial haben, um von der Internetgemeinde angenommen zu werden, bleibt fraglich.

3
Bachelorthesis/Content/AlternativeLoesungen/DarkMail.tex Normal file
View File

@ -0,0 +1,3 @@
Als sehr genau spezifizierte Alternative zur E-Mail muss Dark Mail, bzw. \QuoteM{Dark Internet Mail Environment} \RefIt{darkmail} genannt werden. Dark Mail verwirft jegliche bekannten Protokolle wie SMTP und entwickelt ein gänzlich neues E-Mail Konzept mit den Protokollen \QuoteDirect{Dark Mail Transfer Protocol}{darkmail}{S. 82-87} und \QuoteDirect{Dark Mail Access Protocol}{darkmail}{S. 108}. Ebenso kommt ein eigenes Datenformat namens \QuoteDirect{D/MIME}{darkmail}{S. 68-81} zum Einsatz.
Auf die genauen Einzelheiten kann hier nicht eingegangen werden, da Dark Mail sehr komplex ist. Wichtig zu bemerken ist allerdings, dass es eine dem Onion Routing \RefIt{onionrouting1} \RefIt{onionrouting2} ähnliche Methodik benutzt. Ebenso kommt verschachtelte Verschlüsselung und ein durchdachtes Schlüsselsystem zum Einsatz. Allerdings ist Dark Mail auf Implementierungsebene noch nicht fertig und es existiert zum derzeitigen Zeitpunkt kein Release \RefIt{libdime}.

0
Bachelorthesis/Content/Entwicklung.tex Normal file
View File

8
Bachelorthesis/Content/Entwicklung/IdeaConcept.tex Normal file
View File

@ -0,0 +1,8 @@
Zur Lösung der Anforderungen in \autoref{tab:FunctionalRequirements} wird nachfolgend ein Algorithmus diskutiert und vorgestellt, der die Verbindung zwischen MTAs auf SMTP-Ebene anonymisieren soll, sodass Sender und Empfänger einer E-Mail nicht durch Verfolgung von IP-Adressdaten nachvollzogen werden können.
Bei der Überlegung eines solchen Algorithmus spielt vor allem \autoref{text:NFA1} eine Rolle. Alternative E-Mail Systeme mit einem Schwerpunkt auf Datensicherheit wurden bereits in Kapitel 3 vorgestellt. Im Zuge dieser Arbeit wird allerdings versucht, der Akzeptanz halber eine SMTP-basierte Lösung zu entwickeln. Dies soll, mit minimalem Aufwand für E-Mail Server Betreiber und Nutzer, eine Verbesserung der Datensicherheit ermöglichen.
Bei der Wahl und Entwicklung des Algorithmus wurde vor allem Wert darauf gelegt, dass keine spezifischen SMTP Erweiterungen notwendig sind. Somit soll dieser auf dem Minimum des IMF und SMTP Protokolls fußen.
Die Anonymisierung soll über zufälliges Routing realisiert werden, welches kryptografisch gestützt wird. Alle Informationen zum Routing sollen in der E-Mail kodiert sein. Jeder Knoten soll zu jedem Zeitpunkt nur den Nachfolger und Vorgänger kennen. Die originale E-Mail darf nicht modifiziert werden, was bedeutet, dass ein Verschachtelungsverfahren angewendet werden muss.

2329
Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.dia Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 32 KiB

124
Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.tex Normal file
View File

@ -0,0 +1,124 @@
Der Algorithmus wird nachfolgend \QuoteM{MystMail Algorithmus} genannt und ist vom Grundprinzip dem Onion Routing \RefIt{onionrouting2} nicht unähnlich.
Der Algorithmus bezieht sich allerdings nicht nur auf MTAs, sondern muss auch auf der Ebene der Kommunikation zwischen MUA und MSA eingreifen.
In ihrer Funktionsweise ist die MystMail eine gewöhnliche E-Mail, die eine Art Liste von Relay Servern beinhaltet. Die E-Mail wird also nicht direkt an den schlussendlichen Empfänger gesendet, sondern über mehrere Relay Server (auch \QuoteM{Hops} genannt) geleitet, basierend auf den kodierten Informationen in der E-Mail. Dies ist der Anonymisierungspfad. Damit dieser Pfad selbst weder für die Hops noch für irgendjemand sonst sichtbar ist, muss er kryptografisch in die E-Mail eingebettet werden.
Die sogenannte Liste von Hops ist also keine Liste, die in Form von Klartext als Header festgesetzt wird. Stattdessen wird die originale E-Mail inklusive Header über ein asymmetrisches Verschlüsselungsverfahren mit dem öffentlichen Schlüssel des ersten Hops verschlüsselt und fungiert jetzt als Body einer neuen E-Mail, die an denselben Hop gerichtet ist, gewissermaßen die erste MystMail. Für den nächsten Hop wird das Verfahren mit der soeben neu erstellten MystMail wiederholt. Dies kann theoretisch beliebig oft wiederholt werden und hat zur Folge, dass eine verschachtelte Verschlüsselung vorliegt, jede Schicht mit einem anderen öffentlichen Schlüssel verschlüsselt. Dies bedeutet wiederum, dass kein Hop in der Mitte des Pfades an die übernächste MystMail gelangen kann, da er nicht den privaten Schlüssel dafür besitzt. Somit kennt jeder Hop nur Vor -und Nachfolgehop.
Ist nun die schlussendliche MystMail mit der impliziten Liste von Hops vollständig durch den MUA erstellt, wird sie an den ersten Hop gesendet. Dieser entschlüsselt den Body mit seinem privaten Schlüssel und erhält die nächste MystMail mit Informationen zum nächsten Hop im \verb#To:# Headerfeld. Diese MystMail versendet er über SMTP nun an den nächsten Hop, welcher die nächste MystMail entschlüsselt, usw. Die MystMail hat jedoch ein dediziertes Headerfeld \verb#X-Myst-Mail: 1#, der SMTP-kompatibel markiert, dass diese E-Mail eine spezielle E-Mail ist. Durch den ganzen Pfad ist dieses Headerfeld aktiv. Gelangt die E-Mail an den schlussendlichen Empfänger, so entschlüsselt dieser den Body der E-Mail ohne bereits zu wissen, dass er der Empfänger ist. Erst nachdem der MTA keinen \verb#X-Myst-Mail: 1# findet, weiß er, dass er der schlussendliche Empfänger ist und kann die entschlüsselte E-Mail lokal über den MDA zustellen.
Dieser Algorithmus wird auf MTA-Ebene durch das \verb#X-Myst-Mail: 1# Headerfeld ausgelöst. Ist dieses nicht Bestandteil des Headers, so wird die E-Mail nach den gewöhnlichen Regeln des MTAs zugestellt oder weitergeleitet. Die Art und Weise, wie dieser Algorithmus auf MUA Ebene ausgelöst wird, ist nicht spezifiziert.
Sowohl der Verschlüsselungsalgorithmus für die verschachtelten E-Mails als auch der Zufallsalgorithmus zur Auswahl der Hops wird hier nicht spezifiziert.
In chronologischen Schritten kann der Algorithmus folgendermaßen dargestellt werden:\\
\begin{minipage}{\linewidth}
\begin{mail}{MystMail-Algorithmus Simulation}{MystMail-Algorithmus}
MUA (Sender): empfängt Liste von Hops von einem zentralen
Server
MUA (Sender): wählt aus der Liste einen zufälligen Pfad aus
MUA (Sender): erstellt die initiale verschachtelte MystMail
für den ersten Hop
MUA (Sender): reicht die MystMail an seinen MSA ein
MSA (Sender): nimmt MystMail entgegen
MTA (Sender): sendet die MystMail an den ersten Hop
MTA (1. hop): nimmt die MystMail entgegen
MTA (1. hop): erkennt den "X-Myst-Mail: 1" Header
MTA (1. hop): entschlüsselt den Body der E-Mail mit seinem
öffentlichen Schlüssel
MTA (1. hop): erkennt, dass auch dort ein "X-Myst-Mail: 1"
Header vorliegt
MTA (1. hop): benutzt den entschlüsselten Text als neue E-Mail
und sendet die MystMail an die Adresse aus dem
"To:" Headerfeld, den 2. Hop
MTA (2. hop): nimmt die MystMail entgegen
[...] (wie 1. hop)
MTA (3. hop): nimmt die MystMail entgegen
[...] (wie 1. hop)
MTA (Empfänger): nimmt die MystMail entgegen
MTA (Empfänger): erkennt das "X-Myst-Mail: 1" Headerfeld
MTA (Empfänger): entschlüsselt den Body der E-Mail mit seinem
öffentlichen Schlüssel
MTA (Empfänger): erkennt, dass im entschlüsselten Text kein
"X-Myst-Mail: 1" Headerfeld vorliegt
MTA (Empfänger): leitet die E-Mail an den MDA weiter
MDA (Empfänger): stellt lokal zu
MUA (Empfänger): ruft E-Mail vom POP3/IMAP Server ab
und sieht die original E-Mail
mit dem korrekten "From:" Feld vom Empfänger
\end{mail}
\end{minipage}
Auf Basis des MTA ist also eine Entscheidung notwendig, abhängig vom \verb#X-Myst-Mail# Headerfeld. Diese Entscheidung kann folgendermaßen dargestellt werden:\\
\\
\begin{minipage}{\linewidth}
\begin{mail}{MystMail MTA Entscheider}{mtadecider}
// either relays a MystMail or delivers the inputmail in case
// it is not a MystMail
function processMail (inputmail) {
header = inputmail.header;
body = inputmail.body;
if header.getField("X-Myst-Mail").notNull()
newMystMail = decrypt(body);
envelope = createEnvelope(newMystMail);
send(newEnvelope);
else
deliverToMDA(inputmail);
}
// creates the Envelope that carries Meta-Data for the
// SMTP transaction, such as "RCPT TO" and "MAIL FROM"
function createEnvelope(inputmail) -> Envelope {
from = inputmail.header.getField("From");
to = inputmail.header.getField("To");
return new Envelope(mail = inputmail
, RCTP = [to]
, MAILFROM = from);
}
\end{mail}
\end{minipage}
Für den MUA liegt folgendes Verhalten vor:\\
\begin{minipage}{\linewidth}
\begin{mail}{MystMail-Erstellung (MUA)}{mysterstellung}
// creates the initial MystMail
function createMystMail(inputmail) -> EMail {
hops = getHopList();
path = chooseHopPath(hops) ++ inputmail.recipient;
newmail = inputmail;
for hop in path {Alle Informationen zum routing sollen in der E-Mail kodiert sein.
if (hop == path[0])
from = "myst@" ++ inputmail.sender.address.domain;
else
from = hop.prev.address;
to = "myst@" ++ hop.domain;
body = encrypt(hop, newmail);
newmail = EMail(From = from
, To = to
).addHeader("X-Myst-Mail: 1");
}
return newmail;
}
\end{mail}
\end{minipage}
\autoref{fig:algorithmus} zeigt schematisch den Ablauf des Algorithmus. Die initiale E-Mail ist 4-fach verschachtelt verschlüsselt und geht über 3 Hops. Jeder Hop entschlüsselt den Body der eingegangenen E-Mail, benutzt diesen entschlüsselten Text als vollständige IMF-kompatible E-Mail inklusive Header und Body und leitet diese dann an den nächsten Hop weiter. Der Empfänger MTA erkennt, dass kein \verb#X-Myst-Mail# Headerfeld vorliegt und reicht die unveränderte originale E-Mail an den MDA weiter. Die farbig markierten Pfeile zeigen an, welcher Teil der MystMail gerade weitergesendet wird.
Anzumerken ist hierbei, dass abgesehen von der originalen E-Mail alle Header das \verb#From# und \verb#To# Feld verschleiern, indem der Benutzername \verb#myst# verwendet wird. Technisch gesehen ist es unerheblich, wie der Benutzername definiert ist, da dies das Verhalten des MystMail MTAs nicht verändert.
\begin{figure}[htb]
%\Centerfloat
\centering
\includegraphics[scale=0.5]{Content/Entwicklung/IdeaConcept/Algorithmus.png}
\caption{Übersicht MystMail Algorithmus}
\label{fig:algorithmus}
\end{figure}
\vfill
\clearpage

15
Bachelorthesis/Content/Entwicklung/Methoden.tex Normal file
View File

@ -0,0 +1,15 @@
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.

5
Bachelorthesis/Content/Entwicklung/Realisierung.tex Normal file
View File

@ -0,0 +1,5 @@
Die Realisierung auf Basis des Prototyping Modells durchläuft mehrere Phasen. Zunächst wird ein Testsystem entwickelt, das auf Docker \RefIt{dockerhp} basiert. Dieses Testsystem wird es erlauben, mehrere MTAs miteinander isoliert kommunizieren zu lassen. Dafür muss ebenso eine SMTP Implementierung gewählt werden. Nach der Entwicklung des Testsystems wird der Einsprungpunkt gesucht, an dem der Algorithmus in das bestehende SMTP Protokoll injiziert werden kann. Ist dieser gefunden, wird zunächst der MystMail MTA Entscheider (Code \ref{mtadecider}) implementiert. Dieser wird noch nicht die Logik für das Erstellen der weiterzuleitenden MystMail beinhalten oder das Weiterleiten selbst, sondern lediglich die Entscheidungslogik testen. Danach kann überprüft werden, ob das SMTP Protokoll immer noch einwandfrei funktioniert und beim Erkennen einer MystMail der entsprechende Entscheidungszweig erreicht wird. Ist die Korrektheit hier verifiziert, wird der Teil des MystMail MTA Entscheiders implementiert, der die Nachricht, zunächst noch unverändert, an einen vordefinierten MTA weiterleitet. Somit wird das Weiterleiten zwischen den MTAs getestet. Ist das Weiterleiten möglich, so wird die eigentliche Logik zum Entpacken einer MystMail implementiert, inklusive dem Interpretieren des Bodies und dem Erstellen eines Envelope. Nach diesem Schritt wird eine statische initiale MystMail per Hand erstellt und das Entpacken sowie die Weiterleitung zwischen den MTAs getestet. Als letzter Schritt wird die MystMail-Erstellung (Code \ref{mysterstellung}) als SMTP-Gateway implementiert, nicht als MUA Erweiterung. Dies geschieht aus Gründen der Einfachheit.
Nachfolgend werden die einzelnen Phasen der Entwicklung beschrieben, Entscheidungen erklärt und Probleme erläutert.
\label{section:realisierung}

1
Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung.tex Normal file
View File

@ -0,0 +1 @@
Für die Implementierung wurden zunächst verschiedene SMTP-Softwarelösungen betrachtet und eine adäquate ausgewählt. Nachfolgend werden systematisch, wie in Kapitel~\ref{section:realisierung} erklärt, die einzelnen Implementierungsschritte durchlaufen.

15
Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Einsprungpunkt.tex Normal file
View File

@ -0,0 +1,15 @@
Für die Wahl des Einsprungpunktes kamen mehrere Ansätze in die nähere Auswahl.
Der erste Ansatz war die E-Mails kurz bevor sie die Queue erreichen, im Hook \verb#queue# abzufangen und die E-Mail manuell weiterzuleiten, beispielsweise indem über \verb#outbound.send_email(...)# eine neue E-Mail erstellt und versendet wird. Das Problem hierbei ist allerdings, dass der \verb#queue# Hook speziell ist und man diesen nur vollständig überschreiben kann, nicht aber nur zusätzliche Logik einführen kann. Dies erhöht den Implementierungsaufwand.
Eine weitere Möglichkeit wäre gewesen, an mehreren Stellen anzusetzen, beispielsweise bei den Hooks \verb#mail# und \verb#rcpt#, und für jede Station Informationen zu sammeln, diese dann im \verb#connection.results# Objekt zu speichern und dann zu einem späteren Zeitpunkt eine neue E-Mail zu versenden oder die bestehende zu manipulieren. Da dies allerdings erhöhter Aufwand ist und einen globalen Zustand beinhaltet, wurde diese Idee verworfen.
Der letzte Ansatz war, im Hook \verb#data_post# anzusetzen, direkt nachdem die E-Mail Daten eingegangen sind, also das SMTP Kommando \verb#DATA# abgeschlossen ist. Dies hat mehrere Vorteile. Zum einen kann dieser Hook durch andere Plugins normal weiterverarbeitet werden und zum anderen erlaubt er an dieser Stelle das Transaktionsobjekt, welches gerade erstellt wurde, ohne viel Seiteneffekte direkt zu manipulieren. Ebenso ist dies eine zentrale Stelle, an der noch relativ wenig Plugin-Logik ausgeführt worden ist, sodass kein kompliziertes Speichern von Zwischendaten erforderlich ist.
Somit fiel die Wahl auf den letzten Ansatz und hatte folgende Implikationen:
\begin{itemize}
\item Einsprungpunkt nachdem das SMTP Kommando \verb#DATA# vollständig ausgeführt wurde (nach dem E-Mail Text)
\item keine Zwischenzustände nötig
\item erlaubt das Weiterverarbeiten durch andere Plugins
\item direktes Modifizieren des Transaktionsobjektes: E-Mail und andere Meta-Daten werden direkt manipuliert
\end{itemize}

33
Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Haraka.tex Normal file
View File

@ -0,0 +1,33 @@
Wie bereits erwähnt, basiert Haraka auf einem explizit entwickelten Plugin-System. Weite Teile der Kernfunktionalität von Haraka sind über das Plugin-System selbst implementiert und werden als Standard-Plugins mitgeliefert. Diese können dann über diverse Konfigurationsdateien im Ordner \verb#config# direkt gesteuert werden. Ebenso kann definiert werden, welche Plugins überhaupt ausgeführt werden und in welcher Reihenfolge. Dies ist der Kern der Haraka-Konfiguration und befindet sich in der Datei \verb#config/plugins# im Basisordner.
Interessante hooks, die für die Implementierung von Bedeutung sind oder sein können, sind die folgenden:
\begin{itemize}
\item \verb#connect_init#: wird beim Start einer Verbindung aufgerufen
\item \verb|lookup_rdns|: liefert den reverse DNS
\item \verb#connect#: wird nach \verb|lookup_rdns| aufgerufen
\item \verb#mail#: hier können die Absender examiniert werden
\item \verb#rcpt#: hier können die Rezipienten examiniert werden
\item \verb#data#: wird beim \verb#DATA# SMTP Kommando aufgerufen
\item \verb#data_post#: wird am Ende des \verb#DATA# Kommandos aufgerufen, wenn der Client mit einem Punkt in einer Zeile signalisiert, dass die E-Mail Daten vollständig sind und der Server antworten kann
\item \verb#queue#: bevor die Mail in die Queue gelangt
\item \verb#get_mx#: wird beim Versenden aufgerufen, um den MX Record des empfangenden MTAs festzustellen
\end{itemize}
Das Plugin-Konzept sieht vor, dass mehrere Plugins denselben Hook verwenden können. Dafür muss am Ende der Funktion ein entsprechender Return Code zurückgegeben werden.
Um ein Open Relay zu definieren, kann man beispielsweise beim \verb#rcpt# Hook ansetzen, und ,abhängig von diversen Regeln, eine Weiterleitung erlauben oder nicht:
\begin{JavaScript}{Haraka Relay}{hrelay}
/**
* This relays the mssage if is_valid_rcpt(recipient) returns true
*/
exports.hook_rcpt = function(next, connection, params) {
// check if the recipient is valid (e.g. in a list)
if (is_valid_rcpt(params[0]) == true) {
connection.relaying = true;
}
return next(OK); // no further plugins on this hook will run
}
\end{JavaScript}
Wie hier zu sehen ist, existieren in Haraka einige grundsätzliche Objekte, die etwaige Informationen tragen. Auf der äußersten API Schicht befindet sich das \QuoteM{Connection Object} (\verb#connection# auf Code-Ebene). Dies wird für jede Verbindung, die Haraka mit einem anderen MTA eingeht erstellt und hat eine eindeutige UUID. Es trägt allgemeine Informationen über den Remote Server. Ebenso stellt es allerdings die Verbindung zur nächsten API-Schicht her, der Transaktion. \verb#connection.transaction# ist ein Objekt, das die gerade ablaufende Transaktion beschreibt. Es ist erst valide, nachdem \verb#MAIL FROM# gesendet wurde und wird beim Erreichen der Mail-Queue vernichtet wenn \verb#RSET# gesendet wird oder wenn \verb#MAIL FROM# nicht akzeptiert wurde. Innerhalb des Transaktions-Objekts sind weitere Objekte gekapselt, die die Informationen über den eigentlichen Vorgang enthalten. Das Transaktions-Objekt ist im Grunde der Umschlag der E-Mail. Es enthält die SMTP Informationen über Empfänger in \verb#transaction.rcpt_to# und Sender in \verb#transaction.mail_from#, ebenso wie die E-Mail selbst über die Objekte \verb#transaction.header# (alle Headerfelder) und \verb#transaction.body# (Text der E-Mail). Hierüber ist es möglich, an alle Informationen während einer SMTP-Sitzung zu gelangen, diese zu manipulieren oder abhängig von den Daten (z.B. Existenz von Headerfeldern) weitere Logik ausführen zu lassen. Weiterhin existiert ein ein \QuoteM{Outbound Modul}, welches über das Objekt \verb#outobund# ansprechbar ist. Über dieses Objekt ist es möglich, explizit E-Mails zu verschicken, beispielsweise wenn ein Plugin während der Verarbeitung selbst eine neue E-Mail schicken möchte.
Als letztes interessantes Objekt existiert im Connection Objekt das Objekt \verb#connection.results#, welches dazu benutzt werden kann Zustände und Informationen zu speichern, die dann über mehrere Plugins hinaus abrufbar sind (z.B. logs).

30
Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Konfiguration.tex Normal file
View File

@ -0,0 +1,30 @@
Nun müssen die Implementierungen noch adäquat in das Plugin-System integriert werden. Haraka Plugins werden erst ausgeführt, wenn sie in der Konfigurationsdatei \verb#config/plugins# in der korrekten Reihenfolge aufgelistet sind. Ebenso müssen einige weitere Anpassungen gemacht werden, damit ein Testlauf möglich wird. Beispielsweise muss der \verb#get_mx# Hook überschrieben werden, da hier nur lokale Systeme ohne MX-Record vorliegen. Die Implementierung ist ebenso im Anhang einsehbar. % toref
Die Konfigurationsdatei für die Hops ist folgendermaßen definiert:
\begin{mail}{Hop-Konfiguration}{hopconfig}
my_mx
access
dnsbl
helo.checks
open_relay
data.headers
enable_parse_body
my_transaction
max_unrecognized_commands
\end{mail}
Die Konfigurationsdatei für das SMTP-Gateway ist folgendermaßen definiert:
\begin{mail}{MSA-Konfiguration}{msaconfig}
my_mx
access
dnsbl
helo.checks
mail_from.is_resolvable
open_relay
data.headers
enable_parse_body
create_myst_mail
max_unrecognized_commands
\end{mail}
Der Hauptunterschied liegt lediglich in Zeile 8 und Zeile 9, welche die Plugins beschreiben, die über \verb#data_post# das Transaktions-Objekt verändern.

50
Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/MTA-Entscheider.tex Normal file
View File

@ -0,0 +1,50 @@
Nachfolgend wird der Hauptteil des Implementierungscodes aufgezeigt, allerdings ohne die Hilfsfunktionen. Dies soll eine Übersicht über den Haraka-spezifischen Algorithmus für den MTA-Entscheider geben.
\begin{minipage}{\linewidth}
\begin{JavaScript}{Haraka MTA-Entscheider}{hentscheider}
exports.hook_data_post = function(next, connection) {
// if we have a myst mail, we need to inject our Protocol
if (is_myst_mail(connection.transaction.header)) {
// we decrypt the mail body and treat it as raw
// mail data
var decrypted_email = myst_decrypt(connection.
transaction.body.bodytext);
// replace the current transaction object
var t = transform_transaction(decrypted_email,
connection);
connection.transaction = t;
// the unpacked mail is a myst mail too,
// relay it
if (is_myst_mail(connection.transaction.header)) {
connection.relaying = true;
}
}
// let the other handlers do what they want, we are
// finished injecting our logic, the rest is still
// SMTP compliant
next();
}
\end{JavaScript}
\end{minipage}
Die Funktionen \verb#myst_decrypt()# und \verb#transform_transaction()# können zunächst leere Funktionen sein. Wichtig ist hier lediglich die Funktion \verb#is_myst_mail()#, welche folgendermaßen definiert ist:
\begin{JavaScript}{Haraka Myst header checker}{hismystmail}
function is_myst_mail(header) {
if (header.get("X-Myst")) {
return true;
}
return false;
}
\end{JavaScript}
Damit ist der erste Teil des MTA-Entscheider bereits implementiert und die Logik für das Entpacken und Erstellen der neuen E-Mail kann implementiert werden.
Die Verschlüsselung und Entschlüsselung ist hier lediglich Base64. Die Funktion \verb#transform_transaction()# wird aufgrund ihrer Komplexität nur im Anhang gezeigt, % toref
da sie ebenso auf interner Haraka-API aufbaut.
Ebenso wichtig ist, anzumerken, dass \verb#connection.relaying = true;# im MTA-Entscheider bedeutet, dass der MTA für alle MystMails ein Open Relay ist. Deshalb kann und sollte ab Zeile 16 weitere Logik darüber entscheiden (z.B. eine Whitelist), ob die E-Mail weitergeleitet werden darf.

38
Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/SMTP-gateway.tex Normal file
View File

@ -0,0 +1,38 @@
Um die initiale MystMail zu erstellen, die die Informationen über die Hops verschlüsselt in sich trägt, wird diese der Einfachheit halber im MSA, also gewissermaßen einem SMTP-Gateway, generiert.
Die Liste der Hops ist statisch und vordefiniert für Testzwecke. Es liegt somit kein Zufallsalgorithmus vor. Die Verschlüsselung ist ebenso lediglich Pseudoverschlüsselung und kodiert gemäß Base64.
\begin{minipage}{\linewidth}
\begin{JavaScript}{Haraka Myst Erstellung}{hcreatemystmail}
function create_myst_mail(transaction) {
// recipient is always the last hop
var recipient = transaction.rcpt_to[0].host;
var hops = get_hops();
hops.push(recipient);
// innermost mail, untouched
var old_mail = get_raw_mail(transaction.body);
var i;
var new_mail = old_mail;
for (i = hops.length - 1; i >= 0; i--) {
if (i == 0) {
// first hop, "from" must be the actual sender
var sender = transaction.mail_from.host;
new_mail = create_mail_for_hop(sender, hops[i],
date, new_mail);
} else {
new_mail = create_mail_for_hop(hops[i-1],
hops[i], date, new_mail);
}
}
return new_mail;
}
\end{JavaScript}
\end{minipage}
Die Hilfsfunktionen lassen sich im Anhang einsehen. % toref
Nachdem die Mail erstellt ist, wird ähnlich wie beim MTA-Entscheider im Hook \verb#data_post# angesetzt und das Transaktions-Objekt manipuliert, um die dort enthaltene E-Mail mit der MystMail auszutauschen. Der entsprechende Code ist etwas kompliziert und ebenfalls im Anhang einsehbar.

24
Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Wahl.tex Normal file
View File

@ -0,0 +1,24 @@
Bei der Wahl der SMTP-Software waren mehrere Gesichtspunkte von besonderer Bedeutung:
\begin{itemize}
\item wird die Software tatsächlich eingesetzt?
\item wird die Software aktiv entwickelt und gepflegt?
\item in welcher Sprache ist die Software geschrieben?
\item ist die Software (ausreichend) dokumentiert?
\item wie kompliziert ist die Konfiguration?
\item wie einfach lässt sich die innere Logik verändern?
\end{itemize}
Diese Punkte sind wichtig, um eine mögliche Weiterentwicklung der Idee auf Basis derselben Implementierung einfacher zu machen, obwohl diese nur eine Proof-of-Concept Implementierung ist. Ebenso vereinfachen sie die Implementierung an sich und machen diese einfacher zu verstehen. Einige der Punkte sind auch relevant für Sicherheitsbedenken. Dies betrifft vor allem die Programmiersprache und die Komplexität der inneren Logik.
Zur näheren Auswahl kamen aufgrund der genannten Gesichtspunkte folgende SMTP-Softwarelösungen:
\begin{enumerate}
\item Sendmail \RefIt{sendmailhp}
\item OpenSMTPD \RefIt{opensmtpdhp}
\item Haraka \RefIt{harakahp}
\end{enumerate}
Sendmail kam in die nähere Auswahl, da es eine sehr alte Lösung ist, die extrem hohe Verbreitung hat. Ebenso ist der Code in weiten Teilen sehr gut dokumentiert. Allerdings ist die Konfigurationskomplexität äußerst hoch und der Code beinhaltet viel Indirektion, da der Code über die Zeit gewachsen ist. Sendmail ist in C geschrieben.
Als Alternative zu Sendmail fiel der Blick auf OpenSMTPD, dessen erstes stabiles Release aus dem ersten Quartal 2013 stammt \RefIt{opensmtpdrel}. Dies versprach eine bessere Strukturierung des Codes als Sendmail. Allerdings musste festgestellt werden, dass so gut wie keine Dokumentation auf Code-Ebene vorhanden ist. OpenSMTPD ist ebenfalls in C geschrieben. Aufgrund der mangelhaften Dokumentation schied dies also Option aus.
Als weitere Alternative wurde Haraka betrachtet. Haraka ist ein SMTP Server, welcher in Node.js geschrieben ist, also praktisch in Javascript. Dies öffnete einige Bedenken, da Javascript schwach und dynamisch typisiert ist und diverse Details des SMTP-Protokolls auf sehr exaktem Verhalten bezüglich der Bit-Länge gesendeter Nachrichten beruhen. Allerdings besitzt Haraka ein Plugin-System, welches auf Callbacks bzw. Hooks basiert, die es dem Programmierer erlauben, an unterschiedlichen Stellen in der Verarbeitung einer Transaktion anzusetzen und diese zu überschreiben oder lediglich zusätzliche Logik zu definieren. So ist es beispielsweise möglich, zu definieren was der Haraka Server nach einem empfangenen \verb#DATA# SMTP-Kommando tut, ohne bereits bestehenden Code verändern zu müssen. Ebenso ist die Dokumentation in weiten Teilen ausreichend, weshalb diese SMTP-Softwarelösung trotz der Bedenken über die Schwächen des Javascript-Typsystems als Basis der Implementierung ausgewählt wurde.

13
Bachelorthesis/Content/Entwicklung/Realisierung/Testsystem.tex Normal file
View File

@ -0,0 +1,13 @@
Für das Testsystem wird eine isolierte Umgebung benötigt, die ausreichend Kontrolle über Netzwerkdetails erlaubt und trotzdem möglichst frei von etwaigen Netzwerkproblemen ist. Würde hier echte Hardware eingesetzt werden, so käme das Problem hinzu, dass auf Hardware-Ebene Probleme und Fehler das System beeinträchtigen könnten. Eine manuelle lokale Konfiguration innerhalb eines Host-Systems, die das simulieren mehrerer MTAs erlaubt, ist aufgrund der Konfigurationskomplexität ebenso unerwünscht. Ebenso würde dies eine Abhängigkeit vom Host-System und dessen Konfiguration bedeuten. Aus diesem Grund wird eine Container-Software eingesetzt, die die entsprechenden Abstraktionsschichten bereits bereitstellt. Sie erlaubt mehrere gleichartige Prozesse isoliert laufen zu lassen und dieselben über eine definierte softwareseitige Netzwerkschnittstelle kommunizieren zu lassen. Für diese Art von Software existieren mehrere Lösungen. Für die Realisierung wird hier allerdings die Software \QuoteM{Docker} \RefIt{dockerhp} eingesetzt.
Docker ist keine Hardwarevirtualisierung. Es ist eine Abstraktionsschicht, die es erlaubt Prozesse in isolierten User-Spaces auf demselben Betriebssystemkernel laufen zu lassen. Dazu benutzt es Kernel Features wie Cgroups und Kernel Namespaces. Auf Dateisystem-Ebene wird UnionFS benutzt.
Die praktische Funktionsweise reduziert sich auf folgenden Ablauf: Der Benutzer erstellt eine Definitionsdatei mit dem Namen \QuoteM{Dockerfile}. Diese definiert gewissermaßen den Installationsprozess eines vollständigen Betriebssystems, der darin benötigten Applikationen, sowie die Art und Weise wie diese ausgeführt und konfiguriert werden. Auf Basis dieses Dockerfiles kann ein \QuoteM{Docker Image} erstellt werden. Ein Docker Image kann als Vorlage betrachtet werden, mit der eine Chroot-ähnliche Umgebung erstellt und ausgeführt werden kann. Diese ausgeführte Umgebung wird \QuoteM{Docker Container} genannt. Wichtig ist dabei, zu wissen, dass das Image aus mehreren UnionFS-Layern besteht (pro Dockerfile-Anweisung ein Layer). Wenn ein Container gestartet wird, so wird auf die Daten aus dem Image zugegriffen. Allerdings sind diese immer read-only. Sobald Änderungen an Dateien innerhalb eines Containers gemacht werden, wird die read-only Schicht des Images mit einer read-write Schicht des laufenden Containers zusammengeführt, ohne dass die Daten des Images sich dabei verändern. Somit können auf Basis eines beispielsweise gemeinsamen MySQL-Images mehrere MySQL-Instanzen gestartet werden, die alle dieselbe Version, dasselbe Betriebssystem und dieselbe Umgebung besitzen, aber dennoch voneinander isoliert sind, sowohl auf Prozess-, Netzwerk- und Dateisystem-Ebene. Beim Starten von Containern ist es allerdings möglich, diese miteinander zu verbinden, so dass sie auf Netzwerkebene miteinander kommunizieren können.
Mithilfe dieses Systems wird es möglich, mehrere gleiche MTAs zu starten und zu verbinden. Dabei können diese sich dennoch in der Konfiguration unterscheiden, da im laufenden Container Änderungen vorgenommen werden können. Ebenso ist es möglich, über Umgebungsvariablen oder Mountpoints, die vom Host in den Container zeigen, den Zustand und die Konfiguration eines Containers zu steuern. Ebenso sind die Container nahezu vollständig unabhängig vom laufenden Host-System, da ein Container bereits ein vollständiges Betriebssystem darstellt und lediglich mit dem Kernel des Host-Systems über den Docker Daemon kommuniziert wird.
Es werden gemäß \autoref{fig:algorithmus} also 5 E-Mail Container gestartet. Alle 3 Hops und der E-Mail Server des Empfängers haben dieselbe Konfiguration. Nur der E-Mail Server des Senders hat eine abweichende Konfiguration, da dieser als SMTP Gateway fungiert und anstelle des MUAs die initiale MystMail generiert. Alle Container werden in einem Netzwerk zusammengefasst und können untereinander kommunizieren.
Dieses System erlaubt es nun, fortlaufend Laufzeittests durchzuführen. Diese finden nicht automatisiert statt, sondern werden über die laufenden Prozesse in den Containern und deren Logdateien manuell durchgeführt.
Die Implementierung des Testsysems ist im Anhang einsehbar.

19
Bachelorthesis/Content/EvaluationValidation.tex Normal file
View File

@ -0,0 +1,19 @@
Das Testsystem wird gemäß des im Anhang befindlichen Handbuchs gestartet. Bei jedem Hop wird über die Konsole überwacht, welche Informationen eingehen. Ebenso werden temporär eingehende E-Mails in eine Datei geschrieben, um diese debuggen zu können.
Der Testlauf zeigt auf:
\begin{itemize}
\item die E-Mail erreicht den Empfänger Container
\item die eingegangene E-Mail am Empfänger Container stimmt mit der abgesendeten E-Mail überein
\item in jedem Hop ist nur die MystMail sichtbar, welche im Body in Base64 Kodierung die nächste MystMail beinhaltet
\end{itemize}
Da die Implementierung allerdings nur diverse Teile des Algorithmus implementiert, erfüllt sie auch nicht exakt die Anforderungen aus \autoref{tab:FunctionalRequirements}. Dinge, die erfolgreich implementiert wurden, sind:
\begin{itemize}
\item MystMail MTA Entscheider als Open Relay (basierend auf dem \verb#X-Myst-Mail# Headerfeld)
\item MystMail Erstellung auf SMTP-Gateway Ebene mit statischer Hopliste und Base64 Kodierung anstatt kryptografischer Verschlüsselung
\end{itemize}
Damit kann allerdings bereits nachgewiesen werden, dass der Algorithmus im Kern funktioniert und nur die Informationen an die Hops gelangen, die für diese sichtbar sein sollen. Auf IMF Ebene sind die Informationen durch die Kodierung im Body geschützt und auf IP-Ebene durch das zufällige Routing.
Es kann allerdings nicht nachgewiesen werden, dass eine in der Praxis nutzbare Implementierung möglich oder sinnvoll ist, da u.a. wesentliche Teile der funktionalen Anforderungen aus \autoref{tab:FunctionalRequirements} fehlen wie z.B. tatsächliche kryptografische Verschlüsselung oder ein Algorithmus der eine zufällige Route auswählt. Für einen Nachweis der praktischen Tauglichkeit müssten weitaus mehr Kriterien betrachtet werden und die Implementierung einen anderen Umfang haben. Auf Seite der nichtfunktionalen Anforderungen aus \autoref{tab:NonFunctionalRequirements} wurde zumindest NFA 1 eingehalten, obschon hier der Umstand ausgelassen wird, dass dennoch ein Ökosystem offener E-Mail Relay Server existieren muss, welche den hier beschriebenen Algorithmus beispielsweise als Plugin bereitstellen müssen. Eine MystMail kann nicht über gewöhnliche SMTP Server weitergeleitet werden, da für die Weiterleitung spezielles Wissen erforderlich ist.
Dennoch ist das Kernziel erreicht, indem das Weiterleiten und das Ver -und Entpacken von MystMails erfolgreich implementiert wurde.

25
Bachelorthesis/Content/Intro.tex Normal file
View File

@ -0,0 +1,25 @@
Dieses Kapitel soll eine Übersicht über die Bedeutung, Beschaffenheit und Funktionsweise der E-Mail geben, was sowohl Protokolle und Format als auch in der Praxis relevante Technologien betrifft. Ebenso beschreibt es das Zusammenwirken dieser Protokolle und das daraus entstehende Gesamtsystem, welches auch grob die in der Praxis aufzufindende Server-Struktur umreißt. Dies ist notwendig, um die Problematik praktischer Anonymisierung und Verschlüsselung nachfolgend darzulegen, welche sowohl technologischer als auch ökosystematischer Natur sind.
Die E-Mail ist eines der ältesten digitalen Nachrichten-Übertragungsverfahren und wurde bereits im Arpanet über Erweiterungen des FTP Protokolls \QuoteIndirectNoPage{rfc196} \QuoteIndirectNoPage{rfc822}
angewendet. So gesehen entstand sie über einen längeren Zeitraum und entwickelte sich über mehrere RFCs über die Jahrzehnte.
Streng genommen bezeichnet die E-Mail jede Form briefähnlicher Nachrichten, die auf elektronischem Wege übertragen werden.
Das am häufigsten benutzte E-Mail System
setzt sich aus mehreren Komponenten zusammen, welche sehr stark miteinander korrelieren.
Die Basis hierbei bildet das IMF vom RFC 5322 \RefIt{rfc5322},
welches nur die Form einer Nachricht spezifiziert. Darauf aufbauend wurde das SMTP Protokoll im RFC 5321 \RefIt{rfc5321}
entwickelt, welches den Transport von Nachrichten spezifiziert. Weiterhin existieren Protokolle, die die Verwaltung und den Zugriff auf E-Mails durch den Benutzer, nicht deren Transport zwischen Servern, beschreiben. Dazu zählen POP3 nach RFC 1939 \RefIt{rfc1939}
und IMAP nach RFC 3501 \RefIt{rfc3501},
die sich allerdings in ihrer Funktionalität teilweise stark unterscheiden.
Konzeptionell besteht die gängige E-Mail in erster Linie aus einem äußeren Envelope, welcher Meta-Daten für den Transport beinhaltet. In diesem befinden sich Header und Body. Der Header beinhaltet ebenfalls Metadaten und die eigentliche Nachricht wird als Body bezeichnet.
Dieses System bildet allerdings nur die minimale Basis heutiger internetbasierter E-Mail Kommunikation und wird in der Praxis durch eine Vielzahl von Technologien erweitert. Manche davon wurden speziell als Erweiterungen für E-Mail Protokolle entwickelt, andere werden lediglich systemkompatibel eingesetzt.
Um die Relevanz heutiger E-Mail Kommunikation zu verstehen, ist es hilfreich Statistiken über Anzahl von E-Mail Konten und E-Mail Datenverkehr zu betrachten. Eine Studie der Radicati Group \RefIt{erep}
im Jahr 2013 ergab, dass sich die Anzahl weltweiter E-Mail Konten auf ca. 3.9 Mrd. beläuft. Die Prognose für das Jahresende 2017 sah einen Anstieg auf ca. 4.9 Mrd. Konten vor, welches einer jährlichen Wachstumsrate von 6\% entspricht. Ca. 24\% aller E-Mail Konten sind dieser Studie zufolge geschäftliche E-Mail Konten.
Der Datenverkehr insgesamt belief sich im Jahr 2013 auf ca. 182 Mrd. gesendeter E-Mails pro Tag. Es wird erwartet, dass dieses Volumen für geschäftliche E-Mails ansteigt. Zu bemerken ist allerdings, dass eine Abnahme des Volumens von Privatanwendern erwartet wird. Dies könnte laut der Radicati Group
an dem Aufkommen neuer Kommunikationstechnologien wie Instant Messaging und sozialen Netzwerken liegen.
Dennoch zeigen diese Zahlen, dass E-Mail Kommunikation äußerst relevant ist und sich als Kommunikationsform etabliert hat. \QuoteIndirect{erep}{S. 3, 4}
Aufgrund der hohen Verbreitung von E-Mail Kommunikation müssen auch Lösungen zur Anonymisierung diskutiert werden, die möglicherweise nicht optimal, aber mittelfristig praktikabel und kompatibel mit dem bestehenden System sind.

96
Bachelorthesis/Content/Intro/Format.tex Normal file
View File

@ -0,0 +1,96 @@
Das im Kontext aktueller E-Mail Systeme benutzte E-Mail Format ist das \QuoteM{Internet Message Format}, kurz IMF.
Das IMF hat mehrere Versionen, angefangen beim RFC 822 \RefIt{rfc822},
welches noch den Titel \QuoteM{STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES} trägt und vom 13. August 1982 ist, bis hin zu RFC 2822 \RefIt{rfc2822},
welches bereits den Titel \QuoteM{Internet Message Format} trägt und vom April 2001 ist. Auf Basis dieser beiden RFCs wurde im Oktober 2008 der RFC 5322 \RefIt{rfc5322} veröffentlicht und ist damit die aktuellste Version zum Zeitpunkt dieser Arbeit. Das Ziel des RFC 5322 ist es eine Spezifikation für das Format von Text-Nachrichten, die zwischen Computer-Benutzern verschickt werden, bereitzustellen. Es ist im Kontext der E-Mail eingebettet und korreliert somit sehr eng mit dem SMTP Protokoll. Es beschreibt allerdings lediglich das Format der Nachrichten, nicht wie diese Nachrichten verschickt oder empfangen werden.
Das Format selbst setzt sich aus den Konzepten Header und Body zusammen. Der Header besteht aus mehreren Headerfeldern, welche jeweils einen Namen und einen Wert haben, die durch das Zeichen \verb-":"- getrennt werden. Die Headerfelder selbst werden durch einen Zeilenumbruch voneinander getrennt. Es gibt eine Reihe durch den RFC 5322 vordefinierter Headerfelder, die eine vorgegebene Bedeutung haben und von E-Mail Servern in bestimmter Weise verwertet werden. Dazu zählen vor allem folgende:
\begin{itemize}
\item \verb-From:- der Absender, beschrieben durch E-Mail Adresse, Name optional
\item \verb-To:- eine Liste von Empfängern, beschrieben durch E-Mail Adresse, Name optional
\item \verb-Date:- Zeitpunkt zu dem die Nachricht verfasst wurde, nicht Zeitpunkt des Transports
\item \verb-Subject:- Betreff der Nachricht
\item \verb#Message-ID:# eine von E-Mail Servern automatisch generierte ID wird intern benutzt, um mehrfache Zustellung zu verhindern
\item \verb#Received:# wird von E-Mail Servern, die nur weiterleiten, der Nachricht hinzugefügt, somit kann der Weg, den eine E-Mail nimmt, nachvollzogen werden
\end{itemize}
Die einzigen obligatorischen Headerfelder sind sind \verb-From:- und \verb-Date:-. Jeder Header, der diese Felder nicht besitzt, muss als nicht wohlgeformt zurückgewiesen werden. Weiterhin sind Headerfelder möglich, die nicht im RFC 5322 beschrieben sind. Diese können von E-Mail Servern ignoriert werden. Manche Headerfelder sind für E-Mail Clients gedacht oder werden zum Beispiel von Nachrichtenfiltern ausgewertet.
Dem Header folgt nach einer leeren Zeile der Body. Dieser besteht aus der eigentlichen Nachricht. Sowohl Header als auch Body sind auf 7-bit ASCII beschränkt.
Eine vollständige E-Mail gemäß IMF könnte z.B. so aussehen:
\\
\begin{minipage}{\linewidth}
\begin{mail}{E-Mail}{E-Mail}
From: Hans Bauer <hans@bauer.de>
To: Mina Meier <mina@meier.de>
Date: Tue, 8 Mar 2016 06:46:18 -0800
Subject: Beispiel-Mail
Message-ID: <18283.122131@bauer.de>
X-Mein-Header: True
Dies ist ein Beispieltext
über mehrere Zeilen.
\end{mail}
\end{minipage}
\\
Zeile 1 bis 6 stellen den vollständigen Header dar, getrennt durch die Leere Zeile 7. Der Body erstreckt sich über die Zeilen 8 bis 9.
Aufgrund der Beschränkungen dieses Systems auf 7-bit ASCII Zeichen und dem Fehlen von Inhalten, die nicht Text sind, wurde \QuoteM{Multipurpose Internet Mail Extensions}, kurz MIME, entwickelt. Es ist beschrieben in RFC 2045 \RefIt{rfc2045},
RFC 2046 \RefIt{rfc2046},
RFC 2047 \RefIt{rfc2047},
RFC 2049 \RefIt{rfc2049},
RFC 4288 \RefIt{rfc4288} und
RFC 4289 \RefIt{rfc4289}.
Die Integration dieses Systems in SMTP ist in RFC 1521 \RefIt{rfc1521}
und RFC 1522 \RefIt{rfc1522} beschrieben.
MIME erweitert den IMF Standard, indem es Zeichen erlaubt, die außerhalb des 7-bit ASCII Bereichs liegen, sowohl für den Body als auch für die Header. Weiterhin ermöglicht es Inhalte, die nicht Text sind, wie Programme, Audio-Dateien, Video-Dateien oder Bilder.
Anzumerken ist, dass MIME für unterschiedliche Protokolle verwendet wird, nicht nur für SMTP, sondern auch für beispielsweise HTTP \QuoteIndirect{Berjon:14:H}{Kapitel 4.7.10.3}.
Die Integration in den bestehenden IMF Standard erfolgt über neue dedizierte Headerfelder, die die nötigen Informationen beinhalten, um etwaige spezielle Headerfelder oder nicht-Text Teile des Bodies interpretieren zu können. Die relevanten Headerfelder lauten wie folgt:
\begin{itemize}
\item \verb#MIME-Version:# die Version des MIME Standards
\item \verb#Content-Type:# der Typ des Inhalts, z.b. \verb#text/plain#
\item \verb#Content-Disposition:# wurde in RFC 2183 \RefIt{rfc2183}
hinzugefügt und erlaubt das Angeben von sogenannten \QuoteM{Presentation Information}
\end{itemize}
Der MIME Standard erlaubt es aber vor allem sogenannte \QuoteM{MIME multipart messages} zu erstellen und zu interpretieren. Diese haben mehrere Bodies, die einzeln interpretiert werden. Getrennt werden diese durch das sogenannte \QuoteM{boundary}.
Eine E-Mail mit einem gewöhnlichen Datei-Anhang würde beispielsweise so aussehen:
\begin{minipage}{\linewidth}
\begin{mail}{MIME-Mail}{MIME-Mail}
From: Hans Bauer <hans@bauer.de>
To: Mina Meier <mina@meier.de>
Date: Tue, 8 Mar 2016 06:47:18 -0800
Subject: Beispiel-MIME-Mail
Message-ID: <18283.122131@bauer.de>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="------------080209010109060601000409"
This is a multi-part message in MIME format.
--------------080209010109060601000409
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Mit Anhang.
--------------080209010109060601000409
Content-Type: text/plain; charset=UTF-8;
name="Datei"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="Beispieldatei"
RGF0ZWlpbmhhbHQK
--------------080209010109060601000409--
\end{mail}
\end{minipage}
\\
Die ersten 8 Zeilen sind der E-mail Header, die 9. leere Zeile trennt Header und Body, welcher sich von Zeile 10 bis 25 erstreckt. Wichtig hierbei ist das Headerfeld \verb#Content-Type:# in Zeile 7, welches ankündigt, dass dies eine multipart MIME E-Mail ist. Ebenso gibt dieses Feld in Zeile 8 über \verb#boundary=# an, wo sich die einzelnen Teile im gesamten Body befinden. Dazu beinhalten die einzelnen Teile des Bodies erneut MIME Headerfelder, die eine korrekte Interpretation durch z.B. das E-Mail Programm vom Benutzer erlauben. So besitzt diese E-Mail einen gewöhnlichen Text-Anteil und einen Dateianhang, welcher Base64 verschlüsselt ist.
Dem Benutzer würde in diesem Fall im E-Mail Programm der Text \verb#Mit Anhang.# angezeigt werden und die Möglichkeit angeboten werden, die Datei mit dem Namen \verb#Beispieldatei# herunterzuladen.

43
Bachelorthesis/Content/Intro/Gesamtsystem.tex Normal file
View File

@ -0,0 +1,43 @@
Nachdem nun die Spezifikationen und Protokolle im einzelnen vorgestellt wurden, muss die E-Mail als Gesamtsystem betrachtet werden. Dazu wird nachfolgend untersucht, wie die Komponenten zusammengeführt werden, miteinander kommunizieren und wie eine Server-Konfiguration grob in der Praxis aussieht.
Auf der untersten Ebene befindet sich der \QuoteM{Mail User Agent}, kurz MUA. Er bezeichnet ein gewöhnliches E-Mail Programm, mit dem E-Mails gelesen, verfasst, empfangen und gesendet werden können. Beispiele hierfür sind Programme wie etwa \QuoteM{Mozilla Thunderbird}
oder \QuoteM{Outlook Express}.
Dies ist die Stelle, an der der Benutzer dem System Input gibt. Ein solches Programm muss in der Lage sein, mit allen Protokollen und Spezifikationen umzugehen. Für den Versand ist das beispielsweise IMF und SMTP, für das Empfangen und Manipulieren von E-Mails beispielsweise POP3 oder IMAP4.
Dies findet alles beim Benutzer statt, ist also clientseitig.
Auf der nächsten Ebene befindet sich der sogenannte E-Mail Server. Allerdings besteht dieser aus mehreren Komponenten. Mehrere E-Mail Server können sehr unterschiedliche Funktionalitäten bereitstellen, obwohl sie alle das SMTP Protokoll implementiert haben. Wenn der Benutzer über einen MUA eine E-Mail verschicken will, so sendet er diese an einen sogenannten \QuoteM{Mail Submission Agent} häufig an Port 587 \QuoteIndirect{rfc6409}{S. 6}, kurz MSA. Über diesen wird die initial erstellte E-Mail empfangen und gelangt so in den Zustellungsmechanismus.
Nachfolgend kann die E-Mail nun, abhängig vom Zustellungsmechanismus, über mehrere sogenannte \QuoteM{Mail Transfer Agents}, kurz MTA, weitergeleitet werden. Für jede Weiterleitung wird der E-Mail ein Headerfeld \verb#Received:# hinzugefügt, über welches der Weg, den die E-Mail über mehrere MTAs genommen hat, nachvollzogen werden kann. Der MTA ist die zentrale Einheit der E-Mail Zustellung, da er E-Mails versendet und empfängt.
Gelangt die E-Mail zum E-Mail Server des Empfängers, so wird der sogenannte \QuoteM{Mail Delivery Agent}, kurz MDA, aktiv. Dieser hat die Aufgabe, die E-Mail dem korrekten Benutzerkonto zuzuordnen, da ein E-Mail Server für gewöhnlich mehrere Benutzerkonten bereitstellt.
Auf der letzten Ebene befindet sich erneut ein MUA, und zwar in diesem Fall der des Empfängers, der nun über einen in seinem E-Mail Server integrierten POP3 oder IMAP4 Dienst die E-Mail abrufen kann.
Das bedeutet, dass ein E-Mail Server verschiedene Formen haben kann, z.B.:
\begin{itemize}
\item ein MTA, ein MSA, ein MDA und ein IMAP4 und POP3 Server, gewissermaßen als vollständige Lösung
\item nur ein MSA und MTA, der empfangene E-Mails an einen vordefinierten E-Mail Server weiterleitet, gewissermaßen als SMTP Gateway
\item nur ein MTA, z.B. als offenes oder internes Relay
\end{itemize}
\begin{figure}[htb]
%\Centerfloat
\centering
\includegraphics[scale=0.5]{Content/Intro/Protokolle/emailg.png}
\caption{E-Mail als Gesamtsystem}
\label{fig:emailg}
\end{figure}
\vfill
\clearpage
Die \autoref{fig:emailg} zeigt schematisch das Zusammenspiel der Komponenten:
Der ursprüngliche Absender erstellt über seinen MUA die E-Mail. Der MUA kontaktiert den MSA des \QuoteM{E-Mail Server 1} des Absenders, welcher im MUA hinterlegt ist. Der MTA des \QuoteM{E-Mail Server 1} muss jetzt entscheiden, was mit der E-Mail im nachfolgenden passiert. Eine Möglichkeit ist, dass die E-Mail direkt an den E-Mail Server des Empfängers gesendet wird (in \autoref{fig:emailg} als \QuoteM{Route 1} gekennzeichnet). Ebenso möglich ist aber auch, dass der Empfänger E-Mail Server ein MTA ist, der lediglich weiterleitet (in \autoref{fig:emailg} als \QuoteM{Route 2} gekennzeichnet). Die Regeln dazu werden in Routingtabelle und Zugriffsrichtlinien in den jeweiligen MTAs hinterlegt und können abhängig von einer Reihe von Informationen sein wie z.B. Empfängerdomain der E-Mail. Es kann notwendig sein, dass der weiterleitende MTA das Envelope der E-Mail manipuliert und z.B. den Empfänger anpasst. Wenn keine Regeln vorhanden sind, spricht man von einem \QuoteM{open relay}.
Erreicht die E-Mail den \QuoteM{E-Mail Server 3} des schlussendlichen Empfängers, so wird dieser feststellen, dass er der Empfänger ist und leitet die E-Mail an den MDA weiter, der sie dem korrekten Benutzerkonto zustellt. Dieses Benutzerkonto ist über einen IMAP4 Server vom MUA des Empfängers erreichbar.
Es ist nicht notwendig, dass E-Mail Server 1, 2 und 3 echte physische Instanzen sind. Es sind auch komplexere Konfigurationen möglich, bei denen die einzelnen Funktionalitäten über mehrere physische Instanzen verteilt sind.
Das Konzept eines E-Mail Servers, der nur die Funktionalität eines MTA bereitstellt, wird nachfolgend noch von hoher Relevanz sein.
Ein weiteres wichtiges Detail für die Zustellung und Weiterleitung von E-Mails ist der sogenannte MX Resource Record, erstmals beschrieben in RFC 947 \RefIt{rfc974}. Beim Versenden oder Weiterleiten von E-Mails fragt der sendende MTA zunächst den MX-Record der Empfängerdomain ab, welcher die tatsächliche FQDN des E-Mail Servers des Empfängers liefert. Erst zu diesem verbindet er sich dann.

5
Bachelorthesis/Content/Intro/Protokolle.tex Normal file
View File

@ -0,0 +1,5 @@
Dieses Unterkapitel behandelt die weitverbreiteten E-Mail Protokolle SMTP, POP3 und IMAP4, welche die Basis heutiger internetbasierter E-Mail Kommunikation bilden. Für diese Protokolle gibt es eine Vielzahl von Erweiterungen, die allerdings immer auf den bestehenden Protokollen aufbauen und diese selbst nicht verändern, damit die gemeinsame Schnittstelle nicht verloren geht.
Während das SMTP Protokoll die Kommunikation zwischen E-Mail Servern definiert, behandeln die Protokolle POP3 und IMAP4 die Verwaltung und den Zugriff auf E-Mails durch den Benutzer, nicht deren Transport zwischen Servern. Obwohl IMAP4 das modernere System ist,
verwenden viele Server noch POP3,
weshalb es hier der Vollständigkeit halber mit aufgeführt wird.

3063
Bachelorthesis/Content/Intro/Protokolle/IMAP4.dia Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
Bachelorthesis/Content/Intro/Protokolle/IMAP4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 52 KiB

59
Bachelorthesis/Content/Intro/Protokolle/IMAP4.tex Normal file
View File

@ -0,0 +1,59 @@
IMAP4 ist die Version 4 des \QuoteM{INTERNET MESSAGE ACCESS PROTOCOL} spezifiziert in RFC 3501 \RefIt{rfc3501}. Es ist ähnlich wie POP3 ein textbasiertes Client-Server Protokoll, das das Auflisten, Löschen und Manipulieren von E-Mails an einem E-Mail Server erlaubt, weit über die Möglichkeiten von POP3 hinaus \QuoteIndirect{rfc1939}{S. 2}.
Ein E-Mail Server kann sowohl POP3 als auch IMAP4 gleichzeitig anbieten. Im Gegensatz zu POP3 erlaubt IMAP4 allerdings nicht nur E-Mails herunterzuladen, zu löschen oder aufzulisten, sondern direkt auf der Mailbox des E-Mail Servers zu operieren, was Funktionalitäten wie neue Ordner anzulegen erlaubt \QuoteIndirect{rfc3501}{S. 34 f} oder das serverseitige Durchsuchen von Nachrichten \QuoteIndirect{rfc3501}{S. 49 ff}.
Informationen werden nach Bedarf direkt vom IMAP4 Server abgerufen und nicht einzeln heruntergeladen. Deshalb ist auch im Gegensatz zu POP3 eine lokale Speicherung von Daten nicht notwendig, welche auch dazu führen kann, dass die lokale Mailbox von der entfernten Mailbox divergiert. E-Mail Programme bieten jedoch unabhängig von POP3/IMAP4 die Möglichkeit der lokalen Speicherung an, was allerdings Protokoll-agnostisch ist. Bei IMAP4 ist anzumerken, dass bei fehlender Internetverbindung und keiner expliziten lokalen Speicherung auf Programmebene der Zugriff auf E-Mails auch nicht mehr möglich ist.
IMAP4 benötigt ein zuverlässiges Netzwerkprotokoll wie beispielsweise TCP und wird über den Port 143 abgewickelt \QuoteIndirect{rfc3501}{S. 6}. Ist die Verbindung über IMAPS TLS/SSL-verschlüsselt wird häufig Port 993 benutzt, obwohl in RFC 2595 \RefIt{rfc2595} STARTTLS über den Standardport 143 beworben wird.
Ebenso wie POP3 ist auch IMAP4 ein zustandsbehaftetes Protokoll. Allerdings ist IMAP4 weitaus komplexer und kann sich in 4 verschiedenen Zuständen befinden. Wenn die Verbindung vom Client zum Server initial erstellt wurde, befindet sich die Kommunikation im \QuoteDirect{Not Authenticated State}{rfc3501}{S. 13}. Es wird vom Client nun erwartet, sich zu authentifizieren. Findet eine erfolgreiche Authentifizierung statt, so wird der \QuoteDirect{Authenticated State}{rfc3501}{S. 13} erreicht. Nachfolgend muss der Client eine Mailbox auswählen, bevor er weitere Kommandos zur Manipulation oder Einsicht von E-Mails abgeben kann. Ebenso wird dieser Zustand erreicht, wenn es einen Fehler beim Auswählen einer Mailbox gab oder nach einem erfolgreichen \verb#CLOSE# Kommando \QuoteIndirect{rfc3501}{S. 13}. Wurde eine Mailbox erfolgreich ausgewählt, so erreicht die Verbindung den \QuoteDirect{Selected State}{rfc3501}{S. 13}. In diesem Zustand kann auf der Mailbox operiert werden wie z.B. Ordner anlegen, E-Mails abrufen etc. Der letzte Zustand ist der \QuoteDirect{Logout State}{rfc3501}{S. 14} und kann aus allen vorherigen Zuständen erreicht werden. Hier wird die Verbindung terminiert.
Eine vereinfachte Darstellung der Kommunikation in einem SDL Diagramm ist in \autoref{fig:imap4} zu sehen. Diese Abbildung zeigt bereits die Komplexität des Protokolls, ist aber nicht vollständig. Deshalb kann an dieser Stelle aufgrund der Vielzahl möglicher Kommandos keine vollständige Betrachtung vorgenommen werden. Stattdessen wird nachfolgend eine einfache IMAP4 Sitzung betrachtet:
\begin{minipage}{\linewidth}
\begin{mail}{IMAP4-Sitzung}{IMAP4-Sitzung}
C: <öffnet Verbindung>
S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 322 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 12 RECENT
S: * OK [UNSEEN 88] Message 88 is the first unseen message
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 8 body[header]
S: * 8 FETCH (BODY[HEADER] {342}
S: From: Hans Bauer <hans@bauer.de>
S: To: Mina Meier <mina@meier.de>,
S: Kaiser Wilhelm <wilhelm@keiser.de>
S: Date: Tue, 8 Mar 2016 06:46:18 -0800
S: Subject: Beispiel-Mail
S: Message-ID: <18283.122131@bauer.de>
S: X-Mein-Header: True
S:
S: )
S: a003 OK FETCH completed
C: a004 store 8 +flags \deleted
S: * 8 FETCH (FLAGS (\Seen \Deleted))
S: a004 OK +FLAGS completed
C: a005 logout
S: * BYE IMAP4rev1 server terminating connection
S: a005 OK LOGOUT completed
\end{mail}
\end{minipage}
Wie hier zu sehen ist, sind die Transaktionen durchnummeriert und haben für Client und Server denselben Bezeichner. Der IMAP4 Zustand ist implizit und muss aus dem Kontext erschlossen werden.
% TODO: figure gets misplaced
% TODO: nicht alle server Nachrichten dargestellt
\begin{figure}[htb]
%\Centerfloat
\centering
\includegraphics[scale=0.4]{Content/Intro/Protokolle/IMAP4.png}
\caption{IMAP4 SDL Diagramm}
\label{fig:imap4}
\end{figure}
\vfill
\clearpage

73
Bachelorthesis/Content/Intro/Protokolle/POP3.tex Normal file
View File

@ -0,0 +1,73 @@
POP3 ist die Version 3 des \QuoteM{Post Office Protocol}, spezifiziert in RFC 1939 \RefIt{rfc1939}. Während SMTP das Versenden, Erstellen und Weiterleiten von E-Mails beschreibt, beschreibt POP3 das Abholen, Auflisten und Löschen von E-Mails an einem E-Mail Server \QuoteIndirect{rfc1939}{S. 2}. Es ist keine Erweiterung des SMTP Protokolls, da es eine eigenständige Funktionalität hat, die SMTP nicht bereitstellt. Ebenso denkbar ist, dass POP3 mit einem E-Mail Server verwendet wird, der nicht SMTP zum Versenden benutzt, was allerdings in der Praxis kaum vorkommt. POP3 ist sehr simpel und eingeschränkt in der Funktionalität, was bereits in RFC 1939 angesprochen wird, mit einem Vermerk zu dem etwas mächtigeren IMAP4 Protokoll \QuoteIndirect{rfc1939}{S. 2}.
Ähnlich wie SMTP ist auch POP3 ein Client-Server basiertes System. In gängigen E-Mail Servern befindet sich also häufig nicht nur ein SMTP, sondern auch ein POP3 Server.
Ebenso wie SMTP ist auch POP3 TCP basiert. Die Kommunikation findet entweder über Port 110 \QuoteIndirect{rfc1939}{S. 3} statt oder im Falle von SSL/TSL Verschlüsselung über das POP3S Protokoll auf Port 995, welcher allerdings nach RFC 2595 \QuoteIndirect{rfc2595}{S. 9} als veraltet gilt und stattdessen STARTTLS auf dem Standardport 110 benutzt werden soll.
POP3 ist ein sehr zustandsbehaftetes Protokoll, d.h. die Verbindung kann sich in verschiedenen Zuständen befinden. Der erste Zustand ist der \QuoteDirect{AUTHORIZATION state}{rfc1939}{S. 3}, in dem sich die Verbindung befindet nachdem der POP3 server das sogenannte \QuoteDirect{greeting}{rfc1939}{S. 3} gesendet hat. Nachfolgend muss sich der Client authentifizieren. Ist die Authentifizierung erfolgreich, so gelangt die Verbindung in den \QuoteDirect{TRANSACTION state}{rfc1939}{S. 3}. In diesem Zustand kann der Client diverse Anfragen senden, um mit den auf dem POP3 Server liegenden E-Mails zu interagieren. Der letzte Zustand, der sogenannte \QuoteDirect{UPDATE state}{rfc1939}{S. 3 f}, wird erreicht nachdem der Client das \verb#QUIT# Kommando gesendet hat. In diesem Zustand werden alle Ressourcen freigegeben, die während des \QuoteM{TRANSACTION state} belegt wurden. Erst danach wird die TCP Verbindung geschlossen. \QuoteIndirect{rfc1939}{S. 3 f}
Dem POP3 Client stehen folgende Kommandos zur Kommunikation mit dem Server zur Verfügung:
\begin{itemize}
\item AUTHORIZATION state
\begin{itemize}
\item \verb#USER <user>#: wird in Verbindung mit \verb#PASS# zur Authentifizierung verwendet, alternativ kann \verb#APOP# verwendet werden
\item \verb#PASS <password>#: wird in Verbindung mit \verb#USER# zur Authentifizierung verwendet, alternativ kann \verb#APOP# verwendet werden
\item \verb#APOP#: alternatives Authentifizierungsverfahren, welches das Passwort nicht als Klartext sendet
\item \verb#QUIT#: beendet die Verbindung
\end{itemize}
\item TRANSACTION state
\begin{itemize}
\item \verb#STAT#: Abfrage des Status der Mailbox
\item \verb#LIST (i)#: zeigt Informationen zu der i-ten E-Mail oder zu allen E-Mails, gewöhnlicherweise Anzahl und Größe
\item \verb#RETR i#: lädt die i-te E-Mail vom Server herunter
\item \verb#DELE i#: löscht die i-te E-Mail
\item \verb#NOOP#: tut nichts, der Server antwortet immer positiv
\item \verb#RSET#: macht das löschen von E-Mails rückgängig
\item \verb#TOP i l#: lädt den Header und die ersten l Zeilen der i-ten E-Mail herunter
\item \verb#UIDL i#: zeigt die \QuoteM{unique-id} der E-Mail an
\end{itemize}
\item UPDATE state
\begin{itemize}
\item \verb#QUIT#: beendet die Verbindung und führt mögliche \verb#DELE# Kommandos aus
\end{itemize}
\end{itemize}
Eine mögliche POP3-Sitzung könnte so aussehen:
\\
\\
\begin{minipage}{\linewidth}
\begin{mail}{POP3-Sitzung}{POP3-Sitzung}
S: <wartet auf Verbindung an TCP port 110>
C: <client verbindet sich>
S: +OK pop3.bauer.de POP3-Server
C: USER hans@pop3.bauer.de
S: +OK Valid user, now enter password
C: PASS <Klartext-Passwort>
S: +OK Password valid, maildrop locked and ready
C: STAT
S: +OK 500 4670
C: LIST 670
S: -ERR no such message
C: LIST 67
S: +OK 67 300
C: RETR 67
S: +OK 300 octets
S: <der POP3 server sendet die vollständige E-Mail>
S: .
C: DELE 67
S: +OK message 67 deleted
C: QUIT
S: +OK POP3 server signing off (maildrop empty)
C: <beendet Verbindung>
S: <wartet auf Verbindung an TCP port 110>
\end{mail}
\end{minipage}
Wie hier zu sehen ist, liegt ein impliziter Zustand vor, welcher aus dem Kontext erschlossen werden muss.
Wichtig anzumerken ist auch, dass das normale POP3 Authentifizierungsverfahren über die Kommandos \verb#USER# und \verb#PASS# unsicher ist, da die Daten als Klartext gesendet werden \QuoteIndirect{rfc1939}{S. 14}. Ebenso gilt das alternative APOP Authentifizierungsverfahren als unsicher \QuoteIndirect{apopinsec}{S. 1-18}.
Stattdessen kann STARTTLS mit POP3 verwendet werden, gemäß RFC 2595 \RefIt{rfc2595}.

670
Bachelorthesis/Content/Intro/Protokolle/SMTP-Model.dia Normal file
View File

@ -0,0 +1,670 @@
<?xml version="1.0" encoding="UTF-8"?>
<dia:diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/">
<dia:diagramdata>
<dia:attribute name="background">
<dia:color val="#ffffff"/>
</dia:attribute>
<dia:attribute name="pagebreak">
<dia:color val="#000099"/>
</dia:attribute>
<dia:attribute name="paper">
<dia:composite type="paper">
<dia:attribute name="name">
<dia:string>#A4#</dia:string>
</dia:attribute>
<dia:attribute name="tmargin">
<dia:real val="2.8222000598907471"/>
</dia:attribute>
<dia:attribute name="bmargin">
<dia:real val="2.8222000598907471"/>
</dia:attribute>
<dia:attribute name="lmargin">
<dia:real val="2.8222000598907471"/>
</dia:attribute>
<dia:attribute name="rmargin">
<dia:real val="2.8222000598907471"/>
</dia:attribute>
<dia:attribute name="is_portrait">
<dia:boolean val="true"/>
</dia:attribute>
<dia:attribute name="scaling">
<dia:real val="1"/>
</dia:attribute>
<dia:attribute name="fitto">
<dia:boolean val="false"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="grid">
<dia:composite type="grid">
<dia:attribute name="width_x">
<dia:real val="1"/>
</dia:attribute>
<dia:attribute name="width_y">
<dia:real val="1"/>
</dia:attribute>
<dia:attribute name="visible_x">
<dia:int val="1"/>
</dia:attribute>
<dia:attribute name="visible_y">
<dia:int val="1"/>
</dia:attribute>
<dia:composite type="color"/>
</dia:composite>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#d8e5e5"/>
</dia:attribute>
<dia:attribute name="guides">
<dia:composite type="guides">
<dia:attribute name="hguides"/>
<dia:attribute name="vguides"/>
</dia:composite>
</dia:attribute>
</dia:diagramdata>
<dia:layer name="Background" visible="true" active="true">
<dia:object type="Network - General Computer (Tower)" version="1" id="O0">
<dia:attribute name="obj_pos">
<dia:point val="22.6211,13.1"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="22.613,13.06;23.7883,16.0351"/>
</dia:attribute>
<dia:attribute name="meta">
<dia:composite type="dict"/>
</dia:attribute>
<dia:attribute name="elem_corner">
<dia:point val="22.6211,13.1"/>
</dia:attribute>
<dia:attribute name="elem_width">
<dia:real val="1.1578947368421049"/>
</dia:attribute>
<dia:attribute name="elem_height">
<dia:real val="1.9999999999999989"/>
</dia:attribute>
<dia:attribute name="line_width">
<dia:real val="0.10000000000000001"/>
</dia:attribute>
<dia:attribute name="line_colour">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="fill_colour">
<dia:color val="#ffffff"/>
</dia:attribute>
<dia:attribute name="show_background">
<dia:boolean val="true"/>
</dia:attribute>
<dia:attribute name="line_style">
<dia:enum val="0"/>
<dia:real val="1"/>
</dia:attribute>
<dia:attribute name="padding">
<dia:real val="0.10000000000000001"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
<dia:string>##</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="sans" style="0" name="Helvetica"/>
</dia:attribute>
<dia:attribute name="height">
<dia:real val="0.80000000000000004"/>
</dia:attribute>
<dia:attribute name="pos">
<dia:point val="23.2,15.8026"/>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="alignment">
<dia:enum val="1"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="flip_horizontal">
<dia:boolean val="false"/>
</dia:attribute>
<dia:attribute name="flip_vertical">
<dia:boolean val="false"/>
</dia:attribute>
<dia:attribute name="subscale">
<dia:real val="1"/>
</dia:attribute>
</dia:object>
<dia:object type="Network - Storage" version="1" id="O1">
<dia:attribute name="obj_pos">
<dia:point val="19.8,13"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="19.75,12.95;21.55,15.8825"/>
</dia:attribute>
<dia:attribute name="meta">
<dia:composite type="dict"/>
</dia:attribute>
<dia:attribute name="elem_corner">
<dia:point val="19.8,13"/>
</dia:attribute>
<dia:attribute name="elem_width">
<dia:real val="1.6999999999999995"/>
</dia:attribute>
<dia:attribute name="elem_height">
<dia:real val="1.9999999999999996"/>
</dia:attribute>
<dia:attribute name="line_width">
<dia:real val="0.10000000000000001"/>
</dia:attribute>
<dia:attribute name="line_colour">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="fill_colour">
<dia:color val="#ffffff"/>
</dia:attribute>
<dia:attribute name="show_background">
<dia:boolean val="true"/>
</dia:attribute>
<dia:attribute name="line_style">
<dia:enum val="0"/>
<dia:real val="1"/>
</dia:attribute>
<dia:attribute name="padding">
<dia:real val="0.10000000000000001"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
<dia:string>##</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="sans" style="0" name="Helvetica"/>
</dia:attribute>
<dia:attribute name="height">
<dia:real val="0.80000000000000004"/>
</dia:attribute>
<dia:attribute name="pos">
<dia:point val="20.65,15.65"/>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="alignment">
<dia:enum val="1"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="flip_horizontal">
<dia:boolean val="false"/>
</dia:attribute>
<dia:attribute name="flip_vertical">
<dia:boolean val="false"/>
</dia:attribute>
<dia:attribute name="subscale">
<dia:real val="1"/>
</dia:attribute>
</dia:object>
<dia:object type="Network - General Computer (Tower)" version="1" id="O2">
<dia:attribute name="obj_pos">
<dia:point val="33.5711,13.1"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="33.563,13.06;34.7383,16.0351"/>
</dia:attribute>
<dia:attribute name="meta">
<dia:composite type="dict"/>
</dia:attribute>
<dia:attribute name="elem_corner">
<dia:point val="33.5711,13.1"/>
</dia:attribute>
<dia:attribute name="elem_width">
<dia:real val="1.1578947368421058"/>
</dia:attribute>
<dia:attribute name="elem_height">
<dia:real val="2.0000000000000004"/>
</dia:attribute>
<dia:attribute name="line_width">
<dia:real val="0.10000000000000001"/>
</dia:attribute>
<dia:attribute name="line_colour">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="fill_colour">
<dia:color val="#ffffff"/>
</dia:attribute>
<dia:attribute name="show_background">
<dia:boolean val="true"/>
</dia:attribute>
<dia:attribute name="line_style">
<dia:enum val="0"/>
<dia:real val="1"/>
</dia:attribute>
<dia:attribute name="padding">
<dia:real val="0.10000000000000001"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
<dia:string>##</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="sans" style="0" name="Helvetica"/>
</dia:attribute>
<dia:attribute name="height">
<dia:real val="0.80000000000000004"/>
</dia:attribute>
<dia:attribute name="pos">
<dia:point val="34.15,15.8026"/>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="alignment">
<dia:enum val="1"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="flip_horizontal">
<dia:boolean val="false"/>
</dia:attribute>
<dia:attribute name="flip_vertical">
<dia:boolean val="false"/>
</dia:attribute>
<dia:attribute name="subscale">
<dia:real val="1"/>
</dia:attribute>
</dia:object>
<dia:object type="Network - Storage" version="1" id="O3">
<dia:attribute name="obj_pos">
<dia:point val="36.5,13.15"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="36.45,13.1;38.25,16.0325"/>
</dia:attribute>
<dia:attribute name="meta">
<dia:composite type="dict"/>
</dia:attribute>
<dia:attribute name="elem_corner">
<dia:point val="36.5,13.15"/>
</dia:attribute>
<dia:attribute name="elem_width">
<dia:real val="1.7000000000000015"/>
</dia:attribute>
<dia:attribute name="elem_height">
<dia:real val="2.0000000000000018"/>
</dia:attribute>
<dia:attribute name="line_width">
<dia:real val="0.10000000000000001"/>
</dia:attribute>
<dia:attribute name="line_colour">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="fill_colour">
<dia:color val="#ffffff"/>
</dia:attribute>
<dia:attribute name="show_background">
<dia:boolean val="true"/>
</dia:attribute>
<dia:attribute name="line_style">
<dia:enum val="0"/>
<dia:real val="1"/>
</dia:attribute>
<dia:attribute name="padding">
<dia:real val="0.10000000000000001"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
<dia:string>##</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="sans" style="0" name="Helvetica"/>
</dia:attribute>
<dia:attribute name="height">
<dia:real val="0.80000000000000004"/>
</dia:attribute>
<dia:attribute name="pos">
<dia:point val="37.35,15.8"/>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="alignment">
<dia:enum val="1"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="flip_horizontal">
<dia:boolean val="false"/>
</dia:attribute>
<dia:attribute name="flip_vertical">
<dia:boolean val="false"/>
</dia:attribute>
<dia:attribute name="subscale">
<dia:real val="1"/>
</dia:attribute>
</dia:object>
<dia:object type="Standard - ZigZagLine" version="1" id="O4">
<dia:attribute name="obj_pos">
<dia:point val="20.65,15"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="20.2882,14.95;23.5618,16.75"/>
</dia:attribute>
<dia:attribute name="orth_points">
<dia:point val="20.65,15"/>
<dia:point val="20.65,16.7"/>
<dia:point val="23.2,16.7"/>
<dia:point val="23.2,15.1"/>
</dia:attribute>
<dia:attribute name="orth_orient">
<dia:enum val="1"/>
<dia:enum val="0"/>
<dia:enum val="1"/>
</dia:attribute>
<dia:attribute name="autorouting">
<dia:boolean val="false"/>
</dia:attribute>
<dia:attribute name="start_arrow">
<dia:enum val="22"/>
</dia:attribute>
<dia:attribute name="start_arrow_length">
<dia:real val="0.5"/>
</dia:attribute>
<dia:attribute name="start_arrow_width">
<dia:real val="0.5"/>
</dia:attribute>
<dia:attribute name="end_arrow">
<dia:enum val="22"/>
</dia:attribute>
<dia:attribute name="end_arrow_length">
<dia:real val="0.5"/>
</dia:attribute>
<dia:attribute name="end_arrow_width">
<dia:real val="0.5"/>
</dia:attribute>
<dia:connections>
<dia:connection handle="0" to="O1" connection="1"/>
<dia:connection handle="1" to="O0" connection="1"/>
</dia:connections>
</dia:object>
<dia:object type="Standard - ZigZagLine" version="1" id="O5">
<dia:attribute name="obj_pos">
<dia:point val="37.35,15.15"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="33.7882,15.05;37.7118,16.75"/>
</dia:attribute>
<dia:attribute name="orth_points">
<dia:point val="37.35,15.15"/>
<dia:point val="37.35,16.7"/>
<dia:point val="34.15,16.7"/>
<dia:point val="34.15,15.1"/>
</dia:attribute>
<dia:attribute name="orth_orient">
<dia:enum val="1"/>
<dia:enum val="0"/>
<dia:enum val="1"/>
</dia:attribute>
<dia:attribute name="autorouting">
<dia:boolean val="false"/>
</dia:attribute>
<dia:attribute name="start_arrow">
<dia:enum val="22"/>
</dia:attribute>
<dia:attribute name="start_arrow_length">
<dia:real val="0.5"/>
</dia:attribute>
<dia:attribute name="start_arrow_width">
<dia:real val="0.5"/>
</dia:attribute>
<dia:attribute name="end_arrow">
<dia:enum val="22"/>
</dia:attribute>
<dia:attribute name="end_arrow_length">
<dia:real val="0.5"/>
</dia:attribute>
<dia:attribute name="end_arrow_width">
<dia:real val="0.5"/>
</dia:attribute>
<dia:connections>
<dia:connection handle="0" to="O3" connection="1"/>
<dia:connection handle="1" to="O2" connection="1"/>
</dia:connections>
</dia:object>
<dia:object type="Standard - Line" version="0" id="O6">
<dia:attribute name="obj_pos">
<dia:point val="23.6077,14.1"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="23.5577,13.7382;33.7395,14.4618"/>
</dia:attribute>
<dia:attribute name="conn_endpoints">
<dia:point val="23.6077,14.1"/>
<dia:point val="33.6895,14.1"/>
</dia:attribute>
<dia:attribute name="numcp">
<dia:int val="1"/>
</dia:attribute>
<dia:attribute name="start_arrow">
<dia:enum val="22"/>
</dia:attribute>
<dia:attribute name="start_arrow_length">
<dia:real val="0.5"/>
</dia:attribute>
<dia:attribute name="start_arrow_width">
<dia:real val="0.5"/>
</dia:attribute>
<dia:attribute name="end_arrow">
<dia:enum val="22"/>
</dia:attribute>
<dia:attribute name="end_arrow_length">
<dia:real val="0.5"/>
</dia:attribute>
<dia:attribute name="end_arrow_width">
<dia:real val="0.5"/>
</dia:attribute>
<dia:connections>
<dia:connection handle="0" to="O0" connection="2"/>
<dia:connection handle="1" to="O2" connection="2"/>
</dia:connections>
</dia:object>
<dia:object type="Standard - Text" version="1" id="O7">
<dia:attribute name="obj_pos">
<dia:point val="32.7,11.7"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="32.7,11.0407;36.3093,11.8711"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
<dia:string>#SMTP Server#</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="sans" style="0" name="Helvetica"/>
</dia:attribute>
<dia:attribute name="height">
<dia:real val="0.80000000000000004"/>
</dia:attribute>
<dia:attribute name="pos">
<dia:point val="32.7,11.7"/>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="alignment">
<dia:enum val="0"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="valign">
<dia:enum val="3"/>
</dia:attribute>
</dia:object>
<dia:object type="Standard - Text" version="1" id="O8">
<dia:attribute name="obj_pos">
<dia:point val="22.15,11.7"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="22.15,11.06;25.4275,11.8325"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
<dia:string>#SMTP client#</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="sans" style="0" name="Helvetica"/>
</dia:attribute>
<dia:attribute name="height">
<dia:real val="0.80000000000000004"/>
</dia:attribute>
<dia:attribute name="pos">
<dia:point val="22.15,11.7"/>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="alignment">
<dia:enum val="0"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="valign">
<dia:enum val="3"/>
</dia:attribute>
</dia:object>
<dia:object type="Standard - Text" version="1" id="O9">
<dia:attribute name="obj_pos">
<dia:point val="16.05,14.25"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="16.05,13.61;19.5,14.3825"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
<dia:string>#Dateisystem#</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="sans" style="0" name="Helvetica"/>
</dia:attribute>
<dia:attribute name="height">
<dia:real val="0.80000000000000004"/>
</dia:attribute>
<dia:attribute name="pos">
<dia:point val="16.05,14.25"/>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="alignment">
<dia:enum val="0"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="valign">
<dia:enum val="3"/>
</dia:attribute>
</dia:object>
<dia:object type="Standard - Text" version="1" id="O10">
<dia:attribute name="obj_pos">
<dia:point val="38.735,14.315"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="38.735,13.675;42.185,14.4475"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
<dia:string>#Dateisystem#</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="sans" style="0" name="Helvetica"/>
</dia:attribute>
<dia:attribute name="height">
<dia:real val="0.80000000000000004"/>
</dia:attribute>
<dia:attribute name="pos">
<dia:point val="38.735,14.315"/>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="alignment">
<dia:enum val="0"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="valign">
<dia:enum val="3"/>
</dia:attribute>
</dia:object>
<dia:object type="Standard - Text" version="1" id="O11">
<dia:attribute name="obj_pos">
<dia:point val="26.15,13.45"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="26.15,12.81;31.4075,13.5825"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
<dia:string>#SMTP Kommandos#</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="sans" style="0" name="Helvetica"/>
</dia:attribute>
<dia:attribute name="height">
<dia:real val="0.80000000000000004"/>
</dia:attribute>
<dia:attribute name="pos">
<dia:point val="26.15,13.45"/>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="alignment">
<dia:enum val="0"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="valign">
<dia:enum val="3"/>
</dia:attribute>
</dia:object>
<dia:object type="Standard - Text" version="1" id="O12">
<dia:attribute name="obj_pos">
<dia:point val="26.4,15.2"/>
</dia:attribute>
<dia:attribute name="obj_bb">
<dia:rectangle val="26.4,14.56;31.0975,15.3325"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
<dia:string>#SMTP Antworten#</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="sans" style="0" name="Helvetica"/>
</dia:attribute>
<dia:attribute name="height">
<dia:real val="0.80000000000000004"/>
</dia:attribute>
<dia:attribute name="pos">
<dia:point val="26.4,15.2"/>
</dia:attribute>
<dia:attribute name="color">
<dia:color val="#000000"/>
</dia:attribute>
<dia:attribute name="alignment">
<dia:enum val="0"/>
</dia:attribute>
</dia:composite>
</dia:attribute>
<dia:attribute name="valign">
<dia:enum val="3"/>
</dia:attribute>
</dia:object>
</dia:layer>
</dia:diagram>

BIN
Bachelorthesis/Content/Intro/Protokolle/SMTP-Model.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

76
Bachelorthesis/Content/Intro/Protokolle/SMTP.tex Normal file
View File

@ -0,0 +1,76 @@
Das SMTP Protokoll hat ähnlich wie das Internet Message Format mehrere Versionen, angefangen beim RFC 821 vom August 1982 \RefIt{rfc821}
über RFC 2821 vom April 2001 \RefIt{rfc2821}
bis hin zu RFC 5321 vom Oktober 2008 \RefIt{rfc5321},
welches die aktuellste Version zum Zeitpunkt dieser Arbeit ist. Das Ziel des RFC 5321 ist es, eine Spezifikation für ein Protokoll zum Transport von E-Mails auf Basis des IMF bereitzustellen. Somit beschreibt es die grundlegende Kommunikation von E-Mail Servern untereinander, inklusive Versand, Empfang, Fehlerbehandlung etc., als auch die Kommunikation zwischen einem SMTP Client, welcher eine E-Mail einreicht, und einem SMTP/E-Mail Server. Besonders hervorzuheben ist auch, dass dieser RFC nicht nur das SMTP Protokoll an sich beschreibt, sondern auch den \QuoteDirect{SMTP extension mechanism}{rfc5321}{S. 1, S. 9 ff}
und diverse praktische Gesichtspunkte, die über die Protokoll-Spezifikation hinausgehen.
In seiner Grundform beschreibt das SMTP Protokoll ein Verfahren, das aus mehreren Schichten besteht. Die erste Schicht ist hierbei die Verbindung selbst, gewöhnlicherweise zwischen einem SMTP Client und einem SMTP Server \QuoteIndirect{rfc5321}{S. 7}. Diese Verbindung wird generell über ein zuverlässiges Protokoll wie beispielsweise TCP hergestellt, da es keine Fehlertoleranz auf Daten-Ebene gibt. Sobald der Client sich mit dem Server verbunden hat, z.B. über das Programm \QuoteM{telnet}, stehen dem Client auf Verbindungsebene folgende Kommandos zur Verfügung:
\begin{itemize}
\item \verb#HELO:# identifiziert den Client zum SMTP Server
\item \verb#QUIT:# beendet die Verbindung zum SMTP Server
\end{itemize}
% TODO: EHLO, bzw. ESMTP
Wie hier zu erkennen ist, ist SMTP ein textbasiertes Protokoll. Beim Senden von \verb#HELO# muss der Client als Parameter seine FQDN mitschicken, erst danach ist die Verbindung erfolgreich zustande gekommen und der nächste Schritt ist möglich.
Hat die Verbindung diesen Zustand erreicht, so sind nachfolgend 0 oder mehr Transaktionen möglich, welches die nächste Schicht darstellt. Für eine einzelne Transaktion stehen dem Client folgende Kommandos zur Verfügung:
\begin{itemize}
\item \verb#MAIL FROM:# der erste Schritt, initiiert eine Transaktion und gibt den Sender der E-Mail an
\item \verb#RCPT TO:# der zweite Schritt, gibt den Empfänger an
\item \verb#DATA:# der gewissermaßen letzte Schritt gibt an, dass jetzt der Inhalt der E-Mail gemäß dem IMF folgt
\end{itemize}
Die weiteren Informationen auf Transaktions-Ebene wie \verb#MAIL FROM# und \verb#RCPT TO# in Verbindung mit der tatsächlichen E-Mail, die über das \verb#DATA# Kommando übermittelt wird, können auch grob als Envelope betrachtet werden.
Anzumerken ist hier, dass der E-Mail Server die Transaktion abbrechen muss, wenn diese Kommandos in fehlerhafter Reihenfolge ankommen. Die Reihenfolge ist genau einzuhalten, d.h. erst \verb#MAIL#, welches einmalig angegeben wird, dann \verb#RCPT#, welches mehrmals angegeben werden kann, dann \verb#DATA# und anschließend der Inhalt. Wenn der Inhalt der E-Mail gemäß IMF inklusive Header gesendet wird, so muss dieser mit einer Zeile enden, die nur einen Punkt enthält \QuoteIndirect{rfc5321}{S. 20}.
Nach jedem Kommando, das der Client sendet, muss der Server antworten. Dies geschieht über den Status-Code (engl. \QuoteDirect{reply code}{rfc5321}{S. 48 ff}), welcher aus 3 Ziffern besteht. Die erste Ziffer gibt an, ob die Antwort gut, schlecht oder unvollständig ist. Die zweite Ziffer gibt an, welche Art von Fehler vorliegt. Die dritte Ziffer gibt weitere Informationen über den Fehler an.
Eine vollständige Betrachtung der Status-Codes macht an dieser Stelle keinen Sinn, deshalb wird hier nur die erste Ziffer betrachtet, um einen groben Überblick zu verschaffen.
\verb#2xx# bedeutet, dass die Anfrage erfolgreich verarbeitet wurde und eine weitere Anfrage gesendet werden kann. \verb#3xx# bedeutet ähnlich wie \verb#2xx#, dass die Anfrage erfolgreich war, allerdings erwartet der Server jetzt noch weitere Informationen vom Client. Dies tritt beispielsweise beim \verb#DATA# Kommando auf, nach welchem der E-Mail Inhalt folgen muss. \verb#4xx# denotiert ein Kommando, das nicht akzeptiert wurde, was bedeutet, dass die Anfrage nicht ausgeführt wurde. Der Client kann bzw. sollte die Kommando-Sequenz wiederholen. \verb#5xx# denotiert ähnlich wie \verb#4xx# eine abgewiesene Anfrage. Allerdings ist dies ein permanenter Fehler und die zugrunde liegende Kommando-Sequenz sollte nicht wiederholt werden. Nach dem Status-Code folgt immer ein Text String, der menschenlesbar sein sollte. \QuoteIndirect{rfc5321}{S. 47 ff}.
Eine vollständige SMTP Sitzung könnte wie folgt aussehen (C steht für Client, S für Server):
\\
\\
\begin{minipage}{\linewidth}
\begin{mail}{SMTP-Sitzung}{SMTP-Sitzung}
C: telnet mail.wurst.de 25
S: 220 service ready
C: HELO wurst.de
S: 250 OK
C: MAIL FROM:<hans@bauer.de>
S: 250 OK
C: RCPT TO:<mina@meier.de>
S: 250 OK
C: RCPT TO:<wilhelm@keiser.de>
S: 250 OK
C: DATA
S: 354 start mail input
C: From: Hans Bauer <hans@bauer.de>
To: Mina Meier <mina@meier.de>,
Kaiser Wilhelm <wilhelm@keiser.de>
Date: Tue, 8 Mar 2016 06:46:18 -0800
Subject: Beispiel-Mail
Message-ID: <18283.122131@bauer.de>
X-Mein-Header: True
Dies ist ein Beispieltext
über mehrere Zeilen.
.
S: 250 OK
C: QUIT
S: 221 closing channel
\end{mail}
\end{minipage}
Was hier besonders auffällt und äußerst wichtig für die weitere Betrachtung der Problematik und Implementierung sein wird, ist die Tatsache, dass die Headerfelder \verb#From# und \verb#To# auf Ebene des IMF praktisch losgelöst sind von den tatsächlich angegebenen Informationen \verb#MAIL FROM# und \verb#RCPT TO# auf Ebene des SMTP Protokolls. Sie können divergieren oder übereinstimmen. Obwohl es hier eine Reihe von Regeln gibt wie sich ein E-Mail Server verhalten soll, gibt es keine Garantie, dass hier Konsistenz herrscht. Dies wird unter anderem für das Headerfeld \verb#BCC# genutzt, welches angibt, dass die E-Mail an einen weiteren Empfänger gesendet werden soll, aber diese Information aus dem Header gelöscht wird, sobald der Server zustellt oder weiterleitet \QuoteIndirect{rfc5321}{S. 85}.
Ebenso ersichtlich in Zeile 1 ist hier, dass eine SMTP Sitzung generell über Port 25 abgewickelt wird \QuoteIndirect{rfc5321}{S. 68}. Reicht ein SMTP Client eine E-Mail bei einem Server ein, wird allerdings Port 587 gemäß dem RFC \QuoteDirect{Message Submission for Mail}{rfc6409}{S. 6} benutzt. Im Falle von SSL/TLS Verschlüsselung wird allerdings häufig Port 465 benutzt \QuoteIndirectNoPage{ssmtps}, obwohl nach RFC \QuoteDirect{SMTP Service Extension for Secure SMTP over TLS}{rfc2487}{S. 2} dafür kein designierter Port mehr vorhergesehen ist, da stattdessen STARTTLS benutzt werden soll.
\begin{figure}[htb]
%\Centerfloat
\centering
\includegraphics[scale=0.4]{Content/Intro/Protokolle/SMTP-Model.png}
\caption{SMTP Modell}
\label{fig:smtpmodel}
\end{figure}

2307
Bachelorthesis/Content/Intro/Protokolle/emailg.dia Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
Bachelorthesis/Content/Intro/Protokolle/emailg.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 38 KiB

32
Bachelorthesis/Content/ListOfAbbreviations/ListOfAbbreviations.tex Normal file
View File

@ -0,0 +1,32 @@
\setlength{\columnsep}{3.3 cm} % Space between columnseprule and right text
\setlength{\columnseprule}{\LineThickness} % Thikness of the columnseprule
\begin{acronym}[WWWWWWWWWiii] % The length of the longes abbreviation
\newcommand{\bflabel}[1]{\textbf{\textsf{#1}}\dotfill} % add dotfill
\setlength{\itemsep}{1 pt} % set space between lines
\acro{bzw.}{beziehungsweise}
\acro{ca.}{circa}
\acro{DDoS}{distributed denial-of-service}
\acro{d.h.}{das heißt}
\acro{E-Mail}{electronic mail}
\acro{FTP}{File Transfer Protocol}
\acro{FQDN}{Fully qualified domain name}
\acro{engl.}{englisch}
\acro{etc.}{et cetera}
\acro{ID}{Identifikationsnummer}
\acro{IMAP4}{Internet Message Access Protocol Version 4}
\acro{IMF}{Internet Message Format}
\acro{Mrd.}{Milliarden}
\acro{POP3}{Post Office Protocol Version 3}
\acro{RFC}{Request for Comments}
\acro{SMTP}{Simple Mail Transfer Protocol}
\acro{TCP}{Transmission Control Protocol}
\acro{u.a.}{unter anderem}
\acro{UUID}{Universally Unique Identifier}
\acro{u.U.}{unter Umständen}
\acro{WWW}{World Wide Web}
\acro{z.B.}{zum Beispiel}
\end{acronym}

4
Bachelorthesis/Content/LookOut.tex Normal file
View File

@ -0,0 +1,4 @@
Da nun die Implementierung durchgeführt wurde und dieselbe anhand der definierten funktionalen und nichtfunktionalen Anforderungen validiert wurde, müssen nachfolgend vor allem die Teile betrachtet werden, die nicht oder nicht ausreichend gelöst werden konnten, sei es weil eine adäquate Lösung den Rahmen dieser Arbeit übersteigt oder weil noch keine vorliegt. Demnach sind sowohl theoretische als auch praktische Probleme hier von Belang.
Diese werden im folgenden ausgeführt und beschreiben im Ganzen noch fehlende Lösungen für das vorgeschlagene System.

1
Bachelorthesis/Content/LookOut/PraktischeProbleme.tex Normal file
View File

@ -0,0 +1 @@
Zu den praktischen Problemen gehören vor allem Implementierungsprobleme und diverse Probleme, die sich aus einer praktischen Benutzung des vorgeschlagenen Systems ergeben.

4
Bachelorthesis/Content/LookOut/PraktischeProbleme/DirectoryServer.tex Normal file
View File

@ -0,0 +1,4 @@
Sowohl zur Verbesserung der Spam-Abwehr als auch zur Integrität des Systems insgesamt ist ein Directory Server notwendig. Dieser muss alle validen Knoten für eine mögliche Anonymisierungs-Route verwalten. Sowohl beim Erstellen einer Route wird diese Liste abgefragt als auch bei der Kommunikation zwischen Knoten.
Somit können Knoten mit Fehlverhalten auch problemlos entfernt werden.
Allerdings öffnet dies einen zentralen Angriffspunkt auf das System. Der Directory Server muss mit speziellen Methoden gesichert werden und die abgerufene Liste kryptografisch verifizierbar sein.

5
Bachelorthesis/Content/LookOut/PraktischeProbleme/Fehlerbehandlung.tex Normal file
View File

@ -0,0 +1,5 @@
Die Fehlerbehandlung ist noch nicht ausreichend gelöst. Sie ist ebenso relevant für die Betrachtung der Sicherheit des Systems.
Dies ist auch teilweise ein theoretisches Problem, aber vor allem ein Problem auf Implementierungsebene. So ist es nicht klar, wie die Knoten sich verhalten sollen, wenn es Probleme bei der Weiterleitung, Entschlüsselung oder Verbindung gibt. Diese Probleme müssen robust gelöst werden, um die Angriffsfläche zu minimieren.
Ebenso denkbar sind Angriffe durch den Myst-Header, wenn beispielsweise missgebildete E-Mails versendet werden, die nicht korrekt oder gar nicht verschlüsselt sind und eventuell undefiniertes Verhalten im MTA hervorrufen.

7
Bachelorthesis/Content/LookOut/PraktischeProbleme/Gesamtsystem.tex Normal file
View File

@ -0,0 +1,7 @@
Das hier vorgeschlagene System ist nicht nur eine SMTP-Erweiterung. Es handelt sich vor allem um eine Kombination aus bereits existierenden Technologien wie GPG, TorBirdy und TLS.
Selbst wenn für die SMTP-Erweiterung eine konkrete Spezifikation und eine funktionierende Implementierung existiert, muss der Benutzer dennoch weitere Schritte unternehmen, um dieses System korrekt zu benutzen. Dies erhöht die Wahrscheinlichkeit, dass das System inkorrekt benutzt wird.
Dies ist einerseits Dokumentationsarbeit, andererseits ist es aber auch denkbar, ähnlich wie Tor, eine Softwarelösung zur Verfügung zu stellen, die eine korrekte Konfiguration beinhaltet. Allerdings ist dies schwierig, da dies nur auf MUA Ebene möglich ist und der E-Mail Server immer noch fehlkonfiguriert sein kann.
Ebenso ist das Problem der SMTP Spezifikation ungelöst, welche keine Garantie gibt, dass 2 MTAs überhaupt verschlüsselt kommunizieren, selbst wenn beide dies beherrschen. Dies muss auf Implementierungsebene garantiert werden, für alle Komponenten, die in diesem Kryptografiesystem mitwirken.

6
Bachelorthesis/Content/LookOut/PraktischeProbleme/Implementierung.tex Normal file
View File

@ -0,0 +1,6 @@
Nicht gerade ein Problem dieser Arbeit, aber ein Problem für eine mögliche praktische Benutzung ist das Fehlen einer professionellen Implementierung. Diese ist aber nicht sinnvoll ohne eine konkrete Spezifikation wie auf Seite \pageref{section:spezifikation} genannt möglich.
Die hier präsentierte Implementierung ist eine Proof-of-Concept Implementierung und in keiner Weise für den Einsatz gedacht. Unschöner Weise hängt sie sogar von interner API ab.
Eine professionelle Implementierung würde hingegen als strenges Modul bzw. Plugin entwickelt werden müssen. Darüber hinaus müssen weitere wichtige Gesichtspunkte berücksichtigt werden wie die Wahl der zugrundeliegenden SMTP Implementierung und Sprache.
Dieser Punkt beinhaltet implizit einige der nachfolgend noch genannten Probleme.

7
Bachelorthesis/Content/LookOut/PraktischeProbleme/Spam.tex Normal file
View File

@ -0,0 +1,7 @@
Wie für jedes E-Mail System stellt sich die Frage der Spamabwehr und ob das vorgeschlagene System diese erschwert. Theoretisch sind zumindest zwischen den Knoten auf der Anonymisierungs-Route alle gewöhnlichen Mechanismen zur Spamabwehr möglich. Allerdings liegt das Problem weniger auf Ebene der Knoten. Auch wenn diese E-Mails zurückweisen können, die von nicht authentischen Absendern sind oder diverse Formvorgaben an eine MystMail nicht einhalten, können sie jedoch praktisch keine Aussage darüber machen, ob die E-Mail, die für den schlussendlichen Empfänger bestimmt ist, Spam ist. Denn diese kann nur der Empfänger entschlüsseln und einsehen.
Demnach kann eine Spam-Mail, die trotzdem eine korrekte MystMail ist, zwar beim Empfänger als solche erkannt werden, durchläuft aber dennoch die gesamte Anonymisierungs-Route und verursacht Traffic. Es muss untersucht werden, wie hoch das Potenzial einer Spam-Attacke ist, die DDoS-artige Auswüchse hat und eventuell das System als ganzes lahm legen könnte.
Im schlimmsten Fall könnten diese Probleme sogar zum Blacklisting eigentlich unschuldiger Endknoten führen, die ohne ihr Wissen Spam weiterleiten, da sie gewissermaßen als Open Relays fungieren.
Zumindest ist es denkbar, eine strikte Authentifizierung zwischen den Knoten zu etablieren, damit valide Knoten bekannt sind und verifiziert werden können. Dies würde auch teilweise das Problem von böswilligen Knoten lösen, die möglicherweise E-Mails nicht weiterleiten. Dafür ist ein sogenannter Directory Server von Nöten.

5
Bachelorthesis/Content/LookOut/PraktischeProbleme/Verify.tex Normal file
View File

@ -0,0 +1,5 @@
Obwohl es hier primär um das Unterdrücken und Verschleiern von Informationen geht, ist in praktischen E-Mail Systemen das Verifizieren der Authentizität von Verbindungen im Kontext des SMTP-Protokolls von hoher Bedeutung und das aus einer Vielzahl von Gründen.
Zum einen existiert, wie bereits erwähnt, das Problem der deformierten E-Mails und wie mit diesen umgegangen wird. Ebenso ist es möglich, auf IMF Ebene praktisch alle Headerfelder vorzutäuschen bzw. zu imitieren. Eine Teillösung hierfür wäre, alle Headerfelder mit DKIM \RefIt{rfc6376} zu schützen, was bedeutet, dass selbst ein MITM diese nicht verändern könnte, da die Verifikation beim empfangenden MTA fehlschlagen würde. Damit könnte auch das \verb#X-Myst-Mail# Headerfeld geschützt werden und es wäre nicht möglich, diesen zu entfernen.
Dabei muss allerdings untersucht werden, welche Auswirkungen die Nutzung von DKIM auf das Kryptografiesystem insgesamt hat und ob dies zu Informationsflüssen führen kann, die die Anonymität der kommunizierenden Parteien kompromittieren kann.

3
Bachelorthesis/Content/LookOut/PraktischeProbleme/Zuverlaessigkeit.tex Normal file
View File

@ -0,0 +1,3 @@
Ein E-Mail System ist nur nutzbar und praktikabel, wenn es einen hohen Grad an Zuverlässigkeit hat. Sowohl die Probleme der Fehlerbehandlung als auch die Verschlüsselung, das Routing und diverse Probleme bei der Spam-Abwehr können die Zuverlässigkeit des Systems beeinträchtigen.
Deshalb muss eine Protokollerweiterung bzw. ein Mechanismus entwickelt werden, der es erlaubt, ohne Verlust von Anonymität, das Erreichen einer E-Mail beim Empfänger bestätigen zu lassen. Denkbar wäre nach einem bestimmten Intervall auf eine Bestätigungsmail, welche über eine neue zufällige Route versendet wird, zu warten. Hier stellt sich allerdings die Frage, ob über die Intervalle statistische Analysen möglich sind. Ebenso kann die Bestätigungsmail fehlschlagen und nicht ankommen.

1
Bachelorthesis/Content/LookOut/TheoretischeProbleme.tex Normal file
View File

@ -0,0 +1 @@
Zu den theoretischen Problemen gehören vor allem die mathematisch und kryptografisch relevanten Details des Algorithmus und der Implementierung.

1
Bachelorthesis/Content/LookOut/TheoretischeProbleme/KryptografieSystem.tex Normal file
View File

@ -0,0 +1 @@
Weiterhin muss das Kryptografiesystem insgesamt betrachtet werden und Schwachstellen und Fehler untersucht werden, die bereits auf theoretischer Ebene ausgemacht werden können. Hierbei können u.U. auch ältere Arbeiten wie \QuoteM{Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms} \RefIt{Chaum:1981:UEM:358549.358563} von Nutzen sein. Diese Arbeit untersucht ein Kryptografiesystem zur sicheren E-Mail Kommunikation auf abstrakter Ebene und macht keine konkreten Aussagen über benutzte Protokolle.

4
Bachelorthesis/Content/LookOut/TheoretischeProbleme/PublicKey.tex Normal file
View File

@ -0,0 +1,4 @@
Neben der Wahl des Verschlüsselungsalgorithmus ist im selben Kontext das Problem eines Public-Key Systems äußerst relevant.
Dies beinhaltet mehrere Punkte. Zum einen muss noch spezifiziert werden, welches Schlüsselsystem (ein Paar aus öffentlichem und privatem Schlüssel) überhaupt verwendet wird. Weiterhin muss festgelegt werden, in welcher Weise die öffentlichen Schlüssel verbreitet werden. Dies könnte beispielsweise ähnlich wie bei DKIM \RefIt{rfc6376} erfolgen, welches die öffentlichen Schlüssel im DNS System hinterlegt \QuoteIndirect{rfc6376}{S. 6}. Diese können dann automatisch abgerufen werden. Zusätzlich kann DNSSEC \RefIt{rfc4035} verwendet werden, um das System insgesamt robuster zu machen. Denkbar ist allerdings auch ein Schlüsselsystem mit einer zentralen Autorität.

5
Bachelorthesis/Content/LookOut/TheoretischeProbleme/RoutingAlgo.tex Normal file
View File

@ -0,0 +1,5 @@
Für das Routing selbst wird ein Zufallsalgorithmus benötigt. Dieser sollte allerdings so spezifiziert werden, dass er es vermeidet, bereits ausgewählte Routen wiederzuverwenden. Ebenso muss der Grad der Entropie sichergestellt werden, beispielsweise durch eigens entwickelte Algorithmen und Verwendung mehrerer Entropie-Quellen.
Die Anzahl der Knoten, die mindestens benötigt werden, um eine adäquate Anonymisierung zu erreichen, muss ebenso festgelegt werden. Dies kann auch praktische Untersuchungen erfordern.
Hier könnten Details des Onion routing \RefIt{Syverson97anonymousconnections} \RefIt{torpaper} \RefIt{onionrouting1} \RefIt{onionrouting2} untersucht werden, welches vom Konzept her ähnlich ist.

5
Bachelorthesis/Content/LookOut/TheoretischeProbleme/Spezifikation.tex Normal file
View File

@ -0,0 +1,5 @@
\label{section:spezifikation}
Das Fehlen einer konkreten Spezifikation, bzw. einer Protokollerweiterung ist eines der Hauptprobleme dieser Arbeit, welches auch einige der vorher genannten Probleme mit einschließt. Erst wenn eine vollständige Spezifikation, beispielsweise in Form eines RFC, vorliegt, kann auf konkreter Ebene über Implementierungsprobleme, Logikfehler und Durchführbarkeit diskutiert werden.
Nach jetzigem Stand ist es lediglich möglich, über die Idee und algorithmischen Einzelteile einer möglichen Lösung zu diskutieren.

3
Bachelorthesis/Content/LookOut/TheoretischeProbleme/Verschluesselung.tex Normal file
View File

@ -0,0 +1,3 @@
Für die Verschlüsselung der MystMail selbst, also die Verschachtelung im Body der E-Mail, ist hier keine Spezifikation angegeben. Damit allerdings unterschiedliche E-Mail Server miteinander kommunizieren können, muss es entweder einen fest definierten Algorithmus geben oder es müssen durch genau spezifizierte Informationsweitergabe unterschiedliche Algorithmen unterstützt werden können. Im letzteren Fall würde dies die Fehlerbehandlung verkomplizieren, wenn ein empfangender E-Mail Server den Algorithmus zum Entschlüsseln der MystMail nicht beherrscht.
Ebenso muss das Verschlüsselungssystem adäquat mit einem Public-Key System verknüpft sein.

19
Bachelorthesis/Content/Problematik.tex Normal file
View File

@ -0,0 +1,19 @@
Wie durch Kapitel 1 erhellt wurde, sind die involvierten Protokolle für E-Mail Kommunikation äußerst verbose und übermitteln eine Menge an Metadaten und Inhaltsdaten. Standardmäßig werden alle diese Daten als Klartext übermittelt. Dazu gehören: Absender, Empfänger, Passwörter, Inhalt der E-Mail, etc. Dies bezieht sich auf nahezu alle Stationen, die eine E-Mail über das Internet durchläuft, mindestens aber folgende:
\begin{itemize}
\item MUA kommuniziert mit entfernten MSA
\item MTA kommuniziert mit entfernten MTA
\item MUA kommuniziert mit entfernten POP3/IMAP4 Server
\end{itemize}
Bei komplexeren Konfigurationen kann es sogar möglich sein, dass Informationen innerhalb einer Server-Konfiguration (z.B. entfernte Datenbank) sichtbar werden.
Um die Privatsphäre des Benutzers zu schützen, müssen so wenig Daten wie möglich und nur so viel wie nötig versendet werden. Die Daten, die gesendet werden müssen, sollten durch ein adäquates kryptografisches Verfahren verschlüsselt sein. Dies bezieht sich sowohl auf Metadaten als auch auf den Inhalt der E-Mail.
Nahezu alle existierenden Protokolle wie SMTP, IMAP4 und POP3 besitzen eine gewisse Unterstützung für kryptografische Methoden, die nachfolgend noch dargelegt werden. Allerdings können aufgrund der Beschaffenheit der genannten Protokolle immer noch Verbindungsdaten abgefangen werden, selbst wenn die Transaktionen (z.B. die SMTP Sitzung) kryptografisch verschlüsselt sind. Keines der existierenden E-Mail Protokolle bietet für letzteres eine adäquate Lösung. Dies ist nämlich das Problem der Anonymisierung von Metadaten, die nicht durch Verschlüsselung selbst versteckt werden können.
Anonymisierung von Metadaten in diesem Kontext unterscheidet sich also von der kryptografischen Verschlüsselung dadurch, dass, anstelle von Daten wie dem Inhalt einer Nachricht oder Transaktion, die Existenz der Transaktion oder Verbindung selbst für Außenstehende nicht nachvollziehbar ist, also die Verschleierung der Metadaten auf Netzwerkebene. Dies wird häufig über dedizierte Systeme erreicht, die über Routing-Algorithmen die Indirektion einer Verbindung vervielfachen. Diese Indirektion führt dazu, dass zum Nachvollziehen der Verbindung alle Stationen der Route bekannt sein müssen. Ein Beispiel eines solchen Algorithmus ist das \QuoteDirectNoPage{Onion Routing}{Syverson97anonymousconnections}.
Allerdings sind alle genannten Protokolle in der Lage, zumindest auf der Seite der kryptografischen Verschlüsselung etwas zu leisten.
Demnach liegt dieser Arbeit die Motivation zugrunde, das E-Mail System vor allem hinsichtlich der Anonymität für den Benutzer zu verbessern. Ob bestehende Systeme dies leisten können oder ob völlig neue Systeme entwickelt werden müssen, soll hier diskutiert werden.
In dem Zuge wird nachfolgend der aktuelle Stand der Verschlüsselung und Anonymität von E-Mail Kommunikation untersucht und die Anforderungen an eine adäquate Lösung formuliert.

75
Bachelorthesis/Content/Problematik/Anforderungen.tex Normal file
View File

@ -0,0 +1,75 @@
Nachfolgend werden die Anforderungen an eine adäquate Lösung formuliert. Dabei handelt es sich nicht um die Anforderungen an ein E-Mail System an sich, sondern um die Anforderungen, die relevant für größtmögliche Datensicherheit und Anonymität in einem bereits funktionierenden E-Mail System sind. Als System werden alle Komponenten bezeichnet, die beim Senden und Empfangen einer E-Mail involviert sind.
Die nachfolgenden Anforderungen sind rein funktional und beziehen sich lediglich auf Verschlüsselung und Anonymisierung.
\begin{longtable}{|c|m{12cm}|}
\hline
Nummer & Anforderung \\
\hline
\EmptyRow
\hline \endhead
\Textlabel{FA 1}{text:FA1} &
Das System muss dem Benutzer die Möglichkeit bieten,
den Textinhalt seiner E-Mail vor dem Versenden an den
MSA kryptografisch zu verschlüsseln. \\
\hline \Grayrow
\Textlabel{FA 2}{text:FA2} &
Das System muss dem Benutzer die Möglichkeit bieten,
die Transaktion zwischen MUA und MSA über eine
verschlüsselte Verbindung zu etablieren.\\
\hline
\hline
\Textlabel{FA 3}{text:FA3} &
Das System muss dem Benutzer die Möglichkeit bieten,
die Verbindungsdaten der Transaktion zwischen MUA und
MSA zu anonymisieren.\\
\hline \Grayrow
\Textlabel{FA 4}{text:FA4} &
Das System muss dem Benutzer die Möglichkeit bieten,
die Transaktion zwischen MUA und POP3/IMAP Server
über eine verschlüsselte Verbindung zu etablieren.\\
\hline
\hline
\Textlabel{FA 5}{text:FA5} &
Das System muss dem Benutzer die Möglichkeit bieten,
die Verbindungsdaten der Transaktion zwischen MUA und
POP3/IMAP Server zu anonymisieren.\\
\hline \Grayrow
\Textlabel{FA 6}{text:FA6} &
Das System muss dem Benutzer die Möglichkeit bieten,
den Versand und die Zustellung der E-Mail auf MTA-Ebene
nur über verschlüsselte Verbindungen zu erlauben.\\
\hline
\hline
\Textlabel{FA 7}{text:FA7} &
Das System muss dem Benutzer die Möglichkeit bieten,
den Versand und die Zustellung der E-Mail auf MTA-Ebene
nur über anonymisierte Verbindungen zu erlauben.\\
\hline
\CaptionLongtable{Funktionale Anforderungen}
\label{tab:FunctionalRequirements}
\end{longtable}
Die nachfolgenden Anforderungen sind nicht funktional und beziehen sich auf mögliche Probleme, die aus der Implementierung der genannten funktionalen Anforderungen entstehen könnten.
\begin{longtable}{|c|m{12cm}|}
\hline
Nummer & Anforderung \\
\hline
\EmptyRow
\hline \endhead
\Textlabel{NFA 1}{text:NFA1} &
Das System muss kompatibel mit den Protokollen
SMTP, POP3 und IMAP sein.\\
\hline \Grayrow
\Textlabel{NFA 2}{text:NFA2} &
Das System sollte die bereits existierenden Methoden
zur Spam-Abwehr nicht erschweren. \\
\hline
\CaptionLongtable{Nicht-Funktionale Anforderungen}
\label{tab:NonFunctionalRequirements}
\end{longtable}
Wie zu erkennen ist, folgt aus den funktionalen Anforderungen der Versuch, nicht nur Teile des E-Mail Verkehrs zu verschlüsseln und anonymisieren, sondern das System als ganzes. Da das betrachtete System bestehend aus den Protokollen SMTP, POP3 und IMAP aber aus verschiedenen Einzelteilen besteht, müssen die Lösungen auch spezifisch auf die jeweiligen Teilsysteme bezogen sein. Das bedeutet ebenso, dass ein direkter Bezug zu konkreten Protokollen besteht und dies keine abstrakte Anforderungsliste an irgendein E-Mail System ist.
Die nichtfunktionalen Anforderungen beschäftigen sich hingegen mit der Kompatibilität und der praktischen Einsetzbarkeit des Systems. Diese Komponenten spielen eine wichtige Rolle für eine mögliche Akzeptanz einer Lösung.

1
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz.tex Normal file
View File

@ -0,0 +1 @@
Dieser Abschnitt betrachtet den Datenschutz von aktuellen SMTP-basierten E-Mail Systemen hinsichtlich der Verschlüsselung und Anonymität.

5
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Anonymitaet.tex Normal file
View File

@ -0,0 +1,5 @@
Wie bereits erwähnt bezeichnet Anonymität im Kontext dieser Arbeit das Verschleiern von Metadaten. Nicht immer ist die Trennung von Inhaltsdaten und Metadaten streng nachvollziehbar. So ist es beispielsweise diskutierbar, ob die allgemeinen Informationen einer SMTP Sitzung ohne Betrachtung der E-Mail Nachricht selbst als Metadaten gelten. Als Metadaten im Kontext dieses Kapitels sind aber vor allem Verbindungsdaten wie IP-Adressen gemeint.
Das SMTP Protokoll sowie die Protokolle POP3 und IMAP liefern über ihre Spezifikation keinerlei Methoden eine solche Anonymisierung durchzuführen. Ebenso sind keine Protokoll-Erweiterungen bekannt, die dieses leisten.
Allerdings sind protokollunabhängige Lösungen möglich. Eine davon ist die MUA-Erweiterung \QuoteM{TorBirdy}.

28
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Anonymitaet/TorBirdy.tex Normal file
View File

@ -0,0 +1,28 @@
\QuoteM{TorBirdy} \RefIt{torbirdyhp} \RefIt{torbirdy} ist eine Erweiterung für den MUA \QuoteDirectNoPage{Mozilla Thunderbird}{thunderbirdhp} mit dem Ziel die Kommunikation folgender Komponenten zu anonymisieren:
\begin{itemize}
\item MUA kommuniziert mit entfernten MSA
\item MUA kommuniziert mit entfernten POP3/IMAP4 Server
\end{itemize}
Dies sind zwei von den eingangs drei erwähnten Angriffspunkten.
Das Prinzip von TorBirdy ist, den gesamten Datenverkehr der Kommunikation von Thunderbird mit dem E-Mail Server über das Tor-Netzwerk \RefIt{torpaper} zu leiten.
Das Tor-Netzwerk selbst ist allerdings abstrakter als dieser Anwendungsfall. Es erlaubt allgemein das Anonymisieren von TCP-Verbindungen jeglicher Art. Dieses wird wiederum auf Basis des \QuoteM{Onion Routings} \RefIt{onionrouting1} \RefIt{onionrouting2} realisiert. Das Onion Routing läuft grob in folgenden Schritten ab \QuoteIndirectNoPage{onionrouting2}:
\begin{enumerate}
\item der initiale Sender wählt von einem sogenannten Verzeichnisserver (engl. \QuoteM{directory node}) eine geordnete, aber zufällige Liste von Knoten aus, welche den Pfad bilden, den die Daten bis zum schlussendlichen Empfänger nehmen
\item vom Verzeichnisserver wird ein öffentlicher Schlüssel (asymmetrisches Verschlüsselungsverfahren) für den ersten Knoten bezogen, der sogenannte Eintrittsknoten (engl. \QuoteM{entry node})
\item eine Verbindung wird hergestellt und ein Sitzungsschlüssel (symmetrisches Verschlüsselungsverfahren) erstellt
\item über die erstellte Verbindung kann der Sender eine Nachricht an einen zweiten Knoten senden, die allerdings mit dessen öffentlichem Schlüssel verschlüsselt wurde und somit nicht vom Eintrittsknoten entschlüsselt werden kann
\item der zweite Knoten verbindet sich dazu mit dem ersten Knoten und ist somit indirekt mit dem Sender verbunden, ohne davon Wissen zu haben
\item diese Verbindung kann jetzt zu einem dritten, vierten, usw. ... Knoten erweitert werden
\item der schlussendliche Empfänger benutzt dieselbe Reihe von Knoten zurück zum Sender, nur umgekehrt
\end{enumerate}
Dieses Konzept wird \QuoteM{Onion Routing} genannt, da hier eine verschachtelte Verschlüsselung vorliegt, die nach und nach beim Weiterreichen an den jeweils nächsten Knoten wie eine Zwiebel geschält wird. Die Nachrichten für jede Schicht sind mit dem öffentlichen Schlüssel für exakt diese Schicht verschlüsselt, sodass kein Knoten in der Mitte den vollständigen Pfad herausfinden kann.
Zu jedem Zeitpunkt hat jeder Knoten nur Wissen über den vorherigen Knoten und den nachfolgenden Knoten. Der erste Knoten ist immer der Eintrittsknoten und der letzte der Austrittsknoten (engl. \QuoteM{exit node}). Die Verbindungspfade werden im Tor-Netzwerk in regelmäßigen Abständen geändert. Das Tor-Netzwerk selber benutzt intern konsistent TLS Verschlüsselung.
Dieses Konzept wird vor allem im WWW benutzt, über den sogenannten \QuoteM{Tor Browser} \RefIt{torbrowserhp}.
TorBirdy macht allerdings in derselben Weise Gebrauch davon, bleibt aber kompatibel mit den Protokollen SMTP, POP3 und IMAP.
Anzumerken ist, dass der Versand von E-Mails auch über Weboberflächen möglich ist und somit eine gewöhnliche Verbindung über den Tor Browser verwendet werden kann. Allerdings gibt es auch diverse Gründe dies für vollwertige MUAs zu ermöglichen \QuoteIndirect{torbirdy}{S. 4}.

2374
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.dia Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 32 KiB

18
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.tex Normal file
View File

@ -0,0 +1,18 @@
Nahezu alle Datenschutzmechanismen für E-Mails sind erst wesentlich später als die ursprünglichen Protokolle wie SMTP entstanden und haben sich mit der Zeit entwickelt. Viele der vorgestellten Technologien sind unabhängige Lösungen, die lediglich in Verbindung mit E-Mail Systemen verwendet werden können, andere sind wiederum Protokollerweiterungen, die sich mehr oder weniger sinnvoll in das Gesamtkonzept einfügen. Sichtbar anhand der untersuchten Technologien ist allerdings, dass hier keine konsistente Lösung vorliegt. Jede Lösung zielt auf einen anderen Bereich ab und versucht ein atomares Problem zu lösen, ohne dabei auf die Kohärenz eines in der Praxis eingesetzten E-Mail Systems achten zu können. Dies öffnet unabhängig vom Kohärenzproblem auch das Problem der Konfiguration eines konkreten Systems. Die immense Komplexität der zusammenspielenden Komponenten wurde in Kapitel 1 erhellt und ist ein praktisches Problem solcher Systeme.
Dennoch ist es möglich die genannten Systeme zu nutzen, um eine Reihe von Problemen bezüglich Datensicherheit zu lösen. Um die Inhaltsdaten des Bodies einer E-Mail für jeden außer der Empfängerperson unzugänglich zu machen, kann das asymmetrische Verschlüsselungsverfahren GPG benutzt werden. Selbst der Server-Betreiber oder ein Man-in-the-Middle ist dann nicht in der Lage, die E-Mail ohne weiteres zu entschlüsseln, unabhängig davon, in welcher Weise diese transportiert wurde. Allerdings bezieht sich GPG nur auf den Body einer E-Mail und nicht auf die Header. Ebenso ist es möglich, die Protokoll-Transaktionen von SMTP, POP3 und IMAP über direktes TLS oder STARTTLS zu verschlüsseln. Problematisch hierbei ist aber, dass eine verschlüsselte Verbindung nicht durchgängig garantiert werden kann, z.b. wenn die Verbindung über mehrere MTAs geht oder wenn der E-Mail Server erlaubt zu unverschlüsselten Verbindungen herunterzustufen, insbesondere über SMTP STARTTLS. Und letzten Endes ist eine gewisse Anonymisierung der IP-Verbindungsdaten über TorBirdy möglich. Diese gilt allerdings nur für die Kommunikation des MUA mit dem MSA bzw. POP3/IMAP server.
\autoref{fig:bewertung} zeigt sehr deutlich, dass selbst beim Einsatz all dieser Technologien und unter der Voraussetzung korrekter Konfiguration immer noch eine wesentliche Stelle nicht ausreichend anonymisiert oder verschlüsselt werden kann. Dies ist nämlich die Kommunikation zwischen mehreren MTAs. Hier kann durchgängig nicht angenommen werden, dass Transaktionen verschlüsselt sind. Ebenso sind die Verbindungen direkt und weiterleitende E-Mail Server werden über den \verb#Received# Header gekennzeichnet. Somit ist es ohne viel Aufwand möglich, den Weg, den eine E-Mail nimmt, nachzuverfolgen und zumindest die kommunizierenden E-Mail Server eindeutig zu bestimmen. Die Menge an offenen Metadaten an dieser Stelle ist so hoch, dass hier keine Gesamtlösung zu erkennen ist und u.U. Sender und Empfänger direkt identifiziert werden können.
Allerdings ist festzuhalten, dass abgesehen von der mangelnden Verschleierung der Kommunikation zwischen MTAs, die existierenden Technologien die Basis einer Gesamtlösung bilden können.
\begin{figure}[htb]
%\Centerfloat
\centering
\includegraphics[scale=0.4]{Content/Problematik/BetrachtungDatenschutz/Bewertung.png}
\caption{Übersicht Datenschutz in E-Mail Systemen}
\label{fig:bewertung}
\end{figure}
\vfill
\clearpage

5
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung.tex Normal file
View File

@ -0,0 +1,5 @@
Mit Verschlüsselung sind kryptografisch-mathematische Methoden gemeint, um Nachrichten (z.B. Text) in eine neue Form zu bringen, die nicht ohne weiteres (z.B. ohne Schlüssel) in die ursprüngliche Form gebracht werden kann.
Bei der Betrachtung der Verschlüsselung von E-Mail Verkehr muss erst definiert werden welche Teile des Verkehrs verschlüsselt werden. Hier gibt es mehrere Schichten. Die erste Schicht sind die Inhaltsdaten der E-Mail, gewissermaßen der Body und eventuell auch die Header. Die zweite Schicht ist die Sitzung zwischen E-Mail Server und Client. Dies gilt für alle involvierten Protokolle SMTP, POP3 und IMAP4, die diese Verschlüsselung unterstützen müssen, um die einzelnen Kommandos vom Client zum Server und die Antworten vom Server zum Client über einen kryptografischen Kanal zu transferieren.
Zunächst werden Technologien bezüglich der Verschlüsselung des E-Mail Bodies betrachtet und nachfolgend Technologien auf Protokoll-Ebene untersucht. Dabei werden auch Probleme dieser Verfahren und Methoden aufgezeigt.

30
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/GPG.tex Normal file
View File

@ -0,0 +1,30 @@
\QuoteDirectNoPage{GNU Privacy Guard}{gnupghp} ist eine vollständige und freie Implementierung des OpenPGP Standards, der in RFC 4880 \RefIt{rfc4880} definiert ist.
Es handelt hier sich um ein Verschlüsselungsverfahren, das asymmetrische Public-Key Verfahren mit symmetrischen Verfahren kombiniert \QuoteIndirect{rfc4880}{S. 1}.
Ein symmetrisches Verschlüsselungsverfahren benutzt nur einen einzigen Schlüssel für das Verschlüsseln und Entschlüsseln. Dieser muss also beiden Kommunikationspartnern zur Verfügung stehen, darf aber niemand anderem zugänglich sein. Die Übertragung eines solchen Schlüssels wird deshalb häufig über ein asymmetrisches Verschlüsselungsverfahren bewerkstelligt.
% toref
Ein asymmetrisches Public-Key Verfahren besteht auf Sender -und Empfänger-Seite jeweils aus einem Schlüsselpaar. Dieses setzt sich aus einem öffentlichen und einem privaten Schlüssel zusammen, die gemeinsam generiert werden. Nur die öffentlichen Schlüssel werden ausgetauscht und erlauben der jeweils anderen Partei für den Besitzer des Schlüsselpaars zu verschlüsseln. Der private Schlüssel wird vom Besitzer zum Entschlüsseln benutzt und kann mit einem Passwort geschützt sein.
% toref
\begin{figure}[htb]
%\Centerfloat
\centering
\includegraphics[scale=0.4]{Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.png}
\caption{Asymmetrisches Verschlüsselungsverfahren in der Praxis}
\label{fig:asymcrypto}
\end{figure}
\autoref{fig:asymcrypto} stellt schematisch einen vereinfachten Ablauf einer verschlüsselten einseitigen Kommunikation von Bob zu Alice dar, basierend auf dem asymmetrischen Verschlüsselungsverfahren. Beide Parteien benötigen zunächst ein Schlüsselpaar, welches lokal generiert wird. Danach müssen die Parteien die benötigten öffentlichen Schlüssel austauschen. Dies kann manuell oder über einen öffentlichen Server geschehen. Als nächsten Schritt benutzt Bob den öffentlichen Schlüssel von Alice, um die Nachricht für Alice zu verschlüsseln. Dann verschlüsselt und sendet er diese. Anschließend benutzt Alice ihren privaten Schlüssel um die Nachricht zu entschlüsseln. \QuoteIndirect{Ferguson:2003:PC:862106}{Kapitel 3.3}
Hierbei kommt die Frage auf, woher Bob weiß, dass er den korrekten öffentlichen Schlüssel von Alice besitzt, wenn er diesen über einen öffentlichen Server geladen hat. Um dies festzustellen, wird ein \QuoteM{Secure Hash Algorithm} benutzt, der gewissermaßen den Fingerabdruck des öffentlichen Schlüssels darstellt. Bob kann nun Alice über einen sicheren Kanal kontaktieren (z.B. persönlich) und fragen, ob ihr Fingerabdruck des öffentlichen Schlüssels dem entspricht, den er lokal sieht. Aufgrund der Kollisionsunwahrscheinlichkeit von z.B. SHA-1 erlaubt dies eine sinnvolle Aussage über die Echtheit des öffentlichen Schlüssels, den Bob heruntergeladen hat. \QuoteIndirect{Ferguson:2003:PC:862106}{Kapitel 6.2.2}
GPG ist im Ablauf also ähnlich wie \autoref{fig:asymcrypto}, benutzt allerdings auch das symmetrische Verschlüsselungsverfahren in dem Verschlüsselungsprozess. Beim Sender wird dabei die Nachricht selbst lediglich über das symmetrische Verfahren mit einem einmaligen \QuoteM{session key} verschlüsselt. Dieser \QuoteM{session key} wird dann mit dem öffentlichen Schlüssel des Empfängers über das asymmetrische Verschlüsselungsverfahren verschlüsselt. Der symmetrische Schlüssel wird dann am Anfang der Nachricht mitgeschickt. Der Empfänger muss dann erst mit seinem privaten Schlüssel den \QuoteM{session key} entschlüsseln und dann mit diesem die eigentliche Nachricht. Dies geschieht natürlich auf Programmebene und wird nicht manuell vom Benutzer durchgeführt. \QuoteIndirect{rfc4880}{S. 6}
Anzumerken ist, dass GPG nicht nur für Verschlüsselung, sondern auch für Signierung benutzt werden kann. Damit kann der Absender einer Nachricht kryptografisch verifiziert werden. \QuoteIndirect{rfc4880}{S. 7}
GPG wird in der Praxis vielfältig benutzt. Dazu gehört das manuelle Verschlüsseln von Dateien für Andere, das Signieren von \QuoteM{git commits}
und das Verschlüsseln des Nachrichteninhaltes einer E-Mail.
Angenommen, die E-Mail selber ist über das SMTP Protokoll in sicherer Weise weitergeleitet worden, ohne dass ein Dritter diese verändern oder sehen konnte. Wenn die E-Mail auf dem Zielserver eintrifft, liegt sie dort dennoch als Klartext vor und wird durch die verschiedenen Komponenten innerhalb des Servers durchgereicht. Ist der E-Mail Server kompromittiert, so ist auch die Nachricht kompromittiert. Ist die Nachricht allerdings GPG-verschlüsselt, so ist dies nicht der Fall. Zumindest nicht für den Body.

33
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/STARTTLS.tex Normal file
View File

@ -0,0 +1,33 @@
STARTTLS ist eine Erweiterung für eine Reihe von Text-basierten Protokollen wie IMAP, POP3 und SMTP, aber auch FTP oder LDAP. Für IMAP und POP3 wurde diese in RFC 2595 \RefIt{rfc2595} definiert und für SMTP in RFC 3207 \RefIt{rfc3207}. Die Erweiterung benutzt das TLS Protokoll, hat aber im Vergleich zu einer gewöhnlichen TLS Kommunikation ein paar entscheidende Unterschiede:
\begin{itemize}
\item die Verbindung wird zunächst unverschlüsselt initiiert
\item nach der Begrüßung antwortet der Server, dass er über STARTTLS verfügt und der Client kann eine TLS verschlüsselte Verbindung initiieren und anschließend z.B. Logindaten senden
\item es wird kein dedizierter SSL Port benötigt
\item STARTTLS ist allerdings protokollspezifisch
\end{itemize}
Nachfolgend eine SMTP-basierte STARTTLS Verbindung:
\begin{mail}{SMTP-STARTTLS}{SMTP-STARTTLS}
S: <wartet auf TCP Port 25>
C: <öffnet Verbindung>
S: 220 service ready
C: EHLO bauer.de
S: 250-bauer.de welcome
S: 250-STARTTLS
C: STARTTLS
S: 220 Go ahead
C: <startet TLS Verhandlung>
C & S: <Verhandlung einer TLS Sitzung>
C & S: <Überprüfen des Ergebnisses>
...
\end{mail}
Ab Zeile 12 ist die Verbindung verschlüsselt und der Server kann beispielsweise über \verb#AUTH PLAIN# eine Klartext-basierte Authentifizierung anfordern, da diese nun innerhalb der verschlüsselten Verbindung sicher ist.
Die Vorteile von STARTTLS sind einmal, dass keine zusätzlichen Ports benötigt werden, aber auch, dass optional eine unverschlüsselte Verbindung weitergeführt werden kann. Da dies aber häufig unerwünscht ist, ist es bedingt möglich den Server so zu konfigurieren, dass eine nachfolgende TLS Verbindung erforderlich ist \QuoteIndirect{rfc2595}{S. 3} \QuoteIndirect{rfc3207}{S. 3}. Für POP3/IMAP in Verbindung mit STARTTLS müssen Server so konfigurierbar sein, dass eine erfolgreiche TLS Verbindung etabliert sein muss, bevor jede Art von Benutzerauthentifizierung stattfindet \QuoteIndirect{rfc2595}{S. 3}. Auf SMTP Ebene ist es nur für Server erlaubt, die nicht \QuoteDirect{publicly-referenced}{rfc3207}{S. 3} sind, TLS Verschlüsselung zu erzwingen.
Zu den Nachteilen gehört allerdings, dass bei STARTTLS mehr Metadaten verbreitet werden als bei direkter TLS Verbindung auf einem alternativen Port. Da die Verbindung initial unverschlüsselt ist, erlaubt dies auch weitere Angriffsvektoren wie z.b. \QuoteDirect{STARTTLS Command Injection Attack (CVE-2011-0411)}{rfc7457}{S. 4}, bei denen u.a. versucht werden kann, die Verbindung während der kurzen Periode von Klartextkommunikation herunterzustufen, indem das \verb#STARTTLS# Kommando vom Client gar nicht erst den Server erreicht. Dies hängt aber auch wie schon eingangs erwähnt von der Serverkonfiguration ab. Ebenso sagt die Spezifikation nicht aus wie ein Client sich exakt zu verhalten hat, wenn eine STARTTLS Verbindung fehlschlägt: \QuoteDirect{If the TLS negotiation fails or if the client receives a 454 response, the client has to decide what to do next. There are three main choices: go ahead with the rest of the SMTP session, retry TLS at a later time, or give up and return the mail to the sender.}{rfc3207}{S. 6}.
Dies bedeutet, dass der Client theoretisch versuchen kann, mit einer Klartext-Verbindung fortzufahren.
Dies muss auf Clientebene gelöst werden und entsprechende Konfigurationsoptionen angeboten werden, ist aber nicht garantiert.
Trotz der genannten Probleme ist STARTTLS das einzige Protokoll, das einen TLS-basierten Verbindungsaufbau von SMTP, POP3 und IMAP Servern überhaupt spezifiziert, im Gegensatz zu den Pseudoprotokollen SMTPS, POP3S und IMAPS, die keine konkrete Spezifikation haben und das Verhalten zwischen Client und Server demnach von Implementierungsdetails abhängt.

14
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/TLS.tex Normal file
View File

@ -0,0 +1,14 @@
TLS bezeichnet das Protokoll \QuoteM{Transport Layer Security}, welches im RFC 5246 \RefIt{rfc5246} definiert ist. Es ist ein Protokoll auf Applikationsebene, welches den Datenschutz und die Datenintegrität zweier kommunizierender Applikationen sicherstellen soll. Dabei besteht es aus zwei Schichten, einerseits aus dem \QuoteM{TLS Record Protocol} und dem \QuoteM{TLS Handshake Protocol}. \QuoteIndirect{rfc5246}{S. 4}
Das \QuoteM{TLS Record Protocol} stellt dabei die unterste Schicht dar, direkt über dem TCP Protokoll und stellt sicher, dass die Verbindung selbst verschlüsselt ist. Dies findet über ein symmetrisches Verschlüsselungsverfahren statt. Dabei ist der gemeinsame Schlüssel auf die Laufzeit einer Sitzung begrenzt. Ferner definiert dieses Protokoll wie die Integrität von Nachrichten über Hashfunktionen wie SHA-1 sichergestellt wird. \QuoteIndirect{rfc5246}{S. 4}
Das \QuoteM{TLS Handshake Protocol} hingegen ist im \QuoteM{TLS Record Protocol} eingebettet und übernimmt die Funktion der Authentifizierung. Auf dieser Ebene fällt ebenso die Entscheidung, welcher Verschlüsselungsalgorithmus benutzt wird und der Austausch der kryptografischen Schlüssel. Erst nach diesem Prozess wird die eigentliche Sitzung aktiv und Sitzungsdaten können gesendet werden. Dieser Prozess findet über asymmetrische Verschlüsselung basierend auf dem Public-Key Verfahren statt. Darauf basierend ist dann der Austausch des symmetrischen Sitzungsschlüssels sicher. \QuoteIndirect{rfc5246}{S. 4}
Der öffentliche Schlüssel des Servers wird in der Praxis häufig von einem weiteren öffentlichen Schlüssel einer sogenannten \QuoteM{Certificate Authority} signiert. Die verbindende Gegenstelle muss also nur dem Schlüssel der Certificate Authority vertrauen. Applikationen wie Webbrowser liefern häufig ein Paket von vertrauten Schlüsseln solcher Certificate Authorities mit. Öffentliche Schlüssel können allerdings auch \QuoteM{self-signed} sein ohne Verbindung zu einer Certificate Authority. Diese müssen dann allerdings beim Empfänger manuell verifiziert und zugelassen werden.
\QuoteIndirect{Ferguson:2003:PC:862106}{Kapitel 19 bis 21}
Die Schwächen und Probleme des TLS Protokolls und des darüber liegenden Zertifikats-Systems im einzelnen zu analysieren würde den Rahmen dieser Arbeit sprengen. Einige der bekannten Angriffe auf das Protokoll wurden in RFC 7457 \RefIt{rfc7457} veröffentlicht. Für einige davon existieren Lösungen, entweder durch Konfigurationsänderungen am Server-System oder durch Erweiterungen der TLS Spezifikation.
Festzuhalten ist aber lediglich, dass TLS das wohl am weitesten verbreitete Verfahren ist, um die Kommunikation im WWW, aber auch die Kommunikation von und zu E-Mail Servern zu verschlüsseln und das Problem eines \QuoteM{Man-in-the-Middle-Angriff}, kurz MITMA \RefIt{mitm}, zu lösen.
Die Protokolle SMTPS, POP3S und IMAPS sind also nur Bezeichner für die Protokolle SMTP, POP3 und IMAP, die auf den dedizierten Ports 465, 995 und 993 ansprechbar sind und nur über das TLS Protokoll ansprechbar sind. Für diese existiert keine konkrete Spezifikation.

1964
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.dia Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

418
Bachelorthesis/Content/Settings.tex Normal file
View File

@ -0,0 +1,418 @@
% set font to sans-serif
\renewcommand{\familydefault}{\sfdefault}
\usepackage[left=3.5cm,right=3.0cm,top=2cm,bottom=3cm]{geometry} % Page margins
\usepackage[ngerman]{babel} % Better line breaking
\usepackage[utf8]{inputenc} % Utf8 recognition
\usepackage[T1]{fontenc} % Translate from latex code to draw font
\usepackage{lmodern} % Bolder font
\usepackage{graphicx} % Display images
\usepackage{fancyhdr} % Header/footer
\usepackage[pdfborder={0 0 0}]{hyperref} % Links without visible lines
\usepackage[table]{xcolor} % Get the color in the table
\usepackage{pdflscape} % Get the table into landscape mode
\usepackage[lastpage]{zref} % Set a lable on the last page
\usepackage{listings} % Display formatted code
\usepackage{makeidx} % Generates the index
\usepackage{acronym} % Generates the list of abbreviations
\usepackage{multicol} % List of abbreviations with two columns
\usepackage{bibgerm} % BibTex German Style DIN 1505
\usepackage{longtable} % Multi page tables
\usepackage[onehalfspacing]{setspace}
% Tell LaTeX to generate an index
\makeindex
% No indent @ line start
\parindent 10pt
%\parskip2ex
% The bibstyle
% gerplain is for only numbers in alphabetic order
% geralpha is for name+year in alphabetic order
\bibliographystyle{gerplain}
% Header
\pagestyle{fancy}
\fancypagestyle{plain}{}
\fancyhead[RO,RE]{Seite \thepage\ von\reallastpage}
\fancyhead[LO,LE]{\leftmark}
% Set the lastpage counter -1
% So the statutory declaration is not part of the page counter
\makeatletter
\newcommand{\reallastpage}{
\the \numexpr \zref@extractdefault{LastPage}{page}{0}-1\relax
}
\makeatother
% Header for starting section
\fancypagestyle{rightmark}{
\fancyhead[LO,LE]{\rightmark}
}
% Empty footer
\cfoot{}
% Brake long url in cite
\def\UrlBreaks{\do\/\do-}
% Suppress clubs (Schusterjungen)
\clubpenalty = 10000
% Suppress widows (Hurenkinder)
\widowpenalty = 10000
% Suppress widows in front of a formular
\displaywidowpenalty = 10000
% Macro for centering extreme wide tables/figures
\makeatletter
\newcommand*{\centerfloat}{%
\parindent \z@
\leftskip \z@ \@plus 1fil \@minus \textwidth
\rightskip\leftskip
\parfillskip \z@skip}
\makeatother
%------------------------------------------------------------------------------
% Macro for reusing sume text:
%------------------------------------------------------------------------------
% Use to define some text and then re use the very same text
% \ref{sth:bla}
% \textlabel{Something AAA}{sth:bla}
\makeatletter
\newcommand*{\Textlabel}[2]{%
\edef\@currentlabel{#1}% Set target label
\phantomsection% Correct hyper reference link
#1\label{#2}% Print and store label
}
\makeatother
%------------------------------------------------------------------------------
% Macro for the title:
%------------------------------------------------------------------------------
% The full title
\newcommand*{\Title}{\TitleFirstLine~\TitleSecondLine}
% Only the first line of the title
\newcommand*{\TitleFirstLine}{Betrachtung von Datensicherheit in E-Mail Systemen und Entwicklung eines SMTP-basierten Anonymisierungs-Algorithmus}
% Only the second line of the title
\newcommand*{\TitleSecondLine}{}
%------------------------------------------------------------------------------
% Macros for the list of abbreviations:
%------------------------------------------------------------------------------
% To wirte the text only once
\newcommand*{\ListOfAbbreviations}{Abkürzungsverzeichnis}
% use reversed form
\makeatletter
\renewcommand*{\@acf}[1]{%
\ifAC@footnote
\acsfont{\AC@acs{#1}}%
\footnote{\AC@placelabel{#1}\hskip\z@\AC@acl{#1}{} }%
\else
\acsfont{% Orig:\acffont
\AC@placelabel{#1}\hskip\z@\AC@acs{#1}%Orig: \AC@acl{#1}
\nolinebreak[3] %
\acfsfont{(\acffont{\AC@acl{#1}})}%Orig: (\acsfont{\AC@acs{#1}})
}%
\fi
\ifAC@starred\else\AC@logged{#1}\fi
}
\makeatother
%------------------------------------------------------------------------------
% Macros for the the Index:
%------------------------------------------------------------------------------
% The thickness of the line between the columns of the index and the list of
% Abbreviations; 0.4 pt is the LaTeX standart
\newcommand*{\LineThickness}{0.4 pt}
% Display twoculums with vertical seperator line
\makeatletter
\renewenvironment{theindex}
{\if@twocolumn
\@restonecolfalse
\else
\@restonecoltrue
\fi
\setlength{\columnseprule}{\LineThickness} % Thikness of the columnseprule
\setlength{\columnsep}{35 pt}
\begin{multicols}{2}[\chapter*{\indexname}] % Amount of Columns
\markboth{\MakeUppercase\indexname}%
{\MakeUppercase\indexname}%
\thispagestyle{plain}
\setlength{\parindent}{0pt}
\setlength{\parskip}{0pt plus 0.3pt}
\relax
\let\item\@idxitem}%
{\end{multicols}\if@restonecol\onecolumn\else\clearpage\fi}
\makeatother
%------------------------------------------------------------------------------
% Macros for table colors and longtables:
%------------------------------------------------------------------------------
% Table gray row
\newcommand*{\Grayrow}{\rowcolor{gray!35}}
% Table red cell
\newcommand*{\Redcell}{\cellcolor{red!30}}
% Table green cell
\newcommand*{\Greencell}{\cellcolor{green!30}}
% Generates a small empty row in a longtable
\newcommand*{\EmptyRow}{\multicolumn{0}{l}{} \\[-9pt]}
% Needs to be @ the end of the longtable,
% generates a caption with correct spacing
% @par1: the text of the caption
\newcommand*{\CaptionLongtable}[1]
{\multicolumn{0}{l}{} \\[-3pt]\caption{#1}}
%------------------------------------------------------------------------------
% Macros for quotes:
%------------------------------------------------------------------------------
% A direct quote
% @par1: The quoted text
% @par2: The source where the text is from
% @par3: The page where the text is from
\newcommand*{\QuoteDirect}[3]{\QuoteM{\emph{#1}} \cite[#3]{#2}}
% A direct quote without page
% @par1: The quoted text
% @par2: The source where the text is from
\newcommand*{\QuoteDirectNoPage}[2]{\QuoteM{\emph{#1}} \cite{#2}}
% A indirect quote
% @par1: The source where the text is from
% @par2: The page where the text is from
\newcommand*{\QuoteIndirect}[2]{(vgl. \cite[#2]{#1})}
% A indirect quote without page
% @par1: The source where the text is from
\newcommand*{\QuoteIndirectNoPage}[1]{(vgl. \cite{#1})}
% A reference
% @par1: The source where the text is from
\newcommand*{\RefIt}[1]{\cite{#1}}
% A text with quotation marks
% @par1: The text you want to quote
% »text«
\newcommand*{\QuoteM}[1]{\frqq #1\flqq}
% A text with single quotation marks
% @par1: The text you want to quote
% ›text‹
\newcommand*{\QuoteMs}[1]{\frq #1\flq}
% To adjust some words to the flow
% @par1: the adjusted words
% [text]
\newcommand*{\AdjustWords}[1]{{\normalfont[#1]}}
% Displays a reference to the given object
% @par1: the lable of the thing you want to see
% (Siehe auch Abbildung 1.1 »Ein Bild« auf Seite 4)
\newcommand*{\See}[1]
{(Siehe auch \autoref{#1} \QuoteM{\nameref{#1}} auf \autopageref{#1})}
% Displays a reference to an equation
% @par1: the lable of the equation you want to see
% (Siehe auch Gleichung 1.1 in »Dummy Section« auf Seite 5)
\newcommand*{\SeeEq}[1]
{(Siehe auch \autoref{#1} in \QuoteM{\nameref{#1}} auf \autopageref{#1})}
% The symbol for a elision
% Is used for more than missings one word or a sentence
% [...]
\newcommand*{\Elision}{{\normalfont[\dots]}}
% The symbol for a small elision
% Is used for only one missing word
% [..]
\newcommand*{\ElisionSmall}{{\normalfont[..]}}
% This is used if a book is cited at whole
% passim means something like continuous
% text (vgl. [Aut99, passim]).
\newcommand*{\passim}{passim}
% To show the audience that there is something
% To display a wrong/importen part but not corrected in the quote
% text error [sic!] text
\newcommand*{\SIC}{{\normalfont[sic!]}}
% The text for a note from the author
% text, Anm. d. Autors
\newcommand*{\NoteFromAuthor}{{\normalfont\unskip , Anm. d. Autors}}
% Space btween \item in itemize
\newcommand*{\Itemizespace}{0 pt}
%------------------------------------------------------------------------------
% Listings:
%------------------------------------------------------------------------------
% Change the text from a listings caption
\renewcommand*{\lstlistingname}{Code}
% Change the text from the \autoref
\def\lstlistingautorefname{\lstlistingname}
% Change the text from the list of listings
\renewcommand*{\lstlistlistingname}{Codeverzeichnis}
\lstset{literate=%
{Ö}{{\"O}}1
{Ä}{{\"A}}1
{Ü}{{\"U}}1
{ß}{{\ss}}1
{ü}{{\"u}}1
{ä}{{\"a}}1
{ö}{{\"o}}1
{~}{{\textasciitilde}}1
}
\definecolor{lightgray}{rgb}{.9,.9,.9}
\definecolor{darkgray}{rgb}{.4,.4,.4}
\definecolor{purple}{rgb}{0.65, 0.12, 0.82}
\lstdefinelanguage{JavaScript}{
keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break},
keywordstyle=\color{blue}\bfseries,
ndkeywords={class, export, boolean, throw, implements, import, this},
ndkeywordstyle=\color{darkgray}\bfseries,
identifierstyle=\color{black},
sensitive=false,
comment=[l]{//},
morecomment=[s]{/*}{*/},
commentstyle=\color{purple}\ttfamily,
stringstyle=\color{red}\ttfamily,
morestring=[b]',
morestring=[b]"
}
% C++ code environment
% @par1: The caption
% @par2: The label
% Used as:
% \begin{c++}{caption}{label}
% c++ code
% \end{c++}
% Use empty brackets for code without caption and/or lable like:
% \begin{c++}{}{}
% c++ code
% \end{c++}
\lstnewenvironment{JavaScript}[2]{
\lstset{ % General command to set parameter(s)
language=JavaScript,
% The language of the code
basicstyle=\small \ttfamily,
% The size of the fonts that are used for the code
breaklines=true,
% Sets automatic line breaking
captionpos=b,
% Sets the caption-position to bottom
showstringspaces=false,
% Underline spaces within strings only
showspaces=false,
% Show spaces everywhere adding particular underscores;
% it overrides 'showstringspaces'
keepspaces=true,
% Keeps spaces in text, useful for keeping indentation
% of code (possibly needs columns=flexible)
numbers=left,
% Where to put the line-numbers;
% possible values are (none, left, right)
showtabs=false,
% Show tabs within strings adding particular underscores
keywordstyle=\bfseries \color{blue},
% Keyword style
rulesepcolor=\color{gray},
% The color of the shadow of the box
identifierstyle=\ttfamily,
% The style for non-keywords
commentstyle=\bfseries \color{gray},
% Comment style
stringstyle=\ttfamily \color{red!50!brown},
% String literal style
numberstyle=\tiny,
% The style that is used for the line-numbers
tabsize=2,
% Sets default tabsize to 2 spaces
frame=shadowbox,
% Adds a frame around the code use single for no shadow
rulecolor=\color{black},
% If not set, the frame-color may be changed
% on line-breaks within not-black text
moredelim=[is][\underbar]{__}{__},
% To create a underlind text to highlight something: __text__
caption={#1},
% The caption of the code example will be
% shown in the lstlistoflistings
label={#2}
% The lable used to make a ref to the code
}
}{}
\lstnewenvironment{mail}[2]{
\lstset{ % General command to set parameter(s)
basicstyle=\small \ttfamily,
% The size of the fonts that are used for the code
breaklines=true,
% Sets automatic line breaking
captionpos=b,
% Sets the caption-position to bottom
showstringspaces=false,
% Underline spaces within strings only
showspaces=false,
% Show spaces everywhere adding particular underscores;
% it overrides 'showstringspaces'
keepspaces=true,
% Keeps spaces in text, useful for keeping indentation
% of code (possibly needs columns=flexible)
numbers=left,
% Where to put the line-numbers;
% possible values are (none, left, right)
showtabs=false,
% Show tabs within strings adding particular underscores
keywordstyle=\bfseries \color{blue},
% Keyword style
rulesepcolor=\color{gray},
% The color of the shadow of the box
identifierstyle=\ttfamily,
% The style for non-keywords
commentstyle=\bfseries \color{gray},
% Comment style
stringstyle=\ttfamily \color{red!50!brown},
% String literal style
numberstyle=\tiny,
% The style that is used for the line-numbers
tabsize=2,
% Sets default tabsize to 2 spaces
frame=shadowbox,
% Adds a frame around the code use single for no shadow
rulecolor=\color{black},
% If not set, the frame-color may be changed
% on line-breaks within not-black text
moredelim=[is][\underbar]{__}{__},
% To create a underlind text to highlight something: __text__
caption={#1},
% The caption of the code example will be
% shown in the lstlistoflistings
label={#2}
% The lable used to make a ref to the code
}
}{}

20
Bachelorthesis/Content/StatutoryDeclaration/StatutoryDeclaration.tex Executable file
View File

@ -0,0 +1,20 @@
{\ }
\vfill
\begin{flushleft}
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit
selbstständig und ohne unerlaubte fremde Hilfe angefertigt, andere als die
angegebenen Quellen und Hilfsmittel nicht benutzt und die den benutzten
Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich
gemacht habe.
Dieser Datenträger dient der Vorlage bei dem/r Prüfer/in und der
Prüfungskommission. Der Inhalt der Arbeit darf Dritten ohne ausdrückliche
Genehmigung des Verfassers nicht zugänglich gemacht werden. Dies gilt
insbesondere für die kommerzielle Nutzung, Server von Dritten oder die
Überprüfung mit Hilfe von Plagiatssoftware.
\end{flushleft}
\vspace*{2cm}
\noindent{Minden, den \today ~ \dotfill}
\vspace*{4cm}

34
Bachelorthesis/Content/TitlePage.tex Executable file
View File

@ -0,0 +1,34 @@
\begin{titlepage}
\hrule
\vspace*{3cm}
\begin{center}
{\Huge \sc \TitleFirstLine}
\begin{Large}
\vspace*{18pt}
{\Large von Julian Ospald,\\
geboren am 07.08.1986 in Bielefeld\\
Betreut durch Frau Birgit Christina George}
\vspace*{40pt}
{\bf Bachelor-Abschlussarbeit},\\
eingereicht am Fachbereich Campus Minden\\
der FH Bielefeld, University of Applied Sciences\\
\vspace*{20pt}
\noindent{\today}
\end{Large}
\vspace*{40pt}
\includegraphics[scale=1.0]{Content/TitlePage/fhbi_logo_kompakt_orange}\\
\vfill
\hrule
\vfill
Copyright \copyright \ 2016 Julian Ospald <hasufell@hasufell.de>\\
Licensed under the \href{https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode}{Attribution-NonCommercial-ShareAlike 4.0 International}.
\end{center}
\end{titlepage}

BIN
Bachelorthesis/Content/TitlePage/fhbi_logo_kompakt_orange.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

437
Bachelorthesis/LICENSE Normal file
View File

@ -0,0 +1,437 @@
Attribution-NonCommercial-ShareAlike 4.0 International
=======================================================================
Creative Commons Corporation ("Creative Commons") is not a law firm and
does not provide legal services or legal advice. Distribution of
Creative Commons public licenses does not create a lawyer-client or
other relationship. Creative Commons makes its licenses and related
information available on an "as-is" basis. Creative Commons gives no
warranties regarding its licenses, any material licensed under their
terms and conditions, or any related information. Creative Commons
disclaims all liability for damages resulting from their use to the
fullest extent possible.
Using Creative Commons Public Licenses
Creative Commons public licenses provide a standard set of terms and
conditions that creators and other rights holders may use to share
original works of authorship and other material subject to copyright
and certain other rights specified in the public license below. The
following considerations are for informational purposes only, are not
exhaustive, and do not form part of our licenses.
Considerations for licensors: Our public licenses are
intended for use by those authorized to give the public
permission to use material in ways otherwise restricted by
copyright and certain other rights. Our licenses are
irrevocable. Licensors should read and understand the terms
and conditions of the license they choose before applying it.
Licensors should also secure all rights necessary before
applying our licenses so that the public can reuse the
material as expected. Licensors should clearly mark any
material not subject to the license. This includes other CC-
licensed material, or material used under an exception or
limitation to copyright. More considerations for licensors:
wiki.creativecommons.org/Considerations_for_licensors
Considerations for the public: By using one of our public
licenses, a licensor grants the public permission to use the
licensed material under specified terms and conditions. If
the licensor's permission is not necessary for any reason--for
example, because of any applicable exception or limitation to
copyright--then that use is not regulated by the license. Our
licenses grant only permissions under copyright and certain
other rights that a licensor has authority to grant. Use of
the licensed material may still be restricted for other
reasons, including because others have copyright or other
rights in the material. A licensor may make special requests,
such as asking that all changes be marked or described.
Although not required by our licenses, you are encouraged to
respect those requests where reasonable. More_considerations
for the public:
wiki.creativecommons.org/Considerations_for_licensees
=======================================================================
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International
Public License
By exercising the Licensed Rights (defined below), You accept and agree
to be bound by the terms and conditions of this Creative Commons
Attribution-NonCommercial-ShareAlike 4.0 International Public License
("Public License"). To the extent this Public License may be
interpreted as a contract, You are granted the Licensed Rights in
consideration of Your acceptance of these terms and conditions, and the
Licensor grants You such rights in consideration of benefits the
Licensor receives from making the Licensed Material available under
these terms and conditions.
Section 1 -- Definitions.
a. Adapted Material means material subject to Copyright and Similar
Rights that is derived from or based upon the Licensed Material
and in which the Licensed Material is translated, altered,
arranged, transformed, or otherwise modified in a manner requiring
permission under the Copyright and Similar Rights held by the
Licensor. For purposes of this Public License, where the Licensed
Material is a musical work, performance, or sound recording,
Adapted Material is always produced where the Licensed Material is
synched in timed relation with a moving image.
b. Adapter's License means the license You apply to Your Copyright
and Similar Rights in Your contributions to Adapted Material in
accordance with the terms and conditions of this Public License.
c. BY-NC-SA Compatible License means a license listed at
creativecommons.org/compatiblelicenses, approved by Creative
Commons as essentially the equivalent of this Public License.
d. Copyright and Similar Rights means copyright and/or similar rights
closely related to copyright including, without limitation,
performance, broadcast, sound recording, and Sui Generis Database
Rights, without regard to how the rights are labeled or
categorized. For purposes of this Public License, the rights
specified in Section 2(b)(1)-(2) are not Copyright and Similar
Rights.
e. Effective Technological Measures means those measures that, in the
absence of proper authority, may not be circumvented under laws
fulfilling obligations under Article 11 of the WIPO Copyright
Treaty adopted on December 20, 1996, and/or similar international
agreements.
f. Exceptions and Limitations means fair use, fair dealing, and/or
any other exception or limitation to Copyright and Similar Rights
that applies to Your use of the Licensed Material.
g. License Elements means the license attributes listed in the name
of a Creative Commons Public License. The License Elements of this
Public License are Attribution, NonCommercial, and ShareAlike.
h. Licensed Material means the artistic or literary work, database,
or other material to which the Licensor applied this Public
License.
i. Licensed Rights means the rights granted to You subject to the
terms and conditions of this Public License, which are limited to
all Copyright and Similar Rights that apply to Your use of the
Licensed Material and that the Licensor has authority to license.
j. Licensor means the individual(s) or entity(ies) granting rights
under this Public License.
k. NonCommercial means not primarily intended for or directed towards
commercial advantage or monetary compensation. For purposes of
this Public License, the exchange of the Licensed Material for
other material subject to Copyright and Similar Rights by digital
file-sharing or similar means is NonCommercial provided there is
no payment of monetary compensation in connection with the
exchange.
l. Share means to provide material to the public by any means or
process that requires permission under the Licensed Rights, such
as reproduction, public display, public performance, distribution,
dissemination, communication, or importation, and to make material
available to the public including in ways that members of the
public may access the material from a place and at a time
individually chosen by them.
m. Sui Generis Database Rights means rights other than copyright
resulting from Directive 96/9/EC of the European Parliament and of
the Council of 11 March 1996 on the legal protection of databases,
as amended and/or succeeded, as well as other essentially
equivalent rights anywhere in the world.
n. You means the individual or entity exercising the Licensed Rights
under this Public License. Your has a corresponding meaning.
Section 2 -- Scope.
a. License grant.
1. Subject to the terms and conditions of this Public License,
the Licensor hereby grants You a worldwide, royalty-free,
non-sublicensable, non-exclusive, irrevocable license to
exercise the Licensed Rights in the Licensed Material to:
a. reproduce and Share the Licensed Material, in whole or
in part, for NonCommercial purposes only; and
b. produce, reproduce, and Share Adapted Material for
NonCommercial purposes only.
2. Exceptions and Limitations. For the avoidance of doubt, where
Exceptions and Limitations apply to Your use, this Public
License does not apply, and You do not need to comply with
its terms and conditions.
3. Term. The term of this Public License is specified in Section
6(a).
4. Media and formats; technical modifications allowed. The
Licensor authorizes You to exercise the Licensed Rights in
all media and formats whether now known or hereafter created,
and to make technical modifications necessary to do so. The
Licensor waives and/or agrees not to assert any right or
authority to forbid You from making technical modifications
necessary to exercise the Licensed Rights, including
technical modifications necessary to circumvent Effective
Technological Measures. For purposes of this Public License,
simply making modifications authorized by this Section 2(a)
(4) never produces Adapted Material.
5. Downstream recipients.
a. Offer from the Licensor -- Licensed Material. Every
recipient of the Licensed Material automatically
receives an offer from the Licensor to exercise the
Licensed Rights under the terms and conditions of this
Public License.
b. Additional offer from the Licensor -- Adapted Material.
Every recipient of Adapted Material from You
automatically receives an offer from the Licensor to
exercise the Licensed Rights in the Adapted Material
under the conditions of the Adapter's License You apply.
c. No downstream restrictions. You may not offer or impose
any additional or different terms or conditions on, or
apply any Effective Technological Measures to, the
Licensed Material if doing so restricts exercise of the
Licensed Rights by any recipient of the Licensed
Material.
6. No endorsement. Nothing in this Public License constitutes or
may be construed as permission to assert or imply that You
are, or that Your use of the Licensed Material is, connected
with, or sponsored, endorsed, or granted official status by,
the Licensor or others designated to receive attribution as
provided in Section 3(a)(1)(A)(i).
b. Other rights.
1. Moral rights, such as the right of integrity, are not
licensed under this Public License, nor are publicity,
privacy, and/or other similar personality rights; however, to
the extent possible, the Licensor waives and/or agrees not to
assert any such rights held by the Licensor to the limited
extent necessary to allow You to exercise the Licensed
Rights, but not otherwise.
2. Patent and trademark rights are not licensed under this
Public License.
3. To the extent possible, the Licensor waives any right to
collect royalties from You for the exercise of the Licensed
Rights, whether directly or through a collecting society
under any voluntary or waivable statutory or compulsory
licensing scheme. In all other cases the Licensor expressly
reserves any right to collect such royalties, including when
the Licensed Material is used other than for NonCommercial
purposes.
Section 3 -- License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the
following conditions.
a. Attribution.
1. If You Share the Licensed Material (including in modified
form), You must:
a. retain the following if it is supplied by the Licensor
with the Licensed Material:
i. identification of the creator(s) of the Licensed
Material and any others designated to receive
attribution, in any reasonable manner requested by
the Licensor (including by pseudonym if
designated);
ii. a copyright notice;
iii. a notice that refers to this Public License;
iv. a notice that refers to the disclaimer of
warranties;
v. a URI or hyperlink to the Licensed Material to the
extent reasonably practicable;
b. indicate if You modified the Licensed Material and
retain an indication of any previous modifications; and
c. indicate the Licensed Material is licensed under this
Public License, and include the text of, or the URI or
hyperlink to, this Public License.
2. You may satisfy the conditions in Section 3(a)(1) in any
reasonable manner based on the medium, means, and context in
which You Share the Licensed Material. For example, it may be
reasonable to satisfy the conditions by providing a URI or
hyperlink to a resource that includes the required
information.
3. If requested by the Licensor, You must remove any of the
information required by Section 3(a)(1)(A) to the extent
reasonably practicable.
b. ShareAlike.
In addition to the conditions in Section 3(a), if You Share
Adapted Material You produce, the following conditions also apply.
1. The Adapter's License You apply must be a Creative Commons
license with the same License Elements, this version or
later, or a BY-NC-SA Compatible License.
2. You must include the text of, or the URI or hyperlink to, the
Adapter's License You apply. You may satisfy this condition
in any reasonable manner based on the medium, means, and
context in which You Share Adapted Material.
3. You may not offer or impose any additional or different terms
or conditions on, or apply any Effective Technological
Measures to, Adapted Material that restrict exercise of the
rights granted under the Adapter's License You apply.
Section 4 -- Sui Generis Database Rights.
Where the Licensed Rights include Sui Generis Database Rights that
apply to Your use of the Licensed Material:
a. for the avoidance of doubt, Section 2(a)(1) grants You the right
to extract, reuse, reproduce, and Share all or a substantial
portion of the contents of the database for NonCommercial purposes
only;
b. if You include all or a substantial portion of the database
contents in a database in which You have Sui Generis Database
Rights, then the database in which You have Sui Generis Database
Rights (but not its individual contents) is Adapted Material,
including for purposes of Section 3(b); and
c. You must comply with the conditions in Section 3(a) if You Share
all or a substantial portion of the contents of the database.
For the avoidance of doubt, this Section 4 supplements and does not
replace Your obligations under this Public License where the Licensed
Rights include other Copyright and Similar Rights.
Section 5 -- Disclaimer of Warranties and Limitation of Liability.
a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
c. The disclaimer of warranties and limitation of liability provided
above shall be interpreted in a manner that, to the extent
possible, most closely approximates an absolute disclaimer and
waiver of all liability.
Section 6 -- Term and Termination.
a. This Public License applies for the term of the Copyright and
Similar Rights licensed here. However, if You fail to comply with
this Public License, then Your rights under this Public License
terminate automatically.
b. Where Your right to use the Licensed Material has terminated under
Section 6(a), it reinstates:
1. automatically as of the date the violation is cured, provided
it is cured within 30 days of Your discovery of the
violation; or
2. upon express reinstatement by the Licensor.
For the avoidance of doubt, this Section 6(b) does not affect any
right the Licensor may have to seek remedies for Your violations
of this Public License.
c. For the avoidance of doubt, the Licensor may also offer the
Licensed Material under separate terms or conditions or stop
distributing the Licensed Material at any time; however, doing so
will not terminate this Public License.
d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
License.
Section 7 -- Other Terms and Conditions.
a. The Licensor shall not be bound by any additional or different
terms or conditions communicated by You unless expressly agreed.
b. Any arrangements, understandings, or agreements regarding the
Licensed Material not stated herein are separate from and
independent of the terms and conditions of this Public License.
Section 8 -- Interpretation.
a. For the avoidance of doubt, this Public License does not, and
shall not be interpreted to, reduce, limit, restrict, or impose
conditions on any use of the Licensed Material that could lawfully
be made without permission under this Public License.
b. To the extent possible, if any provision of this Public License is
deemed unenforceable, it shall be automatically reformed to the
minimum extent necessary to make it enforceable. If the provision
cannot be reformed, it shall be severed from this Public License
without affecting the enforceability of the remaining terms and
conditions.
c. No term or condition of this Public License will be waived and no
failure to comply consented to unless expressly agreed to by the
Licensor.
d. Nothing in this Public License constitutes or may be interpreted
as a limitation upon, or waiver of, any privileges and immunities
that apply to the Licensor or You, including from the legal
processes of any jurisdiction or authority.
=======================================================================
Creative Commons is not a party to its public
licenses. Notwithstanding, Creative Commons may elect to apply one of
its public licenses to material it publishes and in those instances
will be considered the “Licensor.” The text of the Creative Commons
public licenses is dedicated to the public domain under the CC0 Public
Domain Dedication. Except for the limited purpose of indicating that
material is shared under a Creative Commons public license or as
otherwise permitted by the Creative Commons policies published at
creativecommons.org/policies, Creative Commons does not authorize the
use of the trademark "Creative Commons" or any other trademark or logo
of Creative Commons without its prior written consent including,
without limitation, in connection with any unauthorized modifications
to any of its public licenses or any other arrangements,
understandings, or agreements concerning use of licensed material. For
the avoidance of doubt, this paragraph does not form part of the
public licenses.
Creative Commons may be contacted at creativecommons.org.

79
Bachelorthesis/Makefile Normal file
View File

@ -0,0 +1,79 @@
include ../common.mk
LATEX_FILES = \
Content/Abstract.tex \
Content/AlternativeLoesungen.tex \
Content/AlternativeLoesungen/Bewertung.tex \
Content/AlternativeLoesungen/DarkMail.tex \
Content/Entwicklung.tex \
Content/Entwicklung/IdeaConcept.tex \
Content/Entwicklung/IdeaConcept/Algorithmus.tex \
Content/Entwicklung/Methoden.tex \
Content/Entwicklung/Realisierung.tex \
Content/Entwicklung/Realisierung/Implementierung.tex \
Content/Entwicklung/Realisierung/Implementierung/Einsprungpunkt.tex \
Content/Entwicklung/Realisierung/Implementierung/Haraka.tex \
Content/Entwicklung/Realisierung/Implementierung/Konfiguration.tex \
Content/Entwicklung/Realisierung/Implementierung/MTA-Entscheider.tex \
Content/Entwicklung/Realisierung/Implementierung/SMTP-gateway.tex \
Content/Entwicklung/Realisierung/Implementierung/Wahl.tex \
Content/Entwicklung/Realisierung/Testsystem.tex \
Content/EvaluationValidation.tex \
Content/Intro.tex \
Content/Intro/Format.tex \
Content/Intro/Gesamtsystem.tex \
Content/Intro/Protokolle.tex \
Content/Intro/Protokolle/IMAP4.tex \
Content/Intro/Protokolle/POP3.tex \
Content/Intro/Protokolle/SMTP.tex \
Content/ListOfAbbreviations/ListOfAbbreviations.tex \
Content/LookOut.tex \
Content/LookOut/PraktischeProbleme.tex \
Content/LookOut/PraktischeProbleme/DirectoryServer.tex \
Content/LookOut/PraktischeProbleme/Fehlerbehandlung.tex \
Content/LookOut/PraktischeProbleme/Gesamtsystem.tex \
Content/LookOut/PraktischeProbleme/Implementierung.tex \
Content/LookOut/PraktischeProbleme/Spam.tex \
Content/LookOut/PraktischeProbleme/Verify.tex \
Content/LookOut/PraktischeProbleme/Zuverlaessigkeit.tex \
Content/LookOut/TheoretischeProbleme.tex \
Content/LookOut/TheoretischeProbleme/KryptografieSystem.tex \
Content/LookOut/TheoretischeProbleme/PublicKey.tex \
Content/LookOut/TheoretischeProbleme/RoutingAlgo.tex \
Content/LookOut/TheoretischeProbleme/Spezifikation.tex \
Content/LookOut/TheoretischeProbleme/Verschluesselung.tex \
Content/Problematik.tex \
Content/Problematik/Anforderungen.tex \
Content/Problematik/BetrachtungDatenschutz.tex \
Content/Problematik/BetrachtungDatenschutz/Anonymitaet.tex \
Content/Problematik/BetrachtungDatenschutz/Anonymitaet/TorBirdy.tex \
Content/Problematik/BetrachtungDatenschutz/Bewertung.tex \
Content/Problematik/BetrachtungDatenschutz/Verschluesselung.tex \
Content/Problematik/BetrachtungDatenschutz/Verschluesselung/GPG.tex \
Content/Problematik/BetrachtungDatenschutz/Verschluesselung/STARTTLS.tex \
Content/Problematik/BetrachtungDatenschutz/Verschluesselung/TLS.tex \
Content/Settings.tex \
Content/StatutoryDeclaration/StatutoryDeclaration.tex \
Content/TitlePage.tex
all: Bachelorthesis.pdf
Bachelorthesis.dvi: Bachelorthesis.tex $(LATEX_FILES)
$(LATEX) $<
$(BIBTEX) Bachelorthesis.aux
$(LATEX) $<
$(LATEX) $<
Bachelorthesis.pdf: Bachelorthesis.tex $(LATEX_FILES)
$(PDFLATEX) $<
$(BIBTEX) Bachelorthesis.aux
$(PDFLATEX) $<
$(PDFLATEX) $<
clean:
$(RM) Bachelorthesis.dvi Bachelorthesis.pdf *.log *.aux *.nav *.snm *.toc *.out *.vrb *.gz *.bbl *.blg *.idx *.lof *.lol *.lot
.PHONY: all clean Bachelorthesis.dvi Bachelorthesis.pdf

7
COPYRIGHT Normal file
View File

@ -0,0 +1,7 @@
Copyright 2016 Julian Ospald <hasufell@hasufell.de>
LaTex source code and thesis are licensed under
Attribution-NonCommercial-ShareAlike 4.0 International.
Implementation is licensed under GPL-2.

100
Implementierung/Handbuch.md Normal file
View File

@ -0,0 +1,100 @@
# Handbuch zur Ausführung der Implementierung
## Vorraussetzungen/Abhängigkeiten
* ein unix-artiges Betriebssystem
* Docker Version 1.10.x (getestet mit 1.10.1)
Der Docker Daemon muss gestartet sein. Siehe [Installations Guide](https://docs.docker.com/engine/installation/).
### Bauen der container
```sh
docker build -t hasufell/haraka alpine-haraka
docker build -t hasufell/haraka-gateway alpine-haraka-gateway
docker build -t hasufell/swaks alpine-swaks
```
## Ausführung des Programms
### Starten des Netzwerkes
Die Container werden in einem Docker Netzwerk zusammengefasst und
können innerhalb dessen kommunizieren.
```sh
docker network create haraka
```
Der Name des Netzwerkes _muss_ hier `haraka` lauten.
### Starten der hops
Diese sollten jeweils in einem Terminal gestartet werden, um den Debug
Output der Container beobachten zu können.
```sh
docker run -ti \
--name=hop1 \
--net=haraka \
hasufell/haraka
docker run -ti \
--name=hop2 \
--net=haraka \
hasufell/haraka
docker run -ti \
--name=hop3 \
--net=haraka \
hasufell/haraka
docker run -ti \
--name=rcpt \
--net=haraka \
hasufell/haraka
```
### Starten des SMTP gateways
Dieser Server erstellt die initiale MystMail, wenn eine gewöhnliche E-Mail
ankommt und sendet sie an `hop1`.
```sh
docker run -ti \
--name=smtp-gateway \
--net=haraka \
hasufell/haraka-gateway
```
### Absenden einer E-Mail
```sh
docker run -ti \
--net=haraka \
hasufell/swaks \
swaks -t wurst@rcpt.haraka -f hasufell@smtp-gateway.com -s smtp-gateway.haraka -p 25
```
## Beobachtung der Ergebnisse
Dies zeigt die MystMail an jedem Hop.
```sh
for i in hop1 hop2 hop3 rcpt ; do
docker exec -ti ${i} cat /tmp/mail.eml
done
```
## Cleanup
Falls die Container neu gestartet werden sollen.
```sh
for i in hop1 hop2 hop3 rcpt smtp-gateway ; do
docker stop ${i}
docker rm ${i}
done
```

340
Implementierung/LICENSE Normal file
View File

@ -0,0 +1,340 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.

13
Implementierung/Makefile Normal file
View File

@ -0,0 +1,13 @@
include ../common.mk
all: Handbuch.pdf
Handbuch.pdf: Handbuch.md
$(PANDOC) $^ --latex-engine=xelatex -o $@
clean:
$(RM) Handbuch.pdf
.PHONY: all clean

50
Implementierung/alpine-haraka-gateway/Dockerfile Normal file
View File

@ -0,0 +1,50 @@
FROM mhart/alpine-node:4
MAINTAINER Julian Ospald <hasufell@posteo.de>
ENV HARAKA_HOME /app
ENV HARAKA_LOGS /logs
ENV HARAKA_DATA /data
ENV PATH /usr/local/bin:$HARAKA_HOME/node_modules/.bin:$PATH
# node-gyp emits lots of warnings if HOME is set to /
ENV HOME /tmp
ENV HARAKA_VERSION 2.7.0
# the application is not started as this user,
# but Haraka can be configured to drop its privileges
# via smtp.ini
RUN echo "@testing http://nl.alpinelinux.org/alpine/edge/testing" \
>> /etc/apk/repositories && \
apk --no-cache add make gcc g++ python shadow@testing && \
groupadd -r haraka && \
useradd --comment "Haraka Server User" \
--home "$HARAKA_HOME" \
--shell /bin/false \
--gid haraka \
-r \
-M \
haraka && \
npm install -g "Haraka@$HARAKA_VERSION" && \
haraka --install "$HARAKA_HOME" && \
apk --no-cache del make gcc g++ python shadow && \
rm -rf /var/cache/apk/*
COPY docker-entrypoint.sh /usr/local/bin/docker-entrypoint
COPY config /app/config
COPY plugins /app/plugins
RUN chmod 0755 /usr/local/bin/docker-entrypoint
RUN mkdir -p "$HARAKA_HOME" && \
mkdir -p "$HARAKA_LOGS" && \
mkdir -p "$HARAKA_DATA" && \
chmod -R 0777 "$HARAKA_LOGS" && \
chmod -R 0777 "$HARAKA_DATA" && \
chown -R haraka:haraka "$HARAKA_HOME" "$HARAKA_LOGS" "$HARAKA_DATA"
ENV HOME "$HARAKA_HOME"
WORKDIR /app
EXPOSE 25
ENTRYPOINT ["/usr/local/bin/docker-entrypoint"]
CMD [""]

4
Implementierung/alpine-haraka-gateway/README.md Normal file
View File

@ -0,0 +1,4 @@
`Dockerfile` and `docker-entrypoint.sh` based on
https://github.com/mhart/alpine-node and https://github.com/gbleux/docker-haraka
`config/` and `plugins/`: Copyright Julian Ospald, 2016

9
Implementierung/alpine-haraka-gateway/config/plugins Normal file
View File

@ -0,0 +1,9 @@
my_mx
access
dnsbl
helo.checks
open_relay
data.headers
enable_parse_body
create_myst_mail
max_unrecognized_commands

131
Implementierung/alpine-haraka-gateway/docker-entrypoint.sh Normal file
View File

@ -0,0 +1,131 @@
#!/bin/sh
#
# a wrapper script for the Haraka server process. when invoked with
# 'haraka' as first argument, it performs two additional steps:
# * ensure proper ownership and permissions of the persistence directories
# * capture the log statements from stdout and writes it to /logs
#
# all other arguments are passed through to the sub-command.
#
# the ownership and permissions flags is required, as docker maintains
# the settings from the host once a volume is mounted. the userid will
# most likely not match and the default bits of 0755 will prevent Haraka
# to write any data. the permission flags can be defined via the
# environment variable DOCKER_VOLUMES_CHMOD and the ownership via
# DOCKER_VOLUMES_CHOWN. if a variable is not defined, its respective
# action is not performed and the volume directories remain unchanged.
#
# logging to file is supported by Haraka, but only in daemon mode. this
# would cause the container to exit immediately. the SMTP server is
# therefor run in the forground, which causes log messages to end up
# in stdout. the wrapper script redirects it to files in /logs. in order
# to preserve log files from previous runs, a new logfile is created,
# together with a symlink pointing to the current file. the name of the
# log file can be configured via the environment variable
# HARAKA_LOG_DATE_FORMAT. its content is expected to be a valid
# date (1) format pattern.
#
set -e
HARAKA_LOG="haraka-latest.log"
HARAKA_BIN="haraka"
# create a new log file and a symbolic link named 'haraka.log'
# to that file in the same directory. the symbolic link is
# overwritten if it exists.
# @param $1 {String} log filename (without directory path)
haraka_log_rotate() {
# remove symlink in case of persistent mount
test -e "$HARAKA_LOGS/haraka.log" && rm -f "$HARAKA_LOGS/haraka.log"
touch "$HARAKA_LOGS/$1" && ln -s "$HARAKA_LOGS/$1" "$HARAKA_LOGS/haraka.log"
}
# change the ownership of the haraka persistence volumes.
# @param $1 {String} chown ownership rule
haraka_chown() {
chown -R "$1" "$HARAKA_LOGS" && \
chown -R "$1" "$HARAKA_DATA"
}
# change the permission flags of the haraka persistence volumes.
# @param $1 {String} chmod permission flags
haraka_chmod() {
chmod "$1" "$HARAKA_LOGS" && \
chmod "$1" "$HARAKA_DATA"
}
# set the filename of the log output. if the environment variable
# 'HARAKA_LOG_DATE_FORMAT' is set, it is used to generate the filename
# postfix using the 'date' command. the default is to use 'date +%s' as
# the filename postfix.
configure_log_filename() {
HARAKA_LOG_IDENT=$(date +"${HARAKA_LOG_DATE_FORMAT:-s}")
HARAKA_LOG="haraka-${HARAKA_LOG_IDENT}.log"
}
# perform pre-boot actions before the SMTP server starts.
haraka_bootstrap() {
configure_log_filename
haraka_log_rotate "$HARAKA_LOG"
if test "x$DOCKER_VOLUMES_CHOWN" != "x";then
haraka_chown "$DOCKER_VOLUMES_CHOWN" || return 1
fi
if test "x$DOCKER_VOLUMES_CHMOD" != "x";then
haraka_chmod "$DOCKER_VOLUMES_CHMOD" || return 1
fi
return 0
}
# ensure the environment has been set up correctly.
# @return {Number} a value greater than zero if anything is not OK
validate_haraka_env() {
if test "x$HARAKA_LOGS" = "x";then
echo "Haraka logs directory has not been set." 1>&2
return 1
fi
if test "x$HARAKA_DATA" = "x";then
echo "Haraka data directory has not been set." 1>&2
return 1
fi
return 0
}
exec_haraka() {
validate_haraka_env || exit 1
haraka_bootstrap || exit 2
# tee outout so 'docker logs' and 'tail -f $LOG_VOLUME/haraka.log' works
exec "$HARAKA_BIN" -c /app "$@" 2>&1 | tee "$HARAKA_LOGS/$HARAKA_LOG"
}
exec_help() {
echo "Either run this command without any parameters to execute"
echo "Haraka or specify the command which should be invoked."
exit 0
}
# script entry point
main() {
case "${1:-haraka}" in
[hH]araka)
exec_haraka
;;
--help|-h|-?)
exec_help
;;
*)
exec "$@"
;;
esac
}
main "$@"

12
Implementierung/alpine-haraka-gateway/plugins/.tern-project Normal file
View File

@ -0,0 +1,12 @@
{
"libs": [
"browser",
"underscore",
"jquery",
"Haraka"
],
"plugins": {
"node": {},
"complete_strings": {}
}
}

162
Implementierung/alpine-haraka-gateway/plugins/create_myst_mail.js Normal file
View File

@ -0,0 +1,162 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
var console = require('console');
var fs = require('fs');
var os = require('os');
var Address = require('./address').Address;
var MessageStream = require('./messagestream');
var Transaction = require('./transaction').Transaction;
var config = require('./config');
var uuid = require('./utils').uuid;
exports.hook_data_post = function(next, connection) {
var mail = create_myst_mail(connection.transaction);
var t = transform_transaction(mail, connection);
connection.transaction = t;
next();
}
/**
* Transforms the current transaction based on a given
* raw email string. This always parses the body.
*
* 'mail_from' and 'rcpt_to' are filled in from the email headers.
* The uuid and results are taken from the old transaction.
*
* @param {string} email the raw full email, including headers
* @param {Connection} connection the current connection object
* @return {Transaction} the new transaction
*/
function transform_transaction(email, connection) {
var email_lines = email.split("\n");
// create new empty transaction
var t = new Transaction();
t.uuid = connection.transaction.uuid;
t.parse_body = true;
t.message_stream = new MessageStream(
config.get('smtp.ini'), t.uuid,
t.header.header_list);
// parse the email and fill the object
var i;
for (i = 0; i < email_lines.length; i++) {
t.add_data(email_lines[i] + "\n");
}
t.end_data(function() { return ; })
// use old result object
t.results = connection.transaction.results;
// overwrite mail_from and rcpt_to
var from_addr = t.header.get("From").match(/[^@<\s]+@[^@\s>]+/g)[0];
var to_addr = t.header.get("To").match(/[^@<\s]+@[^@\s>]+/g)[0];
t.mail_from = new Address(from_addr);
t.rcpt_to = [new Address(to_addr)];
t.results.store.mail_from = new Address(from_addr);
t.results.store.rcpt_to = [new Address(to_addr)];
return t;
}
/**
* Check whether the given header object identifies as a myst mail header
*
* @param {Header} header
* @return {Boolean} true/false
*/
function is_myst_mail(header) {
if (header.get("X-Myst")) {
return true;
}
return false;
}
function myst_encrypt(string) {
var enc = new Buffer(string).toString('base64');
return enc;
}
function get_hops() {
// excludes the last hop
return ["hop1.haraka", "hop2.haraka", "hop3.haraka"];
}
// TODO: randomize date?
function create_mail_for_hop(fromd, tod, date, bodytext) {
var from_addr = "myst@" + fromd;
var to_addr = "myst@" + tod;
return ["Date: " + date,
"To: " + to_addr,
"From: " + from_addr,
"X-Myst: 1",
"Subject: ",
"",
myst_encrypt(bodytext),
""].join("\n");
}
function create_myst_mail(transaction) {
// recipient is always the last hop
var recipient = transaction.rcpt_to[0].host;
var hops = get_hops();
hops.push(recipient);
var date = transaction.header.get("Date").replace(/\n$/, "");
// innermost mail, untouched
var old_mail = get_raw_mail(transaction.body);
var i;
var new_mail = old_mail;
for (i = hops.length - 1; i >= 0; i--) {
if (i == 0) {
// first hop, "from" must be the actual sender
var sender = transaction.mail_from.host;
new_mail = create_mail_for_hop(sender, hops[i], date, new_mail);
} else {
new_mail = create_mail_for_hop(hops[i-1], hops[i], date, new_mail);
}
}
return new_mail;
}
function get_raw_mail(body) {
// TODO: doesn't handle multipart mime
return body.header.header_list.join("") + "\n" + body.bodytext;
}

25
Implementierung/alpine-haraka-gateway/plugins/enable_parse_body.js Normal file
View File

@ -0,0 +1,25 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
// enable parsing of the mail body
exports.hook_data = function(next, connection, params) {
connection.transaction.parse_body = true;
return next();
};

34
Implementierung/alpine-haraka-gateway/plugins/my_mx.js Normal file
View File

@ -0,0 +1,34 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
'use strict';
var dns = require('dns');
/**
* Fake get_mx hook, which just resolves the domain to its ip address.
* This causes outbound.js to avoid dns.resolve, which would otherwise
* mess up with our test system.
*/
exports.hook_get_mx = function(next, hmail, domain) {
dns.lookup(domain, function (err, address, family) {
return next(OK, address);
})
}

46
Implementierung/alpine-haraka-gateway/plugins/open_relay.js Normal file
View File

@ -0,0 +1,46 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
'use strict';
var console = require('console');
var Body = require('./mailbody').Body;
/**
* This acts as an open relay for non-local recipients
*/
exports.hook_rcpt = function(next, connection, params) {
if (is_local_rcpt(connection) == false) {
connection.relaying = true;
}
return next(OK);
}
function is_local_rcpt(connection) {
// TODO: get "ich.com" from the config files
// TODO: we currently only handle one recipient
if (connection.transaction.rcpt_to[0].host == "ich.com") {
return true;
}
return false;
}

50
Implementierung/alpine-haraka/Dockerfile Normal file
View File

@ -0,0 +1,50 @@
FROM mhart/alpine-node:4
MAINTAINER Julian Ospald <hasufell@posteo.de>
ENV HARAKA_HOME /app
ENV HARAKA_LOGS /logs
ENV HARAKA_DATA /data
ENV PATH /usr/local/bin:$HARAKA_HOME/node_modules/.bin:$PATH
# node-gyp emits lots of warnings if HOME is set to /
ENV HOME /tmp
ENV HARAKA_VERSION 2.7.0
# the application is not started as this user,
# but Haraka can be configured to drop its privileges
# via smtp.ini
RUN echo "@testing http://nl.alpinelinux.org/alpine/edge/testing" \
>> /etc/apk/repositories && \
apk --no-cache add make gcc g++ python shadow@testing && \
groupadd -r haraka && \
useradd --comment "Haraka Server User" \
--home "$HARAKA_HOME" \
--shell /bin/false \
--gid haraka \
-r \
-M \
haraka && \
npm install -g "Haraka@$HARAKA_VERSION" && \
haraka --install "$HARAKA_HOME" && \
apk --no-cache del make gcc g++ python shadow && \
rm -rf /var/cache/apk/*
COPY docker-entrypoint.sh /usr/local/bin/docker-entrypoint
COPY config /app/config
COPY plugins /app/plugins
RUN chmod 0755 /usr/local/bin/docker-entrypoint
RUN mkdir -p "$HARAKA_HOME" && \
mkdir -p "$HARAKA_LOGS" && \
mkdir -p "$HARAKA_DATA" && \
chmod -R 0777 "$HARAKA_LOGS" && \
chmod -R 0777 "$HARAKA_DATA" && \
chown -R haraka:haraka "$HARAKA_HOME" "$HARAKA_LOGS" "$HARAKA_DATA"
ENV HOME "$HARAKA_HOME"
WORKDIR /app
EXPOSE 25
ENTRYPOINT ["/usr/local/bin/docker-entrypoint"]
CMD [""]

4
Implementierung/alpine-haraka/README.md Normal file
View File

@ -0,0 +1,4 @@
`Dockerfile` and `docker-entrypoint.sh` based on
https://github.com/mhart/alpine-node and https://github.com/gbleux/docker-haraka
`config/` and `plugins/`: Copyright Julian Ospald, 2016

12
Implementierung/alpine-haraka/config/plugins Normal file
View File

@ -0,0 +1,12 @@
my_mx
access
dnsbl
helo.checks
open_relay
data.headers
enable_parse_body
my_transaction
data_post_write_mail
test_queue
max_unrecognized_commands

131
Implementierung/alpine-haraka/docker-entrypoint.sh Normal file
View File

@ -0,0 +1,131 @@
#!/bin/sh
#
# a wrapper script for the Haraka server process. when invoked with
# 'haraka' as first argument, it performs two additional steps:
# * ensure proper ownership and permissions of the persistence directories
# * capture the log statements from stdout and writes it to /logs
#
# all other arguments are passed through to the sub-command.
#
# the ownership and permissions flags is required, as docker maintains
# the settings from the host once a volume is mounted. the userid will
# most likely not match and the default bits of 0755 will prevent Haraka
# to write any data. the permission flags can be defined via the
# environment variable DOCKER_VOLUMES_CHMOD and the ownership via
# DOCKER_VOLUMES_CHOWN. if a variable is not defined, its respective
# action is not performed and the volume directories remain unchanged.
#
# logging to file is supported by Haraka, but only in daemon mode. this
# would cause the container to exit immediately. the SMTP server is
# therefor run in the forground, which causes log messages to end up
# in stdout. the wrapper script redirects it to files in /logs. in order
# to preserve log files from previous runs, a new logfile is created,
# together with a symlink pointing to the current file. the name of the
# log file can be configured via the environment variable
# HARAKA_LOG_DATE_FORMAT. its content is expected to be a valid
# date (1) format pattern.
#
set -e
HARAKA_LOG="haraka-latest.log"
HARAKA_BIN="haraka"
# create a new log file and a symbolic link named 'haraka.log'
# to that file in the same directory. the symbolic link is
# overwritten if it exists.
# @param $1 {String} log filename (without directory path)
haraka_log_rotate() {
# remove symlink in case of persistent mount
test -e "$HARAKA_LOGS/haraka.log" && rm -f "$HARAKA_LOGS/haraka.log"
touch "$HARAKA_LOGS/$1" && ln -s "$HARAKA_LOGS/$1" "$HARAKA_LOGS/haraka.log"
}
# change the ownership of the haraka persistence volumes.
# @param $1 {String} chown ownership rule
haraka_chown() {
chown -R "$1" "$HARAKA_LOGS" && \
chown -R "$1" "$HARAKA_DATA"
}
# change the permission flags of the haraka persistence volumes.
# @param $1 {String} chmod permission flags
haraka_chmod() {
chmod "$1" "$HARAKA_LOGS" && \
chmod "$1" "$HARAKA_DATA"
}
# set the filename of the log output. if the environment variable
# 'HARAKA_LOG_DATE_FORMAT' is set, it is used to generate the filename
# postfix using the 'date' command. the default is to use 'date +%s' as
# the filename postfix.
configure_log_filename() {
HARAKA_LOG_IDENT=$(date +"${HARAKA_LOG_DATE_FORMAT:-s}")
HARAKA_LOG="haraka-${HARAKA_LOG_IDENT}.log"
}
# perform pre-boot actions before the SMTP server starts.
haraka_bootstrap() {
configure_log_filename
haraka_log_rotate "$HARAKA_LOG"
if test "x$DOCKER_VOLUMES_CHOWN" != "x";then
haraka_chown "$DOCKER_VOLUMES_CHOWN" || return 1
fi
if test "x$DOCKER_VOLUMES_CHMOD" != "x";then
haraka_chmod "$DOCKER_VOLUMES_CHMOD" || return 1
fi
return 0
}
# ensure the environment has been set up correctly.
# @return {Number} a value greater than zero if anything is not OK
validate_haraka_env() {
if test "x$HARAKA_LOGS" = "x";then
echo "Haraka logs directory has not been set." 1>&2
return 1
fi
if test "x$HARAKA_DATA" = "x";then
echo "Haraka data directory has not been set." 1>&2
return 1
fi
return 0
}
exec_haraka() {
validate_haraka_env || exit 1
haraka_bootstrap || exit 2
# tee outout so 'docker logs' and 'tail -f $LOG_VOLUME/haraka.log' works
exec "$HARAKA_BIN" -c /app "$@" 2>&1 | tee "$HARAKA_LOGS/$HARAKA_LOG"
}
exec_help() {
echo "Either run this command without any parameters to execute"
echo "Haraka or specify the command which should be invoked."
exit 0
}
# script entry point
main() {
case "${1:-haraka}" in
[hH]araka)
exec_haraka
;;
--help|-h|-?)
exec_help
;;
*)
exec "$@"
;;
esac
}
main "$@"

12
Implementierung/alpine-haraka/plugins/.tern-project Normal file
View File

@ -0,0 +1,12 @@
{
"libs": [
"browser",
"underscore",
"jquery",
"Haraka"
],
"plugins": {
"node": {},
"complete_strings": {}
}
}

25
Implementierung/alpine-haraka/plugins/add_myst_header.js Normal file
View File

@ -0,0 +1,25 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
// adds the myst header item to the current header list
exports.hook_mail = function(next, connection, params) {
connection.transaction.header.add("X-MYST", "1");
return next();
};

42
Implementierung/alpine-haraka/plugins/data_post_write_mail.js Normal file
View File

@ -0,0 +1,42 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
var console = require('console');
var fs = require('fs');
var os = require('os');
var Address = require('./address').Address;
var Transaction = require('./transaction').Transaction;
var MessageStream = require('./messagestream');
var config = require('./config');
var uuid = require('./utils').uuid;
var tempDir = os.tmpdir();
// write mail to /tmp/mail.eml
exports.hook_data_post = function(next, connection) {
var ws = fs.createWriteStream(tempDir + '/mail.eml');
ws.once('close', function () {
return next(OK);
});
connection.transaction.message_stream.pipe(ws);
};

25
Implementierung/alpine-haraka/plugins/enable_parse_body.js Normal file
View File

@ -0,0 +1,25 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
// enable parsing of the mail body
exports.hook_data = function(next, connection, params) {
connection.transaction.parse_body = true;
return next();
};

34
Implementierung/alpine-haraka/plugins/my_mx.js Normal file
View File

@ -0,0 +1,34 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
'use strict';
var dns = require('dns');
/**
* Fake get_mx hook, which just resolves the domain to its ip address.
* This causes outbound.js to avoid dns.resolve, which would otherwise
* mess up with our test system.
*/
exports.hook_get_mx = function(next, hmail, domain) {
dns.lookup(domain, function (err, address, family) {
return next(OK, address);
})
}

168
Implementierung/alpine-haraka/plugins/my_transaction.js Normal file
View File

@ -0,0 +1,168 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
var console = require('console');
var fs = require('fs');
var os = require('os');
var Address = require('./address').Address;
var MessageStream = require('./messagestream');
var Transaction = require('./transaction').Transaction;
var config = require('./config');
var uuid = require('./utils').uuid;
var outbound = require('./outbound');
exports.hook_data_post = function(next, connection) {
// if we have a myst mail, we need to inject our Protocol
if (is_myst_mail(connection.transaction.header)) {
// we decrypt the mail body and treat it as raw mail data
var decrypted_email = myst_decrypt(connection.transaction.body.bodytext);
// replace the current transaction object with the new one based
// on the decrypted_mail
var t = transform_transaction(decrypted_email, connection);
connection.transaction = t;
// the unpacked mail is a myst mail too, this means we have to relay it,
// otherwise it's handled by the normal haraka delivery methods
if (is_myst_mail(connection.transaction.header)) {
connection.relaying = true;
}
}
// let the other handlers do what they want, we are finished injecting
// our logic, the rest is still SMTP compliant
next();
}
/**
* Transforms the current transaction based on a given
* raw email string. This always parses the body.
*
* 'mail_from' and 'rcpt_to' are filled in from the email headers.
* The uuid and results are taken from the old transaction.
*
* @param {string} email the raw full email, including headers
* @param {Connection} connection the current connection object
* @return {Transaction} the new transaction
*/
function transform_transaction(email, connection) {
var email_lines = email.split("\n");
// create new empty transaction
var t = new Transaction();
t.uuid = connection.transaction.uuid;
t.parse_body = true;
t.message_stream = new MessageStream(
config.get('smtp.ini'), t.uuid,
t.header.header_list);
// parse the email and fill the object
var i;
for (i = 0; i < email_lines.length; i++) {
t.add_data(email_lines[i] + "\n");
}
t.end_data(function() { return ; })
// use old result object
t.results = connection.transaction.results;
// overwrite mail_from and rcpt_to
var from_addr = t.header.get("From").match(/[^@<\s]+@[^@\s>]+/g)[0];
var to_addr = t.header.get("To").match(/[^@<\s]+@[^@\s>]+/g);
var addresses = [];
for (i = 0; i < to_addr.length; i++) {
addresses.push(new Address(to_addr[i]));
}
t.mail_from = new Address(from_addr);
t.rcpt_to = addresses;
t.results.store.mail_from = new Address(from_addr);
t.results.store.rcpt_to = addresses;
return t;
}
/**
* Check whether the given header object identifies as a myst mail header
*
* @param {Header} header
* @return {Boolean} true/false
*/
function is_myst_mail(header) {
if (header.get("X-Myst")) {
return true;
}
return false;
}
/**
* Decrypts the whole mail and return
*
* @param {string} string encrypted string
* @return {string} the decrypted string
*/
function myst_decrypt(string) {
var b = new Buffer(string, 'base64').toString('utf8');
return b;
}
function send_myst_mail(email, connection) {
var email_lines = email.split("\n");
// create transaction for our mail, to make use of the internal parser
var t = new Transaction();
t.uuid = connection.transaction.uuid;
t.parse_body = true;
t.message_stream = new MessageStream(
config.get('smtp.ini'), t.uuid,
t.header.header_list);
// parse the email and fill the object
var i;
for (i = 0; i < email_lines.length; i++) {
t.add_data(email_lines[i] + "\n");
}
t.end_data(function() { return ; })
// use old result object, otherwise we get errors
t.results = connection.transaction.results;
// finally get mail_from and rcpt_to
// TODO: support multiple recipients for last hop
var from_addr = t.header.get("From").match(/[^@<\s]+@[^@\s>]+/g)[0];
var to_addr = t.header.get("To").match(/[^@<\s]+@[^@\s>]+/g);
var outnext = function(code, msg) {
next(OK);
}
// send mail
for (i = 0; i < to_addr.length; i++) {
outbound.send_email(from_addr, to_addr[i], email, outnext);
}
}

29
Implementierung/alpine-haraka/plugins/myst_send.js Normal file
View File

@ -0,0 +1,29 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
'use strict';
var console = require('console');
exports.hook_send_email = function(next, hmail) {
return next(OK);
}

46
Implementierung/alpine-haraka/plugins/open_relay.js Normal file
View File

@ -0,0 +1,46 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
'use strict';
var console = require('console');
var Body = require('./mailbody').Body;
/**
* This acts as an open relay for non-local recipients
*/
exports.hook_rcpt = function(next, connection, params) {
if (is_local_rcpt(connection) == false) {
connection.relaying = true;
}
return next(OK);
}
function is_local_rcpt(connection) {
// TODO: get "rcpt.haraka" from the config files
// TODO: we currently only handle one recipient
if (connection.transaction.rcpt_to[0].host == "rcpt.haraka") {
return true;
}
return false;
}

42
Implementierung/alpine-haraka/plugins/test_queue.js Normal file
View File

@ -0,0 +1,42 @@
/*
Haraka Plugins for SMTP-based anonymization
Copyright (C) 2016 Julian Ospald
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
var console = require('console');
var fs = require('fs');
var os = require('os');
var Address = require('./address').Address;
var Transaction = require('./transaction').Transaction;
var MessageStream = require('./messagestream');
var config = require('./config');
var uuid = require('./utils').uuid;
var tempDir = os.tmpdir();
// write mail to /tmp/mail.eml
exports.hook_queue = function(next, connection) {
var ws = fs.createWriteStream(tempDir + '/mail.eml');
ws.once('close', function () {
return next(OK);
});
connection.transaction.message_stream.pipe(ws);
};

10
Implementierung/alpine-swaks/Dockerfile Normal file
View File

@ -0,0 +1,10 @@
FROM alpine:3.3
MAINTAINER Julian Ospald <hasufell@posteo.de>
RUN echo "@testing http://nl.alpinelinux.org/alpine/edge/testing" \
>> /etc/apk/repositories && \
apk --no-cache add swaks@testing && \
rm -rf /var/cache/apk/*
EXPOSE 25

Some files were not shown because too many files have changed in this diff Show More