Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 146:2c4673d983c3

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
wrote about requirements (related to directions to go)
author meillo@marmaro.de
date Mon, 15 Dec 2008 19:15:46 +0100
parents 1b0ba5151d1b
children ccf0de1ae337
comparison
equal deleted inserted replaced
145:93a47593a493 146:2c4673d983c3
35 35
36 36
37 37
38 38
39 39
40
41 \section{Requirements}
42
43 Following is a list of current and future requirements to make \masqmail\ ready for the future.
44
45
46 \subsubsection*{Large message handling}
47 Trends in the market for electronic communication in general, wants consolidated communication, hence email will be used more and more to transfer voice and video messages, leading to large messages, putting load on \mta{}s.
48
49
50 \subsubsection*{Integrated communication}
51 Integration of asynchonous email with synchronous channels seems not be possible in an evolutionary way. As only a revolutionary change of the whole email concept could enable it, it is best to focus on it. A new designed technology will be supperior to a heavily patched and bent email technology.
52
53
54 \subsubsection*{Ressource friendly software}
55 The merge of communication hardware and the move of email service from providers to homes, demands smaller and more resource-friendly \MTA{}s. The amount of mail will be lower, even if much more mail will be sent. More important will be the energy consumption and heat emission. These topics increased in relevance during the last years and they are expected to become more central. \masqmail\ is not a program to be used on large servers, but to be used on small devices. Thus focusing on energy and heat, not on performance, is the direction to go.
56
57
58 \subsubsection*{New mail transfer protocols}
59 But large data transfers are something to cover. The store-and-forward transport of email is not good suited for large data. Thus new protocols, like \NAME{QMTP} (described in section \ref{}), may become popular. \masqmail\ should be able to operate on them as it becomes neccesary.
60
61 As spam is a problem and the need for a final solution grows, \masqmail\ should be ready to support new protocols when they appear.
62
63 protocols like \NAME{SMTP} and \NAME{UUCP}, between which mail is transferred. \sendmail's initial purpose was moving mail between \NAME{UUCP}, \NAME{SMTP}, and \name{Berknet}.
64
65
66 \subsubsection*{Spam and malicious content handling}
67 Spam handling is a major threat to handle. According to the \NAME{SWOT} analysis, the goal is to reduce it to a bearable amount. Spam is a field where the the good guys tend to lose. Putting too much effort in spam handling will result in few gain. Real success will only be possible with new---better---protocols, abandonning the weak legacy technologies.
68
69 Hence \masqmail\ should be able to provide state-of-the-art spam and virus protection, but not more. This is commonly and best done using external, specialized programs that are invoked.
70
71
72 \subsubsection*{Easy configuration}
73 Having \mta{}s on many home servers and clients, requires easy and standardized configuration. The common situations sould be to set with a single action from the user. Complex configuration should be possible, but easiest should be the most common form of configuration; this will be one of several standard setups.
74
75
76
77
78
79
80
40 \section{Directions to go} 81 \section{Directions to go}
41 82
42 << plans to get masqmail more popular again (if that is the goal) >> 83 This section discusses about what shapes \masqmail\ could have---which directions the development could go to.
43 84
44 85
45 \subsection{\masqmail\ in five years}
46
47 Now how could \masqmail\ be like in, say, five years?
48
49 << requirements >>
50
51 << which parts to do >>
52
53 << how to make masqmail future-safe >>
54
55 << how to advertise masqmail >>
56
57 << why is it worth to revive masqmail? >>
58
59
60 << short term goals --- long term goals >>
61
62 << concrete decisions based on results of the last 2 chapters >>
63 86
64 87
65 88
66 89
67 \subsection{Architecture} 90 \subsection{Architecture}
68 91
69 << architecture diagram >> 92 << architecture diagram >>
70 93
71 (ssl) -> msg-in (local or remote protocol handlers) -> spam-filter (and more) -> queue -> msg-out (local-delivery by MDA, or remote-protocol-handlers) -> (ssl) 94 (ssl)
95 -> msg-in (local or remote protocol handlers)
96 -> spam-filter (and more)
97 -> queue
98 -> msg-out (local-delivery by MDA, or remote-protocol-handlers)
99 (ssl)
72 100
73 A design from scratch? 101 A design from scratch?
74 102
75 << what would be needed (effort) >> 103 << what would be needed (effort) >>
76 104
77 << would one create it at all? >> 105 << would one create it at all? >>
78 106
79 << should it be done? >> 107 << should it be done? >>
80
81
82
83 \subsection{local mail delivery}
84 But for example delivery of mail to local users is \emph{not} what \mta{}s should care about, although most \MTA\ are able to deliver mail, and many do. (\name{mail delivery agents}, like \name{procmail} and \name{maildrop}, are the right programs for this job.)
85
86
87
88 \subsection{various protocols}
89 protocols like \NAME{SMTP} and \NAME{UUCP}, between which mail is transferred.\footnote{\sendmail{}'s initial purpose was moving mail between \NAME{UUCP}, \NAME{SMTP}, and \name{Berknet}.}
90
91
92
93
94
95 108
96 http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command 109 http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command
97 http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security 110 http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security
98 http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery 111 http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery
99 http://fanf.livejournal.com/64941.html %how not to design an mta - spool file format 112 http://fanf.livejournal.com/64941.html %how not to design an mta - spool file format
100 http://fanf.livejournal.com/65203.html %how not to design an mta - spool file logistics 113 http://fanf.livejournal.com/65203.html %how not to design an mta - spool file logistics
101 http://fanf.livejournal.com/65911.html %how not to design an mta - more about log-structured MTA queues 114 http://fanf.livejournal.com/65911.html %how not to design an mta - more about log-structured MTA queues
102 http://fanf.livejournal.com/67297.html %how not to design an mta - more log-structured MTA queues 115 http://fanf.livejournal.com/67297.html %how not to design an mta - more log-structured MTA queues
103 http://fanf.livejournal.com/70432.html %how not to design an mta - address verification 116 http://fanf.livejournal.com/70432.html %how not to design an mta - address verification
104 http://fanf.livejournal.com/72258.html %how not to design an mta - content scanning 117 http://fanf.livejournal.com/72258.html %how not to design an mta - content scanning
118
119
120 \subsubsection*{local mail delivery}
121 But for example delivery of mail to local users is \emph{not} what \mta{}s should care about, although most \MTA\ are able to deliver mail, and many do. (\name{mail delivery agents}, like \name{procmail} and \name{maildrop}, are the right programs for this job.)
105 122
106 123
107 124
108 125
109 126
115 132
116 133
117 134
118 135
119 136
137
138 \subsubsection*{\masqmail\ in five years}
139
140 Now how could \masqmail\ be like in, say, five years?
141
142 << plans to get masqmail more popular again (if that is the goal) >>
143
144 << More users >>
145
146
147
148
120 \section{Work to do} 149 \section{Work to do}
150
151 << short term goals --- long term goals >>
121 152
122 << which parts to take out and do within the thesis >> 153 << which parts to take out and do within the thesis >>
123 154
124