|
89
|
1 \chapter{The \masqmail\ project}
|
|
|
2
|
|
|
3 %TODO: have text by oliver here?
|
|
|
4
|
|
|
5 \section{Purpose of \masqmail}
|
|
|
6
|
|
|
7 \subsection{Target field}
|
|
|
8 Its original author, Oliver Kurth, sees \masqmail\ so:
|
|
|
9 \begin{quote}
|
|
|
10 MasqMail is a mail server designed for hosts that do not have a permanent internet connection eg. a home network or a single host at home. It has special support for connections to different ISPs. It replaces sendmail or other MTAs such as qmail or exim.
|
|
|
11 \end{quote}
|
|
|
12
|
|
|
13 \masqmail\ is inteded to cover a specific niche: non-permanent internet connection and different \NAME{ISP}s.
|
|
|
14
|
|
|
15 Although it can basically replace other \MTA{}s, it is not generally aimed to do so. The package description of \debian\citeweb{packages.debian:masqmail} states this more clearly by changing the last sentence to:
|
|
|
16 \begin{quote}
|
|
|
17 In these cases, MasqMail is a slim replacement for full-blown MTAs such as sendmail, exim, qmail or postfix.
|
|
|
18 \end{quote}
|
|
|
19 \masqmail\ is a good replacement ``in these cases'', but not generally, since is lacks features essential for running on mail servers. It is primarily not secure enough for being accessable from untrusted locations.
|
|
|
20
|
|
|
21 The program is best used in home networks, which are non-permanently connected to the internet. \masqmail\ sends mail to local destinations, like users on the same machine and on other machines in the local net, immediately. Email to recipients outside the local net are queued when offline and sent when a online connection gets established.
|
|
|
22
|
|
|
23 Further more does \masqmail\ respect online connections through different \NAME{ISP}s; a common thing for dial-up connections. In particular can different sender addresses be set, dependent on the \NAME{ISP} that is used. This prevents mail to be likely classified as spam.
|
|
|
24
|
|
|
25
|
|
|
26
|
|
|
27 \subsection{Typical usage}
|
|
|
28 This section describes situations that make senseful use of \masqmail.
|
|
|
29
|
|
|
30 A home network consisting of some workstations without a server. The network is connected to the internet by dial-up or broadband. Going online is initiated by computers inside the local net. \NAME{IP} addresses change at least once every day.
|
|
|
31
|
|
|
32 Every workstation would be equiped with \masqmail. Mail transfer within the same machine or within the local net works straight forward. Outgoing mail to the internet is sent, to the concerning \NAME{ISP} for relaying, whenever the router goes online. Receiving of mail from outside needs to be done by a mail fetch program, like the \masqmail\ internal \NAME{POP3} client or \name{fetchmail} for example. The configuration for \masqmail\ would be the same on every computer, except the hostname.
|
|
|
33
|
|
|
34 For the same network but having a server, one could have \masqmail\ running on the server and using simple forwarders (see \ref{subsec:relay-only}) to the server on the workstations. This setup does only support mail transfer to the server, but not back to a workstation; also sending mail to another user on the same workstation is not possible.
|
|
|
35
|
|
|
36 A better setup is to run \masqmail\ on every machine %FIXME
|
|
|
37
|
|
|
38
|
|
|
39
|
|
|
40 \subsection{What makes it special}
|
|
|
41
|
|
|
42 As main advantage, \masqmail\ makes it easy to set up an \MTA\ on workstations or notebooks without the need to do complex configuration or to be an mail server expert.
|
|
|
43
|
|
|
44 Workstations use %FIXME
|
|
|
45
|
|
|
46
|
|
|
47 \subsection{Alternatives?}
|
|
|
48 % http://anfi.homeunix.org/sendmail/dialup10.html
|
|
|
49
|
|
|
50 \section{History}
|
|
|
51 %TODO: let oliver prove read it!
|
|
|
52 %FIXME: add references
|
|
|
53 %FIXME: where does the name come from: masqdialer (guessed)
|
|
|
54
|
|
|
55 The date of the first release (version 0.0.1) is unknown.
|
|
|
56 The only information available is, that it was packaged for \debian\ at 15\nth\ of September in 1999.
|
|
|
57 Further releases were made every few weeks or month during 2000, 2001 and 2002.
|
|
|
58 Development ended in mid-2003 in a hard stop.
|
|
|
59 The last ordinary release known to me is version 0.2.20, released on 4\nth\ of June in 2003.
|
|
|
60
|
|
|
61 During the time of development, Oliver released 53 versions.
|
|
|
62 That means a new release in less than every 20 days in average!
|
|
|
63
|
|
|
64 Mentionable are the four \emph{beta} releases of version 0.1.8 (named with the trailing letters `a' to `d') in winter 2000/2001 and the security-fix 0.1.15.1 in 2002.
|
|
|
65
|
|
|
66 One extra release (version 0.2.21) was made by him in November 2005.
|
|
|
67 This one is only available from the \debian\ pool.
|
|
|
68 Comparing it to version 0.2.20 shows, that no source code was altered.
|
|
|
69 Only building documents (like Makefiles) and \debian\ packageing documents were changed.
|
|
|
70 That leeds to the assumption that this last release was specificly created for the needs of \debian---to fix some errors in the package.
|
|
|
71
|
|
|
72 In May 2000 the minor version number increased to `1'.
|
|
|
73 Nothing special is mentioned in the documentation about that.
|
|
|
74 When it increased again to start the 0.2.x releases, Oliver titled them as the ``development branch'' of \masqmail.
|
|
|
75 At that second time, he started developing the 0.2.x ``development branch'', continuing to work on the 0.1.x series.
|
|
|
76 His parallel work on both branches lasted for four month, and one additional last release, numbered 0.1.17, one more year later.
|
|
|
77
|
|
|
78
|
|
|
79
|
|
|
80 \section{Taking \masqmail}
|
|
|
81
|
|
|
82
|
|
|
83
|
|
|
84
|
|
|
85 \section{About \freesw\ projects}
|
|
|
86
|
|
|
87 % http://www.faqs.org/docs/artu/
|
|
|
88
|
|
|
89 There are several differences between \freesw\ projects and projects about proprietary software.
|
|
|
90 To understand \freesw\ projects, one needs to understand \freesw\ itself first.
|
|
|
91
|
|
|
92 \subsection{About \freesw}
|
|
|
93 The term ``Free Software'' was coined by the \name{Free Software Foundation} (short: \NAME{FSF}), founded by Richard~M.\ Stallman (known as ``RMS'') in 1985.
|
|
|
94 Although various licenses make software free, none of them represents the thinking of \freesw\ like the the \GNU\ \gpl\ (short: \GPL). Its first version was written by Stallman in 1989.
|
|
|
95 One could say, the \GPL\ catalized the \name{Free Software movement}.
|
|
|
96
|
|
|
97 % http://www.fsf.org/about/what-is-free-software
|
|
|
98
|
|
|
99 After all, the \GPL\ was not the first \freesw\ license used.
|
|
|
100 The \name{MIT License} (or \name{X Consortium License}) for example is older; published in 1988.
|
|
|
101 Licenses providing the same rights have been used since long time ago.
|
|
|
102 But none of them was so often (re)used by other projects---thus gattering less awareness.
|
|
|
103 Further more was the \GPL\ created to be a \emph{general} license for all kinds of programs, unlike most other licenses written for one particular program.
|
|
|
104
|
|
|
105 \freesw\ gives freedoms to its users.
|
|
|
106 In contrast to proprietary software restricting the users freedom.
|
|
|
107 The freedoms (or rights) the user has are stated in the \name{Free Software Definition} of the \NAME{FSF}. Namely these are:
|
|
|
108 % http://www.gnu.org/philosophy/free-sw.html
|
|
|
109 % http://www.fsf.org/licensing/essays/free-sw.html
|
|
|
110 \begin{enumerate}
|
|
|
111 \item The freedom to run the program, for any purpose (freedom 0).
|
|
|
112 \item The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
|
|
|
113 \item The freedom to redistribute copies so you can help your neighbor (freedom 2).
|
|
|
114 \item The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
|
|
|
115 \end{enumerate}
|
|
|
116
|
|
|
117
|
|
|
118 \subsection{The term ``Open Source''}
|
|
|
119 \name{Open Source Software} often stands for the same as \freesw.
|
|
|
120 But there is an essential difference: \name{Open Source} focuses on the availability of source code, while \freesw\ is about freedoms for people.
|
|
|
121
|
|
|
122 \name{Open Source Software} is a subset of \freesw, meaning: All \freesw\ is \name{Open Source}, but there exists \name{Open Source Software} that is not free.
|
|
|
123
|
|
|
124 % http://www.gnu.org/philosophy/open-source-misses-the-point.html
|
|
|
125 % http://catb.org/~esr/open-source.html
|
|
|
126
|
|
|
127
|
|
|
128 \subsection{Development of \freesw}
|
|
|
129 Having source code available and the right to modify it, encouridges programmers to actually do so.
|
|
|
130 Their modifications are manifoldly.
|
|
|
131 Some tailor the software to their needs.
|
|
|
132 Some add features.
|
|
|
133 Some do it just for fun.
|
|
|
134 There are no limitations---whoever wants to, may work on it.
|
|
|
135
|
|
|
136 Since the boom of the internet, \freesw\ typically is developed by an open community of programmers interested in the software.
|
|
|
137 The process of development is watchable by everyone.
|
|
|
138
|
|
|
139 The other, now less common, method is a more closed group, developing in a ``sealed'' room, but releasing finished versions to the public.
|
|
|
140
|
|
|
141 Eric~S.\ Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral} \cite{catb}.
|
|
|
142
|
|
|
143 The following text will focus on the ``bazaar'' model.
|
|
|
144
|
|
|
145
|
|
|
146 \subsection{The role of the community}
|
|
|
147 \freesw\ projects rise and fall with their community!
|
|
|
148
|
|
|
149 Most \freesw\ programs are developed by a very small group of programmers, often only one person.
|
|
|
150 But they are used by many people.
|
|
|
151 In between the programmers and the users, are people located who are a bit of both.
|
|
|
152 These are the ones that write documentation, find bugs and probably even fix it.
|
|
|
153 They discuss on mailing lists, bulletin boards and \NAME{IRC} chats.
|
|
|
154 The program is often spread by their ``advertising''.
|
|
|
155
|
|
|
156 The \emph{community} consists of the actual developers and all users that contribute to the program.
|
|
|
157 Contribution can be one of the described ways, or others like providing a server for the project website for example.
|
|
|
158
|
|
|
159 \emph{Community} is everyone who is in contact through the project.
|
|
|
160 Be it on the mailing list, the discussion board, or by telling the developers about a new feature wanted.
|
|
|
161
|
|
|
162 There will hardly be a community if no communication channels are available.
|
|
|
163 If the development team does not provide them, there is a chance that encouraged users set them up on their own.
|
|
|
164 But this is rare and the program needs to be very popular. %TODO: maybe include an example here (w3m?)
|
|
|
165
|
|
|
166 Projects without a good community tend to die sooner or later.
|
|
|
167
|
|
|
168
|
|
|
169 \subsection{Evolution of a community}
|
|
|
170 Let us look at the process a community establishes: In most times it's only one who has an idea, in the beginning.
|
|
|
171 He starts developing.
|
|
|
172 When others get in contact with the project, there may be some who are so much interested that they start co-developing.
|
|
|
173 Others report bugs, and some only use the program.
|
|
|
174
|
|
|
175 After some time, one will find a small group of core developers, a larger group of contributers (bugs, patches, documentation) and a very large group of users.
|
|
|
176 The size ratio of the groups vary by type of project.
|
|
|
177
|
|
|
178 One should have that in mind, when starting a \freesw\ project.
|
|
|
179
|
|
|
180
|
|
|
181 \subsection{Creating a strong community}
|
|
|
182 Building up a good community needs some effort of the main developers.
|
|
|
183 %TODO: search for documents about this topic
|
|
|
184
|
|
|
185 First communication channels need to be set up, to enable the growth of a community.
|
|
|
186
|
|
|
187 Second, development should be visible by everyone who is interested in it.
|
|
|
188 Time between work done on the project and its visibility to the public should be kept short.
|
|
|
189 This makes it interesting for other developers to join.
|
|
|
190 Developers are the core of a community.
|
|
|
191
|
|
|
192 Third, there is a rule of thumb that should be followed: ``Release early, release often!'' \cite{catb}.
|
|
|
193 Releases are (more) stable versions, primary for users.
|
|
|
194 They should be created, frequently.
|
|
|
195 People will more likely use programs of active projects.
|
|
|
196
|
|
|
197 Fourth, the developers should try to get the users ``in the boat''.
|
|
|
198 Good communities have a large group of users that do not only receive, but also give something back to the project.
|
|
|
199 The project leaders should motivate users to contribute.
|
|
|
200 This unlocks a big work force and gets lot of unexiting work done.
|
|
|
201
|
|
|
202 Fifth, documentation matters.
|
|
|
203 Good documentation makes it easy for users and developers to start.
|
|
|
204 And it helps to avoid a lot of unsatisfaction.
|
|
|
205 Documentation is something that shows quality and that people care about the project.
|
|
|
206
|
|
|
207 And sixth, project leaders should be good souvereigns.
|
|
|
208 They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
|
|
|
209
|
|
|
210 Not to forget: Every work that was done, every contribution that was made and every idea received needs to be honored in an appropriate way!
|
|
|
211 Volunteer work lives by acknowledgement of the effort spent.
|
|
|
212
|
|
|
213
|
|
|
214
|
|
|
215
|
|
|
216
|
|
|
217 \section{Project infrastructure}
|
|
|
218
|
