Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 314:9038d2030d9a

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
small wording change and added a label
author meillo@marmaro.de
date Wed, 21 Jan 2009 14:48:39 +0100
parents 0d88bf21e152
children f3a86ce788ec
comparison
equal deleted inserted replaced
313:a3fba017ef01 314:9038d2030d9a
106 At least one of the secret-based mechanisms should be supported. 106 At least one of the secret-based mechanisms should be supported.
107 107
108 108
109 109
110 \paragraph{\RF7: Encryption} 110 \paragraph{\RF7: Encryption}
111 \label{requirement-encryption}
111 Electronic mail is vulnerable to sniffing attacks, because in generic \SMTP\ all data transfer is unencrypted. The message's body, the header, and envelope are all unencrypted, but also authentication dialogs that transfer plain text passwords (e.g.\ \NAME{PLAIN} and \NAME{LOGIN}). Hence encryption is throughout important. 112 Electronic mail is vulnerable to sniffing attacks, because in generic \SMTP\ all data transfer is unencrypted. The message's body, the header, and envelope are all unencrypted, but also authentication dialogs that transfer plain text passwords (e.g.\ \NAME{PLAIN} and \NAME{LOGIN}). Hence encryption is throughout important.
112 113
113 The common way to encrypt \SMTP\ dialogs is using \name{Transport Layer Security} (short: \TLS, the successor of \NAME{SSL}). \TLS\ encrypts the datagrams of the \name{transport layer}. This means it works below the application protocols and can be used with any of them \citeweb{wikipedia:tls}. 114 The common way to encrypt \SMTP\ dialogs is using \name{Transport Layer Security} (short: \TLS, the successor of \NAME{SSL}). \TLS\ encrypts the datagrams of the \name{transport layer}. This means it works below the application protocols and can be used with any of them \citeweb{wikipedia:tls}.
114 115
115 Using secure tunnels that are provided by external programs, should be prefered over including encryption into the application, because the application needs not to bother with encryption then. Outgoing \SMTP\ connections can get encrypted using a secure tunnel, created by an external application (like \name{openssl}). But incoming connections can not use external secure tunnels, because the remote \NAME{IP} address is hidden then; all connections would appear to come from localhost instead. Figure \ref{fig:stunnel} depicts the situation of using an application like \name{stunnel} for incoming connections. The connection to port 25 comes from localhost and this information reaches the \MTA. Authentication based on \NAME{IP} addresses and many spam prevention methods are useless then. 116 Using secure tunnels that are provided by external programs, should be prefered over including encryption into the application, because the application needs not to bother with encryption then. Outgoing \SMTP\ connections can get encrypted using a secure tunnel, created by an external application (like \name{openssl}). But incoming connections can not use external secure tunnels, because the remote \NAME{IP} address is hidden then; all connections would appear to come from localhost instead. Figure \ref{fig:stunnel} depicts the situation of using an application like \name{stunnel} for incoming connections. The connection to port 25 comes from localhost and this information reaches the \MTA. Authentication based on \NAME{IP} addresses and many spam prevention methods are useless then.
597 598
598 \subsubsection*{The problem with ``good enough''} 599 \subsubsection*{The problem with ``good enough''}
599 600
600 The decision for later restructuring is problematic. Functionality is often more wanted than quality, so further function is prefered over better quality, as quality is still ``good enough''. But it might be still ``good enough'' the next time, and the time after that one, and so on. 601 The decision for later restructuring is problematic. Functionality is often more wanted than quality, so further function is prefered over better quality, as quality is still ``good enough''. But it might be still ``good enough'' the next time, and the time after that one, and so on.
601 602
602 Quality improving is no popular work but it is required to avoid dead ends. As more code increases quality and modularity improvement work, it is better to do it early. Afterwards all further development profits from it. 603 Quality improving is no popular work but it is required to avoid dead ends. As more code increases the work that needs to be done for quality and modularity improvements, it is better to do these improvements early. Afterwards all further development profits from it.
603 604
604 Also if some design is bad one should never hesitate to erase it and rebuild it in a sane way. 605 Also if some design is bad one should never hesitate to erase it and rebuild it in a sane way.
605 606
606 However, making such a cut is hard, especially if the bad design is still ``good enough''. 607 However, making such a cut is hard, especially if the bad design is still ``good enough''.
607 608