I've been working on compiling all of the RFCs relevant to the creation of
a new MTA designed around the architecture of qmail, and I've gotten to
the point where I wanted to share my design ideas as well as some of the
information I've compiled on SMTP and its defined extensions. First off,
inside this email are my initial design goals listed at a high level.
Additionally there are 2 links after the design document:
The first is a text document where I've listed all of the RFCs that
appear to be the most current documents for various parts of how SMTP
(and MTAs in general) should behave. I may have missed something, but not
much :) Items with RFC numbers indented more than one space are
subsidiary documents to the less indented document listed above it.
The second is a spreadsheet listing all of the RFC-documented SMTP
extensions, verbs and parameters/arguments to those verbs, including
those from base SMTP/ESMTP. There are 4 tabs - the first 3 are identical
except for sort order, and the last is the result of a simple survey of
SMTP servers I took to see which extensions are actually advertised,
along with whether I would implement it or not if I moved forward with
this project.
Here are the basic design goals - please let me know what you think.
--BEGIN--
The MTA Project (codename: jsmail) is intended to be a modern
reimplementation of qmail (http://cr.yp.to/qmail.html) providing core
functionality as specified by current Internet Standards (as defined by
STDxxxx) and Best Current Practices (BCPxxxx), updated by current draft
standards (namely, RFC5321/5322). Additional SMTP extensions and other
functionality will be implemented using binary plugin APIs that do not
require patching or recompiling to add new functionality.
The major goals of this project are as follows:
1. Binary drop-in compatibility with major SMTP qmail components when
configured for minimum functionality. Major components are <smtpd>,
<queue>, <send> (including clean and todo), <lspawn>, <local>, <rspawn>,
<remote> and <inject>. Additional smaller pieces will likely be
replicated as their need is determined. No QMTP support is planned at
this time.
2. Built-in functionality to support the required and recommended parts of
STD0010 (as updated by RFC5321), STD0011 (as updated by RFC5322), STD0003
(as relates to STD0010), STD0013 (as relates to STD0010), STD0060,
STD0071, STD0072, and STD0073 (STD0076 support will be handled via plugin
as it does not require core implementation status). Also core support for
BCP0138 (using RFC2034 for implementation) for enhanced status codes, and
support for all recommendations from BCP0030. All advanced functionality
beyond RFC5321 minimal requirements will be configurable to turn it off.
3. Modular system of adding additional functionality at runtime (no
recompiling needed) either via API hooks for processing or loadable plugin
libraries (e.g., new ESMTP extensions).
4. New APIs and extension of existing qmail APIs for added functionality -
not all required for initial implementation:
a. Common API in <smtpd> for help, sender and recipient checks for
envelope scanning.
i. Database interface (CDB support by default, others via plugin)
ii. Program interface using checkpassword API
(helo\0sender\0recipient\0\0)
b. Extend the <queue> and <send> envelope format to allow additional
sender- and recipient-specific information as passed using ESMTP
extensions for later use.
c. <queue> outputs response message on fd 4 with specific exit codes.
d. Common program API in <queue> for content scanning.
e. Common API in <remote> to allow for send processing of messages
(e.g., DKIM signing).
f. <send> processes messages so that multiple recipients at the same
domain are sent in a single command to <rspawn>. Number of recipients
per connection is configurable.
g. <rspawn> accepts multiple recipients and passes them to <remote>,
which already accepts them.
h. <remote> connection multiplexer to show remote to reuse existing
connections sending multiple messages to the same domain.
--END--
RFC Listing:
https://drive.google.com/open?id=0BwHcG0dvZKc9aXNuSVloSGtBaTQ&authuser=0
(E)SMTP Extenstion/Verb List
https://drive.google.com/open?id=1mzoUbav_9Ds6MGw7UI5HwltxYmzzFHvkTxzoEqkSjC8&authuser=0
I look forward to hearing what people think, especially whether or not
they think this is a worthwhile project and what they agree or disagree
with from a design perspective.
Josh
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
josh@honorablemenschen.com
a new MTA designed around the architecture of qmail, and I've gotten to
the point where I wanted to share my design ideas as well as some of the
information I've compiled on SMTP and its defined extensions. First off,
inside this email are my initial design goals listed at a high level.
Additionally there are 2 links after the design document:
The first is a text document where I've listed all of the RFCs that
appear to be the most current documents for various parts of how SMTP
(and MTAs in general) should behave. I may have missed something, but not
much :) Items with RFC numbers indented more than one space are
subsidiary documents to the less indented document listed above it.
The second is a spreadsheet listing all of the RFC-documented SMTP
extensions, verbs and parameters/arguments to those verbs, including
those from base SMTP/ESMTP. There are 4 tabs - the first 3 are identical
except for sort order, and the last is the result of a simple survey of
SMTP servers I took to see which extensions are actually advertised,
along with whether I would implement it or not if I moved forward with
this project.
Here are the basic design goals - please let me know what you think.
--BEGIN--
The MTA Project (codename: jsmail) is intended to be a modern
reimplementation of qmail (http://cr.yp.to/qmail.html) providing core
functionality as specified by current Internet Standards (as defined by
STDxxxx) and Best Current Practices (BCPxxxx), updated by current draft
standards (namely, RFC5321/5322). Additional SMTP extensions and other
functionality will be implemented using binary plugin APIs that do not
require patching or recompiling to add new functionality.
The major goals of this project are as follows:
1. Binary drop-in compatibility with major SMTP qmail components when
configured for minimum functionality. Major components are <smtpd>,
<queue>, <send> (including clean and todo), <lspawn>, <local>, <rspawn>,
<remote> and <inject>. Additional smaller pieces will likely be
replicated as their need is determined. No QMTP support is planned at
this time.
2. Built-in functionality to support the required and recommended parts of
STD0010 (as updated by RFC5321), STD0011 (as updated by RFC5322), STD0003
(as relates to STD0010), STD0013 (as relates to STD0010), STD0060,
STD0071, STD0072, and STD0073 (STD0076 support will be handled via plugin
as it does not require core implementation status). Also core support for
BCP0138 (using RFC2034 for implementation) for enhanced status codes, and
support for all recommendations from BCP0030. All advanced functionality
beyond RFC5321 minimal requirements will be configurable to turn it off.
3. Modular system of adding additional functionality at runtime (no
recompiling needed) either via API hooks for processing or loadable plugin
libraries (e.g., new ESMTP extensions).
4. New APIs and extension of existing qmail APIs for added functionality -
not all required for initial implementation:
a. Common API in <smtpd> for help, sender and recipient checks for
envelope scanning.
i. Database interface (CDB support by default, others via plugin)
ii. Program interface using checkpassword API
(helo\0sender\0recipient\0\0)
b. Extend the <queue> and <send> envelope format to allow additional
sender- and recipient-specific information as passed using ESMTP
extensions for later use.
c. <queue> outputs response message on fd 4 with specific exit codes.
d. Common program API in <queue> for content scanning.
e. Common API in <remote> to allow for send processing of messages
(e.g., DKIM signing).
f. <send> processes messages so that multiple recipients at the same
domain are sent in a single command to <rspawn>. Number of recipients
per connection is configurable.
g. <rspawn> accepts multiple recipients and passes them to <remote>,
which already accepts them.
h. <remote> connection multiplexer to show remote to reuse existing
connections sending multiple messages to the same domain.
--END--
RFC Listing:
https://drive.google.com/open?id=0BwHcG0dvZKc9aXNuSVloSGtBaTQ&authuser=0
(E)SMTP Extenstion/Verb List
https://drive.google.com/open?id=1mzoUbav_9Ds6MGw7UI5HwltxYmzzFHvkTxzoEqkSjC8&authuser=0
I look forward to hearing what people think, especially whether or not
they think this is a worthwhile project and what they agree or disagree
with from a design perspective.
Josh
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
josh@honorablemenschen.com