comparison thesis/tex/4-MasqmailsFuture.tex @ 406:1d527ad76c97

spell checking
author meillo@marmaro.de
date Sun, 08 Feb 2009 23:51:48 +0100
parents a3d9a63defa7
children 4b151c1b3835
comparison
equal deleted inserted replaced
405:a3d9a63defa7 406:1d527ad76c97
163 \index{plain text} 163 \index{plain text}
164 164
165 The common way to encrypt \SMTP\ dialogs is using \name{Transport Layer Security} (short: \NAME{TLS}, the successor of \NAME{SSL}). \NAME{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}. 165 The common way to encrypt \SMTP\ dialogs is using \name{Transport Layer Security} (short: \NAME{TLS}, the successor of \NAME{SSL}). \NAME{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}.
166 \index{tls} 166 \index{tls}
167 167
168 Using secure tunnels that are provided by external programs should be preferred 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. 168 Using secure tunnels that are provided by external programs should be preferred 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 the local host 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 from local host and exactly this information is available to the \MTA. Authentication based on \NAME{IP} addresses and many spam prevention methods are useless then.
169 \index{secure tunnel} 169 \index{secure tunnel}
170 \index{stunnel} 170 \index{stunnel}
171 \index{openssl} 171 \index{openssl}
172 172
173 \begin{figure} 173 \begin{figure}
486 486
487 \paragraph{\RG\,6: Testability} 487 \paragraph{\RG\,6: Testability}
488 \index{testability} 488 \index{testability}
489 The testability suffers from missing modularity, too. Testing program parts is hard to do. Nevertheless, it is done by compiling parts of the source to two special test programs: One tests reading input from a socket, the other tests constructing messages and sending it directly. Neither is designed for automated testing of source parts, they are rather to help the programmer during development. 489 The testability suffers from missing modularity, too. Testing program parts is hard to do. Nevertheless, it is done by compiling parts of the source to two special test programs: One tests reading input from a socket, the other tests constructing messages and sending it directly. Neither is designed for automated testing of source parts, they are rather to help the programmer during development.
490 490
491 Two additional scripts exist to send a set of mails to differend kinds of recipients. They can be used for automated testing, but both check only the function of the whole system, not its parts. 491 Two additional scripts exist to send a set of mails to different kinds of recipients. They can be used for automated testing, but both check only the function of the whole system, not its parts.
492 \index{test program} 492 \index{test program}
493 493
494 494
495 \paragraph{\RG\,7: Performance} 495 \paragraph{\RG\,7: Performance}
496 \index{performance} 496 \index{performance}
533 533
534 The importance is ranked from `-{}-' (not important) to `++' (very important). The pending work is ranked from `-{}-' (nothing) to `++' (very much). Large work tasks with high importance need to receive much attention, they need to be in focus. In contrast should small, low importance work tasks receive few attention. Here the focus for a task is calculated by summing up the importance and the pending work with equal weight. Normally, tasks with high focus are the ones of high priority and should be done first. 534 The importance is ranked from `-{}-' (not important) to `++' (very important). The pending work is ranked from `-{}-' (nothing) to `++' (very much). Large work tasks with high importance need to receive much attention, they need to be in focus. In contrast should small, low importance work tasks receive few attention. Here the focus for a task is calculated by summing up the importance and the pending work with equal weight. Normally, tasks with high focus are the ones of high priority and should be done first.
535 535
536 The functional requirements that receive highest attention are \RF\,6 (authentication), \RF\,7 (encryption), and \RF\,8 (spam handling). Of the non-functional requirements, \RG\,1 (security), \RG\,2 (reliability), and \RG\,4 (extendability), rank highest. 536 The functional requirements that receive highest attention are \RF\,6 (authentication), \RF\,7 (encryption), and \RF\,8 (spam handling). Of the non-functional requirements, \RG\,1 (security), \RG\,2 (reliability), and \RG\,4 (extendability), rank highest.
537 537
538 These tasks are presented in more detail in a todo list, now. The list is sorted by focus and then by importance. 538 These tasks are presented in more detail in a to-do list, now. The list is sorted by focus and then by importance.
539 539
540 540
541 \subsubsection*{\TODO\,1: Encryption (\RF\,7)} 541 \subsubsection*{\TODO\,1: Encryption (\RF\,7)}
542 \index{enc} 542 \index{enc}
543 Encryption is chosen for number one as it is essential to provide privacy. Using \NAME{STARTTLS} for encryption is definitely needed and should be added first; encrypted data transfer is hardly possible without support for it. 543 Encryption is chosen for number one as it is essential to provide privacy. Using \NAME{STARTTLS} for encryption is definitely needed and should be added first; encrypted data transfer is hardly possible without support for it.
717 717
718 \person{Doug McIlroy}, a person with important influence on Unix especially by inventing the Unix pipe, demands: ``To do a new job, build afresh rather than complicate old programs by adding new features.'' \cite{mcilroy78}. 718 \person{Doug McIlroy}, a person with important influence on Unix especially by inventing the Unix pipe, demands: ``To do a new job, build afresh rather than complicate old programs by adding new features.'' \cite{mcilroy78}.
719 \index{pipe} 719 \index{pipe}
720 \index{Unix} 720 \index{Unix}
721 721
722 Repair strategies are useful, but only in the short-time view and in times of trouble. If the future is bright, however, one does best by investing into a software. As shown in section~\ref{sec:market-analysis-conclusion}, the future for \MTA{}s is bright. This means it is time to invest into a redesign with the intension to build up a more modern product. 722 Repair strategies are useful, but only in the short-time view and in times of trouble. If the future is bright, however, one does best by investing into a software. As shown in section~\ref{sec:market-analysis-conclusion}, the future for \MTA{}s is bright. This means it is time to invest into a redesign with the intention to build up a more modern product.
723 723
724 In the author's view is \masqmail\ already needing this redesign since about 2003 when the old design was still quite suitable \dots\ it already delayed too long. 724 In the author's view is \masqmail\ already needing this redesign since about 2003 when the old design was still quite suitable \dots\ it already delayed too long.
725 \index{masqmail!new design} 725 \index{masqmail!new design}
726 726
727 %Clinging to much to existing code will be no help, it is an indicator for fear. Having the courage to through bad code away to make it better, shows the view forward. 727 %Clinging to much to existing code will be no help, it is an indicator for fear. Having the courage to through bad code away to make it better, shows the view forward.
744 \index{sendmail} 744 \index{sendmail}
745 745
746 Redesigning a software as requirements change helps keeping it alive. 746 Redesigning a software as requirements change helps keeping it alive.
747 \index{redesign} 747 \index{redesign}
748 748
749 The knowledge of \person{Heraclitus}, a Greek philosopher, shall be an inspriation: ``Nothing endures but change.'' 749 The knowledge of \person{Heraclitus}, a Greek philosopher, shall be an inspiration: ``Nothing endures but change.''
750 750
751 Another danger is the dead end of complexity which is likely to appear by constant work on the same code base. It is even more likely if the code base has a monolithic architecture. A good example for simplicity is \qmail\ which consists of small independent modules, each with only about one thousand lines of code. Such simple code makes it obvious to understand what it does. The \name{suckless} project \citeweb{suckless.org} for example advertises such a philosophy of small and simple software by following the thoughts of the Unix inventors \cite{kernighan84} \cite{kernighan99}. Simple, small, and clear code avoids complexity and is thus also a strong prerequisite for security. 751 Another danger is the dead end of complexity which is likely to appear by constant work on the same code base. It is even more likely if the code base has a monolithic architecture. A good example for simplicity is \qmail\ which consists of small independent modules, each with only about one thousand lines of code. Such simple code makes it obvious to understand what it does. The \name{suckless} project \citeweb{suckless.org} for example advertises such a philosophy of small and simple software by following the thoughts of the Unix inventors \cite{kernighan84} \cite{kernighan99}. Simple, small, and clear code avoids complexity and is thus also a strong prerequisite for security.
752 \index{qmail} 752 \index{qmail}
753 \index{suckless software} 753 \index{suckless software}
754 \index{Unix} 754 \index{Unix}
827 \index{Free Software} 827 \index{Free Software}
828 828
829 Free Software ``sells'' if it has a good user base. For example: Although \qmail\ is somehow outdated and its author has not released any new version since about ten years, \qmail\ still has a very strong user base and community. 829 Free Software ``sells'' if it has a good user base. For example: Although \qmail\ is somehow outdated and its author has not released any new version since about ten years, \qmail\ still has a very strong user base and community.
830 \index{qmail} 830 \index{qmail}
831 831
832 Good concepts, sound design, and a sane philosophy gives users good feelings for the software and faith in it. They become interested in using it and to contribute. In contrast do constant repaire work and reappearance of weaknesses leave a bad feeling. 832 Good concepts, sound design, and a sane philosophy gives users good feelings for the software and faith in it. They become interested in using it and to contribute. In contrast do constant repair work and reappearance of weaknesses leave a bad feeling.
833 833
834 The motivation of most volunteer developers is their wish to do good work with the goal to create good software. Projects that follow admirable plans towards a good product will motivate volunteers to help. More helpers can get the 2,5 man-years for a new design in less absolute time done. Additionally is a good developers base the best start for a good user base, and users define a software's value. 834 The motivation of most volunteer developers is their wish to do good work with the goal to create good software. Projects that follow admirable plans towards a good product will motivate volunteers to help. More helpers can get the 2,5 man-years for a new design in less absolute time done. Additionally is a good developers base the best start for a good user base, and users define a software's value.
835 \index{development!motivation} 835 \index{development!motivation}
836 836
837 837