1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Wed Jan 21 14:48:10 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Wed Jan 21 14:48:39 2009 +0100
     1.3 @@ -108,6 +108,7 @@
     1.4  
     1.5  
     1.6  \paragraph{\RF7: Encryption}
     1.7 +\label{requirement-encryption}
     1.8  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.
     1.9  
    1.10  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}.
    1.11 @@ -599,7 +600,7 @@
    1.12  
    1.13  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.
    1.14  
    1.15 -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.
    1.16 +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.
    1.17  
    1.18  Also if some design is bad one should never hesitate to erase it and rebuild it in a sane way.
    1.19