Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 345:f26d63dbb22b

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
added quotes
author meillo@marmaro.de
date Tue, 27 Jan 2009 11:18:30 +0100
parents f9f925c5e2d1
children 80b2e476c2e3
comparison
equal deleted inserted replaced
344:8aa47a4b911e 345:f26d63dbb22b
155 155
156 Filtering spam can be done by either refusing spam during the \SMTP\ dialog or by checking for spam after the mail was accepted and queued. Both ways have advantages and disadvantages, so modern \MTA{}s use them in combination. 156 Filtering spam can be done by either refusing spam during the \SMTP\ dialog or by checking for spam after the mail was accepted and queued. Both ways have advantages and disadvantages, so modern \MTA{}s use them in combination.
157 157
158 Spam is identified by the results of a set of checks. Static rules, querying databases (\NAME{DNS} blacklists \cite{cole07} \cite{levine08}), requesting special client behavior (\name{greylisting} \cite{harris03}, \name{hashcash} \cite{back02}), or statistical analysis (\name{bayesian filters} \cite{graham02}) are checks that may be used. Running more checks leads to better results, but takes more system resources and more time. 158 Spam is identified by the results of a set of checks. Static rules, querying databases (\NAME{DNS} blacklists \cite{cole07} \cite{levine08}), requesting special client behavior (\name{greylisting} \cite{harris03}, \name{hashcash} \cite{back02}), or statistical analysis (\name{bayesian filters} \cite{graham02}) are checks that may be used. Running more checks leads to better results, but takes more system resources and more time.
159 159
160 Doing some basic checks during the \SMTP\ dialog seems to be a must \cite[page~25]{eisentraut05}. Including them into the \MTA\ makes them fast to avoid \SMTP\ dialog timeouts. For modularity and risibility reasons internal interfaces to specialized modules seem to be best. 160 Doing some basic checks during the \SMTP\ dialog seems to be a must \cite[page~25]{eisentraut05}. Including them into the \MTA\ makes them fast to avoid \SMTP\ dialog timeouts. For modularity and reusability reasons internal interfaces to specialized modules seem to be best. \person{Raymond} says: ``Modularity (simple parts, clean interfaces) is a way to organize programs to make them simpler.'' \cite[chapter~1]{raymond03}.
161 161
162 More detailed checks after the message is queued should be done using external scanners. Interfaces to invoke them need to be defined. (See also the remarks about \name{amavis} in the next section.) 162 More detailed checks after the message is queued should be done using external scanners. Interfaces to invoke them need to be defined. (See also the remarks about \name{amavis} in the next section.)
163 163
164 164
165 165
550 550
551 \subsubsection*{Repairing} 551 \subsubsection*{Repairing}
552 552
553 Besides these advantages of existing code, one must not forget that further work on it is often repair work. Small bug fixes are not the problem, but adding something for which the software originally was not designed for are problems. Such work often destroys the clear concepts of the software, especially in interweaved monolithic code. 553 Besides these advantages of existing code, one must not forget that further work on it is often repair work. Small bug fixes are not the problem, but adding something for which the software originally was not designed for are problems. Such work often destroys the clear concepts of the software, especially in interweaved monolithic code.
554 554
555 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, currently. This means it is time to invest into a redesigning to build up a more modern product. 555 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 redesigning to build up a more modern product.
556 556
557 In the author's view is \masqmail\ already needing a redesign since about 2003 when the old design was still quite suitable \dots\ it already delayed too long. 557 In the author's view is \masqmail\ already needing a redesign since about 2003 when the old design was still quite suitable \dots\ it already delayed too long.
558 558
559 %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. 559 %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.
560 560
568 568
569 A new design does protect against such dead ends. 569 A new design does protect against such dead ends.
570 570
571 Changing requirements are one possible dead end if the software does not evolve with them. A famous example is \sendmail, which had an almost monopoly for a long time. But when security became important \sendmail\ was only repaired instead of removing the problem sources---its insecure design. Thus security problems reappeared and over the years \sendmail's market share shrank as more secure \MTA{}s became available. \sendmail's reaction to the new requirements, in form of \name{sendmail X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s. Redesigning a software as requirements change helps keeping it alive. % fixme: add quote: ``one thing surely remains: change'' (something like that) 571 Changing requirements are one possible dead end if the software does not evolve with them. A famous example is \sendmail, which had an almost monopoly for a long time. But when security became important \sendmail\ was only repaired instead of removing the problem sources---its insecure design. Thus security problems reappeared and over the years \sendmail's market share shrank as more secure \MTA{}s became available. \sendmail's reaction to the new requirements, in form of \name{sendmail X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s. Redesigning a software as requirements change helps keeping it alive. % fixme: add quote: ``one thing surely remains: change'' (something like that)
572 572
573 Another danger is the dead end of complexity which is likely to appear by constantly working 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. %fixme: proof 573 Another danger is the dead end of complexity which is likely to appear by constantly working 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.
574 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.
575 574
576 575
577 576
578 577
579 578
581 580
582 The avoidance of dead ends is essential for further development on current code too. Hence it is mandatory to refactor the existing code base sooner or later. Most important is the intention to modularize it, as it improves many quality requirements, eases further development, and essentially improves security. 581 The avoidance of dead ends is essential for further development on current code too. Hence it is mandatory to refactor the existing code base sooner or later. Most important is the intention to modularize it, as it improves many quality requirements, eases further development, and essentially improves security.
583 582
584 One example how modular structure makes it easy to add further functionality: \person{Sill} describes that integrating the \name{amavis} filter framework into the \qmail\ system can be done by renaming the \name{qmail-queue} module to \name{qmail-queue-real} and renaming the \name{amavis} to \name{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in the \qmail\ system needs to be changed. This is a very admirable approach, but only possible in a modular system that consists of independent executables. 583 One example how modular structure makes it easy to add further functionality: \person{Sill} describes that integrating the \name{amavis} filter framework into the \qmail\ system can be done by renaming the \name{qmail-queue} module to \name{qmail-queue-real} and renaming the \name{amavis} to \name{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in the \qmail\ system needs to be changed. This is a very admirable approach, but only possible in a modular system that consists of independent executables.
585 584
586 This thesis showed several times that modularity is the key property for good software design. This property can hardly be retrofitted into software. Hence development on base of current code will need a throughout restructuring too to modularize the source code. Thus a new design is similar to such a throughout refactoring, except without depending on current code. 585 This thesis showed several times that modularity is a key property for good software design. This property can hardly be retrofitted into software. Hence development on base of current code will need a throughout restructuring too to modularize the source code. Thus a new design is similar to such a throughout refactoring, except without depending on current code.
587 586
588 587
589 588
590 589
591 590
622 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. 621 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.
623 622
624 Also if some design is bad one should never hesitate to erase it and rebuild it in a sane way. 623 Also if some design is bad one should never hesitate to erase it and rebuild it in a sane way.
625 624
626 However, making such a cut is hard, especially if the bad design is still ``good enough''. 625 However, making such a cut is hard, especially if the bad design is still ``good enough''.
626
627 \person{Doug McIlroy}, a person with important influence on \unix\ especially by inventing the \unix\ pipe, gives valuable advice: ``To do a new job, build afresh rather than complicate old programs by adding new features.'' and: ``Don't hesitate to throw away the clumsy parts and rebuild them.'' \cite{mcilroy78}.
627 628
628 629
629 630
630 631
631 632