Hi, For a project I'm on I wrote some code that makes MMBase act as an SMTP server (yes, it implements RFC 2821: but only those commands strictly necessary for a compliant implementation). It will listen to a configurable port and receive emails that are given to it. These emails are parsed and put in MMBase objects. The code is fully configurable: _everything_ can be changed in the module XML (see below).
The question now raises where this code should be placed. The most obvious place would be the 'email' application Daniel is working on. Can this extra functionality be added to this project? Should this be an independant hack? (since the email application deals with outgoing email, and this is incoming email functionality). For those of you interested in the code it is attached to this email. The design is as follows: The main module starts a 'listening' thread that waits for incoming messages. New connections are handled by the 'handler' thread that is spawned for a message: here the dirty work is done. After communication with the client, the message is stored inside MMBase. We have some code lying here at the EO that parses MIME attachments from emails and creates 'attachments' objects for them. I am still looking into this to port this to the new smtp module; this might be added in a future version. Johannes ================================== The following configuration options can be set in the module xml. The first few are mandatory: - hostname: the hostname to send out in the greeting messages - port: the port to listen on - domains: the name (or list of names, seperated with the ',' character) to accept mail for. - emailbuilder: the main builder in which emails are stored - emailbuilder.bodyfield: the field in which the body of the mail should be stored - usersbuilder: the builder that is used to find the user for which the email is intended - usersbuilder.accountfield: the 'username' field which is used to search the intended recipient. In this setup, new 'emailbuilder' objects will be related to a found 'userbuilder' object. The following optional properties can be set also: - mailboxbuilder: optional extra builder that specifies which kind of object should be found related to the 'usersbuilder' object. - mailboxbuilder.where: in case several 'mailboxbuilder' objects can be related to your 'usersbuilder' object, you can specify a WHERE clause to select the correct one to relate incoming messages to. - mailboxbuilder.notfound: what to do in case a mailbox could not be found? (currently only supports "bounce") Furthermore, there are several optional properties that allow other fields of the 'emailbuilder' objects to be set: - emailbuilder.tofield - emailbuilder.ccfield - emailbuilder.fromfield - emailbuilder.subjectfield - emailbuilder.headersfield - emailbuilder.datefield
smtpmodule.zip
Description: Zip archive
