Mercurial > docs > diploma

comparison thesis/tex/5-Improvements.tex @ 248:724cc6057105

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
complete names are now in small caps
author meillo@marmaro.de
date Sun, 11 Jan 2009 20:49:50 +0100
parents 5cfea0d05e7f
children 32e14e98cd91
comparison
equal deleted inserted replaced
247:50240b753a46 248:724cc6057105
135 \subsubsection*{Incoming channels} 135 \subsubsection*{Incoming channels}
136 136
137 \sendmail-compatible \mta{}s must support at least two incoming channels: mail submitted using the \sendmail\ command, and mail received via the \SMTP\ daemon. It is therefor common to split the incoming channel into local and remote. This is done by \qmail\ and \postfix. The same way is \person{Hafiz}'s view. 137 \sendmail-compatible \mta{}s must support at least two incoming channels: mail submitted using the \sendmail\ command, and mail received via the \SMTP\ daemon. It is therefor common to split the incoming channel into local and remote. This is done by \qmail\ and \postfix. The same way is \person{Hafiz}'s view.
138 138
139 In contrast is \name{sendmail X}: Its locally submitted messages go to the \SMTP\ daemon, which is the only connection towards the mail queue. %fixme: is it a smtp dialog? or a second door? 139 In contrast is \name{sendmail X}: Its locally submitted messages go to the \SMTP\ daemon, which is the only connection towards the mail queue. %fixme: is it a smtp dialog? or a second door?
140 \person{fanf} proposes a similar approach. He wants the \texttt{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA\ like it is done by connections from remote. The advantage here is one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module to put mail into the queue not need to be \name{setuid} or \name{setgid} because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs. 140 \person{Finch} proposes a similar approach. He wants the \texttt{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA\ like it is done by connections from remote. The advantage here is one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module to put mail into the queue not need to be \name{setuid} or \name{setgid} because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs.
141 141
142 But merging the input channels in the \SMTP\ daemon makes the \MTA\ heavily dependent on \SMTP\ being the main mail transfer protocol. To \qmail\ and \postfix\ new modules to support other ways of message receival may be added without change of other parts of the system. Also is it better to have more independent modules if each one is simpler then. 142 But merging the input channels in the \SMTP\ daemon makes the \MTA\ heavily dependent on \SMTP\ being the main mail transfer protocol. To \qmail\ and \postfix\ new modules to support other ways of message receival may be added without change of other parts of the system. Also is it better to have more independent modules if each one is simpler then.
143 143
144 With the increasing need for new protocols in mind, it seems better to have single modules for each incoming channel, although this leads to duplicated acceptance checks. 144 With the increasing need for new protocols in mind, it seems better to have single modules for each incoming channel, although this leads to duplicated acceptance checks.
145 145