Windows IMAP style Mail Server (WIMS)

For a better formatted document, download: [login to view URL] This is one part of a project to create a secure private electronic mail delivery system, similar to emails. Details of the overall project will be provided to suitable bidders. This part of the project is to develop a Windows based IMAP style Mail Server (WIMS) with some specific features including multi-language support. WIMS acts as the final destination for hosted mail accounts. WIMS send and receive messages directly wherever possible. WIMS operate in conjunction with a network of other Linux servers that accept messages (from the sending WIMS) when the account hosting (destination) WIMS is off-line or cannot be reached. When a mailbox account (e.g. bob@kapur.h) is added (hosting) to WIMS, security details are provided for it to login to the Linux server network over a secure connection. To avoid any confusion, the domain names associated with our private secure mail service are private to and managed by our own network service, they are not issued by Nominet, Internic or any other domain authority. The Linux servers do not relay messages but simply store them till they are collected by the destination WIMS. Periodically and when the WIMS comes back online, it contacts the relevant Linux servers for each hosted mailbox account to check for any messages (or part of a message) that may be waiting to be downloaded. All messages are encrypted (PKI) and sent over secure connections (SSL / TLS). Messages can only be sent between pre-established partners and between mail accounts from the same domain. File attachments may be large (4GB+) When a message is to be sent, WIMS encrypts (PKI) the message & attachments and contacts a designated (for the sending or ‘from’ account) Linux server, over a secure (SSL / TLS) connection, to get authorisation before it can send the message. When authorisation is granted, the message sending WIMS tries to contact the destination WIMS directly and if possible sends the message directly over a secure connection (SSL / TLS). If the destination WIMS cannot be contacted or the connection is lost mid-transfer then the sending WIMS contacts one of the designated Linux servers (that act as backup hosts for the recipient mailbox) and uploads the whole or remaining part of the message. Again, if the connection is lost from one server, WIMS will attempt to deliver the remaining part of the message to another backup server. When a message is received in its entirety, it is decrypted and the WIMS automatically generates a messagereceived receipt (without any intervention from the mail client or user) and sends it back to the message sender. Unlike conventional mail servers, WIMS do not host complete domains (i.e. you cannot create new mail accounts, for hosted domains, on WIMS; new accounts are created externally), they host individual mail accounts though all mail accounts for one or more domains may be hosted on a single WIMS. In addition to messages being sent via the mail client connecting to WIMS over TCP/IP, messages can also be sent, by creating necessary files in a designated WIMS system folder. A suitable .xml file can be created that contains all relevant details (from, to, cc, subject, message, file attachment details etc..). This folder is polled periodically and any awaiting .xml files processed by WIMS. It should be possible to prepare and send a message using nothing more than notepad. Some security measures will be required to ensure rouge programs don’t exploit this feature and start sending Spam. The messages are to be stored in a secure local database. To prevent the database size reaching its maximum limit quickly, larger file attachments may be stored externally as separate files with some obfuscation. Multilingual support. The system must be configurable for different languages though you do not have to provide translations for other languages. Customisation. The system appearance and branding should be customisable easily say using some configuration file. Event logging. For diagnostic purposes the system should have different levels of event logging from zero (logging turned off) to maximum where almost all events get logged. Updates. Implement some form of automatic web update check for new releases and bug fixes. Authentication and verification. Messages, attachments and receipts are prepared using suitable PKI security. WIMS monitor – also part of this project and also multilingual. This is a standalone application that can connect to a local or remote WIMS. It contains mailbox account authentication details and can request status / progress of all jobs / tasks being performed by WIMS on a per mailbox account basis. For example, if a message has just been sent from an account, the WIMS monitor may display the progress of the message and attachments being encrypted and later being sent. The monitor display needs to be similar to the types seen on file sharing and download type of programs like uTorrent. It should be possible to show / hide the job progress monitor display. When visible, the display monitor must be listed in the task bar. Some of the required features include: · All connections (between mail clients, WIMS and Linux servers) are secure (SSL / TLS). · Handle multiple concurrent connections (both incoming and outbound). · Handle end-to-end (WIMS – WIMS) connections through firewalls (e.g. UDP hole punching). · Provide full support for IMAP style mail client (to be developed separately). · Every mail account is created outside of WIMS (on the service Linux server) and has a profile record (like an address record) associated with it. Account details are entered in to WIMS to host the account there. · Support (differentiate) different message types (message, fax, invoice, statement, remittance etc..). · Allow large (4GB+) message attachments. · All messages and attachments are encrypted before bent sent. · Send large messages as smaller data chunks to allow transfer resumption after connection loss. · Parts of a single message may be uploaded to two or more destinations (destination WIMS or service backup Linux servers). · The system should be capable of running on Windows 7, Vista, XP and 2000. Support for Windows 98 desirable. · Should be capable of co-existing on a PC running the mail client or on a separate, dedicated system on the network. · WIMS maintains its own internal clock (for time stamping) which is set by / synchronised with the Linux server network. This time is also passed on to mail clients so that their time is also synchronised when they time stamp message headers etc.. Server side message rules. This is a wish list and not a necessity. As in MS Exchange server / Outlook, a facility to create similar message rules is desirable. Instant messaging. When a message is received, the recipient should be able to send an IM back to the sender instead of having to reply to the message. A complete IM conversation could then take place, if desired, which is ‘tied’ to the original message. If there are significant cost implications in implementing IM, then this can be incorporated at a future revision. However, the system design must make provisions for IM implementation. Web Interface. At some point down the development cycle, I may want to implement a web interface. That is, allow users to connect to WIMS from any web browser over a secure connection, similar to Squirrel mail. Again, the system design must take this into account. At the end: · You will provide all source code and full documentation. · Intellectual property passes to me. Please make your bids are for just developing WIMS. Quote separately for implementing the extra wish list items (server side rules, IM and web interface). Payment in milestones, through escrow.