docs/diploma

annotate thesis/tex/2-MailTransferAgents.tex @ 89:3b5ba7331eb5

complete restructuring of whole document
author meillo@marmaro.de
date Thu, 13 Nov 2008 23:24:52 +0100
parents
children e050221efd38
rev   line source
meillo@89 1 \chapter{Mail transfer agents}
meillo@89 2
meillo@89 3 \section{\unix\ \MTA{}s}
meillo@89 4
meillo@89 5 After having read about the history of electronic mail and the basics of \mta{}s in the last chapter, this chapter introduces a group of \mta{}s. Among them, the already mentioned \sendmail. The selected group will be delimited against other groups of \MTA{}s, which are described as well.
meillo@89 6
meillo@89 7 The chosen programs will be presented to the reader in a short overview and with the most important facts. The next chapter will show a comparison of these programs in several disciplines.
meillo@89 8
meillo@89 9
meillo@89 10 \section{Types of \MTA{}s}
meillo@89 11 ``Mail transfer agent'' is a term covering a variety of programs. One thing is common to them: they transfer email from one \emph{thing} to another. These \emph{things} can be hosts, meaning independent machines, or protocols like \NAME{SMTP} and \NAME{UUCP}, between which mail is transfered.\footnote{\sendmail{}'s initial purpose was moving mail between \NAME{UUCP}, \NAME{SMTP}, and \name{Berknet}.}
meillo@89 12
meillo@89 13 Beside this common property, \MTA{}s can be very different. Some of them have \NAME{POP3} and/or \NAME{IMAP} servers included. Some can fetch mails through these protocols. Others have have all features you can think of. And maybe there are some that do nothing else but transporting email.
meillo@89 14
meillo@89 15 Following are groups of \mta{}s that will \emph{not} be regarded further.
meillo@89 16
meillo@89 17 \subsection{Relay-only \MTA{}s}
meillo@89 18 \label{subsec:relay-only}
meillo@89 19 This is the most simple kind of \MTA. It transfers mail only to defined \name{smart hosts}\footnote{\name{smart host}s are \MTA{}s that receives email and route it to the actual destination}. \name{Relay-only} \MTA{}s do not receive mail from outside the system, and they do not deliver locally.
meillo@89 20
meillo@89 21 Most \MTA{}s can be configured to act as such a \name{forwarder}. But this is usually an additional functionality.
meillo@89 22
meillo@89 23 One would use such a program to give a system the possibility to send mail, without the need to do lots of configuration. In a local network, usually the clients are set up with a \name{relay-only} \MTA, while there is one \name{mail server} that acts as a \name{smart host}. The ``dumb'' clients send mail to this one \name{mail server} which does all the work.
meillo@89 24
meillo@89 25 Examples for that group are: \name{nullmailer}, \name{ssmtp} and \name{esmtp}.
meillo@89 26
meillo@89 27
meillo@89 28 \subsection{Groupware}
meillo@89 29 Normally the term ``groupware'' does not mean one single program, but a suite of programs. They build a framework which is then populated with various modules that provide actual funktionality. Modules for mail transfer, file storage, calendars, resource management, instant messaging, etc., are commonly available.
meillo@89 30
meillo@89 31 One would use one of these program suites if the main work to do is not mail transfer, but providing integrated communication facilities and team working support for a group of people. The most common scenario are companies. They have \name{groupware} running to provide adequate services for their teams to work efficently. But one may use \name{groupware} on the home server for his family members also.
meillo@89 32
meillo@89 33 Examples are: \name{Lotus Notes}, \name{Microsoft Exchange}, \name{OpenGroupware.org} and \name{eGroupWare}.
meillo@89 34
meillo@89 35
meillo@89 36 \subsection{``Real'' \MTA{}s}
meillo@89 37 There is a third type of \mta{}s in between the minimalistic \name{relay-only} \MTA{}s and the bloated \name{groupware}. Those programs may be named ``real \MTA{}s'', or ``proper \MTA{}s'', though there is no common name. They are what is meant with the term ``\mta''.
meillo@89 38
meillo@89 39 Common to them is their focus on transfering email, while being able to act as \name{smart host}. Their variety ranges from ones mostly restricted to mail transfer (\name{qmail}) to others already having interfaces for adding further mail processing modules (\name{postfix})---thus everything in between the other two groups. %FIXME: are postfix and qmail good examples?
meillo@89 40
meillo@89 41 This group is of importance in this document. The programs selected for the comparison are ``real \MTA{}s''.
meillo@89 42
meillo@89 43
meillo@89 44
meillo@89 45 \subsection{Programs to sort out}
meillo@89 46
meillo@89 47 \name{Mail transfer agent}s can be segmented in various ways, apart from the classification above. Groups of programs wiproperties significantly different from \masqmail\ will be sorted out now.
meillo@89 48
meillo@89 49 \subsection{Non-\emph{sendmail-compatible} \MTA{}s}
meillo@89 50 Due to \sendmail's significance---described in section \ref{sec:sendmail}---compatiblity interfaces for \sendmail\ are of importance for \unix\ \MTA{}s. Being not \emph{sendmail-compatible} does not need to matter for some fields of action, but makes the program ineligible for serving as a general purpose \MTA\ on \unix\ systems.
meillo@89 51
meillo@89 52 Hence all \MTA{}s not having a \emph{sendmail-compatible} interface or not offering it as a compatibility addon, will not be covered here.
meillo@89 53
meillo@89 54 An Examples here is \name{Apache James}. %FIXME: check if correct
meillo@89 55
meillo@89 56
meillo@89 57 \subsection{Non-free software}
meillo@89 58 Only programs being \freesw\ are regarded, because comparing \freesw\ with proprietary or commercial software is not what typical users of programs like \masqmail\ do. Comparison with those non-free programs may be a point for large \freesw\ projects, trying to step into the business world. Small projects, mostly used by individuals at home, need to be compared against other projects of similar shape.
meillo@89 59
meillo@89 60 The comparison should be seen from \masqmail's point of view, so non-free software is out of the way.
meillo@89 61
meillo@89 62
meillo@89 63
meillo@89 64 \section{Popular \MTA{}s}
meillo@89 65 The programs remaining are \emph{sendmail-compatible} ``smart'' \MTA{}s that focus on mail transfer and are \freesw. One would not use a program for a job it is not suited for. Therefor only \mta{}s that are mostly similar to \masqmail\ are regarded.
meillo@89 66
meillo@89 67 For the comparision, five programs are taken. These are: \sendmail, \name{qmail}, \name{postfix}, \name{exim}, and \masqmail. The four alternatives to \masqmail\ are the most important representatives of the regarded group. % FIXME: add ref that affirm that
meillo@89 68
meillo@89 69 \name{courier-mta} is also a member of this group, being even closer to \name{groupware} than \name{postfix}. It is excluded here, because the \NAME{IMAP} and webmail parts of the mail server suite are more in focus than its \MTA. Common mail server setups even bundle \name{courier-imap} with \name{postfix}.
meillo@89 70
meillo@89 71 Other members are: \name{smail}, \name{zmailer}, \name{mmdf}, and more; they all are less important and rarely used.
meillo@89 72
meillo@89 73 Following is a small introduction to each of the five programs chosen for comparision.
meillo@89 74
meillo@89 75 \subsection{\sendmail}
meillo@89 76 \label{sec:sendmail}
meillo@89 77 \sendmail\ is the most popular \mta. Since it was one of the first \MTA{}s and was shipped by many vendors of \unix\ systems.
meillo@89 78
meillo@89 79 The program was written by Eric Allman as the successor of his program \name{delivermail}. \sendmail\ was first released with \NAME{BSD} 4.1c in 1983. Allman was not the only one working on the program. Other people developed own versions of it and a variety of flavors came up, especially in the late eighties when Allman was inactive.
meillo@89 80
meillo@89 81 \sendmail\ is focused on transfering mails between different protocols and networks, this lead to a very flexible (though complex) configuration.
meillo@89 82
meillo@89 83 The latest version is 8.14.3 from May 2008. The program is distributed under the \name{Sendmail License} as both, \freesw\ and proprietary software of \name{Sendmail, Inc.}.
meillo@89 84
meillo@89 85 Further development will go into the project \name{MeTA1} which succeeds \sendmail.
meillo@89 86
meillo@89 87 More information can be found on the \sendmail\ homepage \citeweb{sendmail:homepage} and on \citeweb{wikipedia:sendmail} and \citeweb{jdebp}.
meillo@89 88
meillo@89 89
meillo@89 90 \subsection{\name{qmail}}
meillo@89 91 \label{sec:qmail}
meillo@89 92 \name{qmail} is seen by its community as ``a modern SMTP server which makes sendmail obsolete''. It was written by Daniel~J.\ Bernstein starting in 1995. His primary goal was to create a secure \MTA\ to replace the popular, but vulnerable, \sendmail.
meillo@89 93
meillo@89 94 \name{qmail} first introduced may innovative concepts in \mta\ design and is generally seen as the first security-aware \MTA\ developed.
meillo@89 95
meillo@89 96 Since November 2007, \name{qmail} is released in the \name{public domain} which makes it \freesw. The latest release is 1.03 from July 1998.
meillo@89 97
meillo@89 98 The programs homepages are \citeweb{qmail:homepage1} and \citeweb{qmail:homepage2}. Further information about \name{qmail} is available on \citeweb{lifewithqmail}, \citeweb{wikipedia:qmail} and \citeweb{jdebp}.
meillo@89 99
meillo@89 100
meillo@89 101 \subsection{\name{postfix}}
meillo@89 102 \label{sec:postfix}
meillo@89 103 The \name{postfix} project was started in 1999 at \name{IBM research}, then called \name{VMailer} or \name{IBM Secure Mailer}. Wietse Venema's program ``attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different.''\citeweb{postfix:homepage} In fact, \name{postfix} was mainly designed after qmail's architecture to gain security. But in contrast to \name{qmail} it aims much more on being fast and full-featured.
meillo@89 104
meillo@89 105 Today \name{postfix} is taken by many \unix systems and \gnulinux distributions as default \MTA.
meillo@89 106
meillo@89 107 The latest stable version is numbered 2.5.5 from August 2008. \name{postfix} is covered by the \name{IBM Public License 1.0} which is a \freesw\ license.
meillo@89 108
meillo@89 109 Additional information is available on the program's homepage \citeweb{postfix:homepage}, on \citeweb{jdebp} and \citeweb{wikipedia:postfix}.
meillo@89 110
meillo@89 111
meillo@89 112 \subsection{\name{exim}}
meillo@89 113 \label{sec:exim}
meillo@89 114 \name{exim} was started in 1995 by Philip Hazel at the \name{University of Cambridge}. Its age is about the same as \name{qmail}'s, but the architecture is totally different.
meillo@89 115
meillo@89 116 While \name{qmail} took a completely new approach, \name{exim} forked of \name{smail-3}, and therefor is monolitic like that and like \sendmail. But having no separation of the individual components of the system, like \name{qmail} and \name{postfix} have, did not hurt. Its security is comparably good.
meillo@89 117
meillo@89 118 \name{exim} is highly configurable, especially in the field of mail policies. This makes it easy to specify how mail is routed through the system and who is allowed to send email to whom. Also interfaces for integration of virus and spam check programs are provided by design.
meillo@89 119
meillo@89 120 The program is \freesw, released under the \GPL. The latest stable version is 4.69 from December 2007.
meillo@89 121
meillo@89 122 One finds \name{exim} on its homepage \citeweb{exim:homepage}. More information about it can be retrieved from \citeweb{wikipedia:exim} and \citeweb{jdebp}.
meillo@89 123
meillo@89 124
meillo@89 125 \subsection{\masqmail}
meillo@89 126 \label{sec:masqmail}
meillo@89 127 The \masqmail\ program was written by Oliver Kurth, starting in 1999. His aim was to create a small \mta\ which is especially focused on computers with dial-up connections to the internet. \masqmail\ is easy configurable for situations which are rarely solveable with the common \MTA{}s.
meillo@89 128
meillo@89 129 \masqmail\ queues mail for destinations outside the local network if no connection to the internet is online. If the machine goes online, this mail is sent. Mail to local machines is sent immediately.
meillo@89 130
meillo@89 131 While the other \MTA{}s are more general purpose \MTA{}s, \masqmail\ aims on special situations only. Nevertheless can it handle ordinary mail transfers too.
meillo@89 132
meillo@89 133 \masqmail\ is released under the \GPL, which makes it \freesw. The latest stable version is 0.2.21 from November 2005.
meillo@89 134
meillo@89 135 The program's new homepage \citeweb{masqmail:homepage} provides further information about this \MTA.
meillo@89 136
meillo@89 137
meillo@89 138
meillo@89 139
meillo@89 140 \section{Comparison of \MTA{}s}
meillo@89 141
meillo@89 142 % http://shearer.org/MTA_Comparison
meillo@89 143 % http://www.geocities.com/mailsoftware42/
meillo@89 144 % http://fanf.livejournal.com/50917.html
meillo@89 145 % http://archives.neohapsis.com/archives/postfix/2006-07/1762.html
meillo@89 146 % http://www.oreillynet.com/lpt/a/6849
meillo@89 147 % http://www.mailradar.com/mailstat/
meillo@89 148
meillo@89 149 \subsection{First release}
meillo@89 150 sendmail: 1983
meillo@89 151
meillo@89 152 postfix: 1999
meillo@89 153
meillo@89 154 qmail: 1996 (first beta 0.70), 1997 (first general 1.0)
meillo@89 155
meillo@89 156 exim: 1995
meillo@89 157
meillo@89 158 masqmail: 1999
meillo@89 159
meillo@89 160 exchange: 1993
meillo@89 161
meillo@89 162
meillo@89 163 \subsection{Lines of code (with sloccount on debian packages)}
meillo@89 164 sendmail: 93k
meillo@89 165
meillo@89 166 postfix: 92k
meillo@89 167
meillo@89 168 qmail: 18k
meillo@89 169
meillo@89 170 exim: 54k
meillo@89 171
meillo@89 172 masqmail: 14k
meillo@89 173
meillo@89 174 exchange: (no source available)
meillo@89 175
meillo@89 176
meillo@89 177 \subsection{Architecture}
meillo@89 178 sendmail: monolitic
meillo@89 179
meillo@89 180 postfix: modular
meillo@89 181
meillo@89 182 qmail: modular
meillo@89 183
meillo@89 184 exim: monolitic
meillo@89 185
meillo@89 186 masqmail: monolitic
meillo@89 187
meillo@89 188 exchange: (unknown)
meillo@89 189
meillo@89 190
meillo@89 191 \subsection{Design goals}
meillo@89 192 sendmail: flexibility
meillo@89 193
meillo@89 194 postfix: performance and security
meillo@89 195
meillo@89 196 qmail: security
meillo@89 197
meillo@89 198 exim: general, flexible \& extensive facilities for checking
meillo@89 199
meillo@89 200 masqmail: for non-permanent internet connection
meillo@89 201
meillo@89 202 exchange: groupware
meillo@89 203
meillo@89 204
meillo@89 205 \subsection{Market share (by Bernstein in 2001)}
meillo@89 206 sendmail: 42\%
meillo@89 207
meillo@89 208 postfix: 1.6\%
meillo@89 209
meillo@89 210 qmail: 17\%
meillo@89 211
meillo@89 212 exim: 1.6\%
meillo@89 213
meillo@89 214 masqmail: (unknown)
meillo@89 215
meillo@89 216 exchange: 18\%
meillo@89 217
meillo@89 218
meillo@89 219
meillo@89 220
meillo@89 221 1) complexity
meillo@89 222
meillo@89 223 2) security
meillo@89 224
meillo@89 225 3) simplicity of configuration and administration
meillo@89 226
meillo@89 227 4) flexibility of configuration and administration
meillo@89 228
meillo@89 229 5) code size
meillo@89 230
meillo@89 231 6) code quality
meillo@89 232
meillo@89 233 7) documentation (amount and quality)
meillo@89 234
meillo@89 235 8) community (amount and quality)
meillo@89 236
meillo@89 237 9) used it myself
meillo@89 238
meillo@89 239 10) had problems with it
meillo@89 240
meillo@89 241
meillo@89 242
meillo@89 243 \section{The future of communication}
meillo@89 244 \label{chap:future-of-communication}
meillo@89 245 As globalization proceeds, long distance communication becomes more and more important. This chapter tries to locate trends in communication methods and their impact on the future for communication. The insights gathered from the analysis will be applied to \masqmail, afterwards.
meillo@89 246
meillo@89 247
meillo@89 248 \subsection{Communication methods}
meillo@89 249 \label{sec:communication-methods}
meillo@89 250 Today's long distance communication methods are either written or spoken information. And on the other side, they can be classified by the time between responses.
meillo@89 251
meillo@89 252 A classification of long distance communication methods is shown in figure %\ref{fig:}.
meillo@89 253 % slow | | |
meillo@89 254 % | | letter | days
meillo@89 255 % | | |
meillo@89 256 % | | |
meillo@89 257 % | answering | email |
meillo@89 258 % | machine | telefax | few seconds
meillo@89 259 % | | SMS |
meillo@89 260 % fast | | |
meillo@89 261 % | telephone | IM | real time
meillo@89 262 % -----------------------------------------------------
meillo@89 263 % response | spoken | written | delivery time
meillo@89 264
meillo@89 265 % TODO: find reference literature
meillo@89 266
meillo@89 267 \paragraph{Speed}
meillo@89 268 Communication gets faster in general. Slow mediums as letters get substituted by electronic mail, which is delivered within seconds. Also communication becomes more transmitted through digital channels. This can be seen at the telephone which's information is now more and more transported in bits over the internet link. Also telefaxes are succeeded by email or are transported within email. Instant messaging can be seen as the written couterpart to the telephone; not to substitute it completely, but to be used if it is more useful for the information to transmit.
meillo@89 269
meillo@89 270 Many of the digital communication methods gained success by beeing cheaper than their counterparts. One example here is instant messaging in contrast to the telephone. As phoning costs fell, it became more popular again. The last years showed, that communication cost degreased dropped generally, caused by the transport through digital channels. And nothing to see, that would make them rise again.
meillo@89 271
meillo@89 272 It seems as if in future will be low-cost communication methods available, which will be digitally transmitted.
meillo@89 273
meillo@89 274 \paragraph{Variety}
meillo@89 275 Regarding the variety of communication methods shows a change, too. Communication systems are more easy to establish today, so more get established. This leads to more methods a person uses. But not only in the amount, also in parallel. For example when two people talk to each other on the phone, one might send a URI\footnote{Uniform Resource Identifier} by email meanwhile, because oral communication is not well suited to exchange such data. Another example for in parallel used communication channels is video chatting. Ony typically sees the other person, talks to it, and additionally has a instant messaging facility for exchanging written information.
meillo@89 276
meillo@89 277 Parallel usage of different kinds of communication channels will be important in future. The most common combinations are one for spoken and one for written information. But one for dialogs and one for sending documents will be important too.
meillo@89 278
meillo@89 279 \paragraph{Hardware}
meillo@89 280 Next about the hardware needed for communicating. On the one side stands the telephone, now available as the mobile phone. It provides spoken dialog by calling, spoken messages with the included answering machine and written messages in form of short message service. On the other side stands the letter and its relatives. They need pen and paper, a telefax machine or in most today's cases a computer. They typically send documents, only instant messaging is focused on dialog.
meillo@89 281
meillo@89 282 The last years finally brought the two groups together, with \name{smart phones} being the merging element. Smart phones are computers in the size of mobile phones. They provide both functions, using it as telephones and as computers.
meillo@89 283
meillo@89 284 It matches well the requirements of telephoning and short message service, for which it was designed of course. Also providing being suitable for instant messaging in what is needed additionally to the telephone and short message service. The only problem is the minimal keyboard available to insert text. This also affects writing documents in case of email. It can be done but not very comfortably. Further communication methods include voice and video messages.
meillo@89 285
meillo@89 286 This leaves us with the need for ordinary computers for the field of exchanging documents, and as better input hardware for all written input.
meillo@89 287
meillo@89 288
meillo@89 289
meillo@89 290 \subsection{Trends for electronic mail}
meillo@89 291 \label{sec:email-trends}
meillo@89 292 The previous section stated that electronic mail will still be important in future to complete the communication methods provided by phone and instant messaging.
meillo@89 293
meillo@89 294 But will emailing in future not be the same as emailing now. This will mainly affect how email is transfered.
meillo@89 295
meillo@89 296 \paragraph{Provider oriented emailing}
meillo@89 297 Today's email structure is heavily dependent on email providers. This means, most people have email addresses from some provider. These can be the provider of their online connection (e.g.\ \NAME{AOL}, \name{T\~Online}), freemail provider (e.g.\ \NAME{GMX}, \name{Yahoo}, \name{Hotmail}) or provider that offer enhanced mail services that one needs to pay for. Outgoing mail is send either with the webmail client of the provider or using \name{mail user agent}s sending it to the provider for relay. Incoming mail is read with the webmail client or retrieved from the provider via \NAME{POP3} or \NAME{IMAP} to the local computer to be read in the \name{mail user agent}. This means all mail sending and receiving work is done by the provider.
meillo@89 298
meillo@89 299 The reason therefor is originated in the time when people used dial-up connections to the internet. A mail server needs to be online to receive email. Sending mail is no problem, but receiving it is hardly possible with an \MTA\ being few time online. Internet service providers had servers running all day long connected to the internet. So they offered email service.
meillo@89 300
meillo@89 301 \paragraph{Provider independence}
meillo@89 302 Nowadays, dial-up internet access is rare; the majority has broadband internet access paying a flat rate for it. So being online or not does not affect costs anymore, even traffic is unlimited. Today it is possible to have an own mail server running at home. The last technical problem remaining are the changing \NAME{IP} addresses one gets assigned every 24 hours. But this is easily solvable with one of the dynamic \NAME{DNS} services around; they provide the mapping of a fixed domain name to the changing \NAME{IP} addresses.
meillo@89 303
meillo@89 304 Home servers become popular in these days, for central data storage and multi media services. Being assembled of energy efficient elements, power consumption is no big problem anymore. These home servers will replace video recorders and music collections in the near future. It is also realistic that they will manage heating systems and intercoms too. Given the future leads to this direction, it is a logical step to have email and other communication will be provided by the (or one of) the own server aswell.
meillo@89 305
meillo@89 306 After \mta{}s have not been popular for users in the last time, the next years might bring them back to them. Maybe in a few years nearly everyone will have one running at home \dots\ possibly without knowing about it.
meillo@89 307
meillo@89 308 \paragraph{Is email future-safe?}
meillo@89 309 It seems as if electronic mail or a similar technology has good chances to survive the next decades. This bases on the assumption that it always will be important to send information messages. These can be notes from other people, or notifications from systems (like a broken or full hard drive in the home server, or the coffee machine ran out of coffee beans). Other communication technologies are not as suitable for this kind of messages, as email, short message service, voice mail, and the like. Telephone talks are more focused on dialog and normally interrupt people. These kind of messages should not interrupt people, unless urgent, and they do not need two-way information exchange. The second argument appies to instant messaging too. If only one message is to be send, one does not need instant messaging. Thus, one type of one-way message sending technology will survive.
meillo@89 310
meillo@89 311 Whether email will be the one surviving, or short message service, or another one, does not matter. Probably it will be \name{unified messaging}, which includes all of the other ones in it, anyway. \MTA{}s are a kind of software needed for all of these messaging methods---programs that transfer and receive messages.
meillo@89 312
meillo@89 313 \paragraph{Pushing versus polling}
meillo@89 314 The retrieval of email is a field that is about to change now. The old way is to fetch email by polling the server that holds the personal mail box. This polling is done in regular intervals, often once every five to thirty minutes. The mail transfer from the mail box to the \name{mail user agent} is initiated from the mail client side. The disadvantage herewith is the delay between mail actually arriving on the server and the user finally having the message on his screen.
meillo@89 315
meillo@89 316 To remove this disadvantage, \name{push email} was invented. Here the server is not polled every few minutes about new mail, but the server pushes new mail directly to the client on arrival. The transfer is initiated by the server. This concept became popular with the smart phones; they were able to do emailing, but the traffic caused by polling the server often was expensive. The concept workes well with mobile phones where the provider knows about the client, but it seems not to be a choice for computers since the provider needs to have some kind of login to push data to the computer.
meillo@89 317
meillo@89 318 The push concept, however could swap over to computers when using a home server and no external provider. A possible scenario is a home server receiving mail from the internet and pushing it to computers and smart phones. The configuration could be done by the user through some simple interface, like one configures his telephone system to have different telephone numbers ring on specified phones.
meillo@89 319 %FIXME: add reference to push email
meillo@89 320
meillo@89 321 \paragraph{Internet Mail 2000}
meillo@89 322 Another concept to redesign the electronic mail system, but this time focused on mail transfer is named ``Internet Mail 2000''. It was proposed by Daniel J.\ Bernstein, the creater of \name{qmail}. Similar approaches were independently introduced by others too.
meillo@89 323
meillo@89 324 As main change it makes the sender have the responsibility of mail storage; only a notification about a mail message gets send to the receiver, who can fetch the message then from the sender's server. This is in contrast to the \NAME{SMTP} mail architecture, where mail and the responsibility for it is transfered from the sender to the receiver.
meillo@89 325
meillo@89 326 \name{Mail transfer agent}s are still important in this mail architecture, but in a slightly different way. Their job is not transfering mail anymore---this makes the name missleading---they are used to transport the notifications about new mail to the destinations. This is a quite similar job as they do in the \NAME{SMTP} model. The real transfer of the mail can be done in any way, for example via \NAME{FTP} or \NAME{SCP}.
meillo@89 327
meillo@89 328 %FIXME: add references for IM2000
meillo@89 329
meillo@89 330
meillo@89 331 \section{Market analysis}
meillo@89 332
meillo@89 333 \subsection{\NAME{SWOT} analysis}
meillo@89 334 %TODO
meillo@89 335
meillo@89 336
meillo@89 337
meillo@89 338 \subsection{What will be important}
meillo@89 339 \label{sec:important-for-mtas}
meillo@89 340 Now that it is explained why email will survive (in some changed but related form), it is time to think about the properties required for \mta{}s in the next years. As the fields and kinds of usage change, the requirement change too.
meillo@89 341
meillo@89 342 Provider independence through running an own mail server at home asks for easy configuration of the \MTA. Providers have specialists to configure the systems, but ordinary people do not. Solutions are either having some home service system for computer configuration established with specialists coming to one's home to set up the systems; like it is already common for problems with the power supply or water supply system. Or configuration needs to be easy and fool-prove, to be done by the owner himself. The latter solution depends on standardized parts that fit together seamlessly. The technology itself must not be a problem itself. Only settings custom to the users environment should be left open for him to set. This of course needs to be doable on a simple configuration interface like a web interface; non-technical educated users should be able to configure the system.
meillo@89 343
meillo@89 344 \sendmail\ and \name{qmail} appear to have bad positions at this point. Their configuration is complex, thus they would need simplification wrappers around them to provide easy configuration.
meillo@89 345
meillo@89 346 The approach of wrappers around the main program to make it look easier to the outside is a good concept in general. %FIXME: add ref
meillo@89 347 It still lets the specialist do complex and detailed configuration, and also offering a simple configuration interface to novices. Further more is it well suited to provide various wrappers with different user interfaces (e.g.\ a graphical program, a website, a command line program; all of them either in a questionaire style or iteractive).
meillo@89 348
meillo@89 349 When \MTA{}s become popular on home servers and maybe even on workstations and smart phones, then performance will be less important. Providers need \mta{}s that process a large amount of mail in short time. Home servers or workstations however, do not see that much mail; they need to handle tens or hundrets of email messages per hour. Thus performance will probably not be a main requirement for an \MTA\ in the future, if they mainly run on private machines.
meillo@89 350
meillo@89 351 \name{postfix} focuses much on performance, this might not be an important point then.
meillo@89 352
meillo@89 353 New mailing concepts and architectures like push email or \name{Internet Mail 2000} will, if they succeed, require \mta{}s to adopt the new technology. \MTA{}s that are not able to change are going to be sorted out by evolution. Thus it is important to not focus too much on one use case, but to stay flexible. Allman saw this property of \sendmail\ one reason for its huge success (see section \ref{sec:sendmail}).
meillo@89 354
meillo@89 355 Another important requirement for all kinds of software will be security. There is a constant trend going from completely non-secured software from the 70s and 80s over growing security awareness in the 90s to security being a primary goal now. This leads to the conclusion that software security will even more important in the next years. As more clients get connected to the internet and especially more computers are waiting for incoming connections (like an \MTA\ in a home server), there are more possibilities to break into systems. Securing software systems will be done with increasing effort in future.
meillo@89 356
meillo@89 357 ``Plug-and-play''-able hardware with preconfigured software running can be expected to become popular. Like someone buys a set-top box to watch Pay-TV today, he might be buying a box acting as mail server in a few years. He plugs the power cable in, inserts his email address in a web interface and selects the clients (workstation computers or smart phones) to which mail should be send and from which mail is accepted to receive. That's all. It would just work then, like everyone expects it from a set-top box today.
meillo@89 358
meillo@89 359 Containing secure and robust software is a pre-requisite for such boxes to make that vision possible.
meillo@89 360
meillo@89 361 It seems as if all widely used \mta{}s provide good security nowadays. \name{qmail}'s architecture, also used in \name{postfix}, is generally seen to be conceptually more secure, however.
meillo@89 362
meillo@89 363 In summary: easy configuration, aswell as the somehow opposed flexibility will be important for future \mta{}s. Also will it be security, but not performance. \MTA{}s might become more commodity software, like web servers already are today, with the purpose to include it in many systems and the need of minimal configuration.
meillo@89 364
meillo@89 365