1 \chapter{\masqmail's present and future}

2

3 \section{Existing code base}

4 Here regarded is version 0.2.21 of \masqmail. This is the last version released by Oliver \person{Kurth}, and the basis for my thesis.

5

6

7 \subsubsection*{Features}

8

9 \masqmail\ accepts mail on the command line and via \SMTP. Mail queueing and alias expansion is supported. \masqmail\ is able to deliver mail to local mailboxes (in \name{mbox} or \name{maildir} format) or pass it to a \name{mail delivery agent} (like \name{procmail}). Mail destinated to remote locations is sent using \SMTP\ or can be piped to commands, being gatesways to \NAME{UUCP} or \NAME{FAX} for example.

10

11 Outgoing \SMTP\ connections feature \SMTP-\NAME{AUTH} and \SMTP-after-\NAME{POP} authentication, but incoming connections do not. Using wrappers for outgoing connections is supported. This offers a two way communication through a wrapper application like \name{openssl}.

12 %todo: what about SSL/TLS encryption?

13

14 \masqmail\ focuses on non-permanent online connections, thus a concept of online routes is used. One may configure any amount of routes to send mail. Each route can have criterias, like matching \texttt{From:} or \texttt{To:} headers, to determine if mail is allowed to be sent using it. Mail to destinations outside the local net gets queued until \masqmail\ is informed about the existance of a online connection.

15

16 The \masqmail\ executable can be called under various names for sendmail-compatibility reasons. This is organized by symbolic links with different names pointing to the \masqmail\ executable. The \sendmail\ names are \path{/usr/lib/sendmail} and \path{/usr/sbin/sendmail} because many programs expect the \mta\ to be located there. Further more \sendmail\ supports calling it with a different name instead of supplying command line arguments. The best known of this shortcuts is \path{mailq}, which is equivilent to calling it with the argument \verb+-bq+. \masqmail\ recognizes the names \path{mailq}, \path{smtpd}, \path{mailrm}, \path{runq}, \path{rmail}, and \path{in.smtpd}. The first two are inspired by \sendmail. Not implemented is the name \path{newaliases} because \masqmail\ does not generate binary representations of the alias file.\footnote{A shell script located named \path{newaliases}, that invokes \texttt{masqmail -bi}, can provide the command to satisfy other software needing it.} \path{hoststat} and \path{purgestat} are missing for sendmail-compatibility.

17 %masqmail: mailq, mailrm, runq, rmail, smtpd/in.smtpd

18 %sendmail: hoststat, mailq, newaliases, purgestat, smtpd

19

20 Additional to the \mta\ job, \masqmail\ also offers mail retrieval services with being a \NAME{POP3} client. It can fetch mail from different remote locations, dependent on the active online route.

21

22

23

24 \subsubsection*{The code}

25

26 \masqmail\ is written in the C programming language. The program, as of version 0.2.21, consists of 34 source code and eight header files, containing about 9,000 lines of code\footnote{Measured with \name{sloccount} by David A.\ Wheeler.}. Additionally, it includes a \name{base64} implementation (about 300 lines) and \name{md5} code (about 150 lines). For systems that do not provide \name{libident}, this library is distributed as well (circa 600 lines); an available shared library however has higher precedence in linking.

27

28 The only mandatory dependency is \name{glib}---a cross-platform software utility library, originated in the \NAME{GTK+} project. It provides safer replacements for many standard library functions. It also offers handy data containers, easy-to-use implementations of data structures, and much more.

29

30

31 With \masqmail\ comes the small tool \path{mservdetect}; it helps setting up a configuration that uses the \name{mserver} system to detect the online state. Two other binaries get compiled for testing purposes: \path{readtest} and \path{smtpsend}. All three programms use \masqmail\ source code; they only add a file with a \verb+main()+ function each.

32

33

34 \masqmail\ does not provide an interface to plug in modules with additional functionality. There exists no add-on or module system. The code is only separated by function to the various source files. Some functional parts can be included or excluded by defining symbols. Adding maildir support at compile time, means giving the option \verb+--enable-maildir+ to the \path{configure} call. This preserves the concerning code to get removed by the preprocessor. Unfortunately the \verb+#ifdef+s are scattered through all the source, leading to a FIXME(holperig) code base.

35

36

37

38

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

81 \section{Directions to go}

82

83 This section discusses about what shapes \masqmail\ could have---which directions the development could go to.

84

85

86

87

88

89

90 \subsection{Architecture}

91

92 << architecture diagram >>

93

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)

100

101 A design from scratch?

102

103 << what would be needed (effort) >>

104

105 << would one create it at all? >>

106

107 << should it be done? >>

108

109 http://fanf.livejournal.com/50917.html %how not to design an mta - the sendmail command

110 http://fanf.livejournal.com/51349.html %how not to design an mta - partitioning for security

111 http://fanf.livejournal.com/61132.html %how not to design an mta - local delivery

112 http://fanf.livejournal.com/64941.html %how not to design an mta - spool file format

113 http://fanf.livejournal.com/65203.html %how not to design an mta - spool file logistics

114 http://fanf.livejournal.com/65911.html %how not to design an mta - more about log-structured MTA queues

115 http://fanf.livejournal.com/67297.html %how not to design an mta - more log-structured MTA queues

116 http://fanf.livejournal.com/70432.html %how not to design an mta - address verification

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.)

122

123

124

125

126

127

128

129

130

131

132

133

134

135

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

149 \section{Work to do}

150

151 << short term goals --- long term goals >>

152

153 << which parts to take out and do within the thesis >>

154