Each license includes one year of free updates, and unlimited lifetime technical support. Remember that each developer must have his own design-time license.
General information
WeOnlyDo! COM ImapServer ActiveX control is component that can be easily integrated into your applications to provide full IMAP4rev1 protocol server implementation. All you need to do is to put it on VB form, call it's Start method and it's immediately accepting connections by your clients! It fully supports commands defined in RFC2060.
About IMAP protocol
IMAP stands for Internet Message Access Protocol. It is a method of accessing electronic mail or bulletin board messages that are kept on a (possibly shared) mail server. In other words, it permits a "client" email program to access remote message stores as if they were local.
IMAP's ability to access messages (both new and saved) from more than one computer has become extremely important as reliance on electronic messaging and use of multiple computers increase, but this functionality cannot be taken for granted: the widely used Post Office Protocol (POP) works best when one has only a single computer, since it was designed to support "offline" message access, wherein messages are downloaded and then deleted from the mail server. This mode of access is not compatible with access from multiple computers since it tends to sprinkle messages across all of the computers used for mail access. Thus, unless all of those machines share a common file system, the offline mode of access that POP was designed to support effectively ties the user to one computer for message storage and manipulation. (taken from http://www.imap.org/).
Difference between POP3 and IMAP4
Difference between well known POP3 protocol and IMAP4 is that IMAP supports access to multiple folders - while POP3 knew only INBOX (one folder with messages). Instead of using your local system to create folders and move received messages to them for local archival, IMAP4 allows you to do the same - but still for messages to remain on remote system. This way you can access your messages from anywhere, using any client that supports IMAP4 (even web based emails) and still have access to *ALL* emails. Backward compatibility to POP3 still exists - almost every IMAP4 server have one folder called 'INBOX', and this is the same folder (and only folder!) that you access when you use POP3 protocol. Keep in mind that 'folder' is same as 'mailbox' since UNIX keeps all emails in one file, while we plan to keep emails in our samples as separate files, but idea is the same. INBOX folder is very important in this process. Because of this, INBOX object should always exist in your code because most clients will first try to access it! You might even add this folder automatically when user logs in, just to make sure client doesn't receive an error.
WeOnlyDo! Implementation of IMAP server
wodImapServer is IMAP4rev1 implementation as defined by RFC2060.
Since wodImapServer is COM object and not the full application, there's few things developer should look after - simply because COM objects cannot deal with information that should be preserved between the sessions. Most important is to keep UID information (UNIQUE ID) for folders and messages. If you do so - wodImapServer will work flawlessly with any client that connects to it. On each client action wodImapServer will fire appropriate event where you can internally handle the action and return positive or negative result. You should also deal with message flags.
wodImapServer does not deal with message storage - you should do it by yourself. It will deal with structures and references to folders and messages - but actual contents of messages cannot be handled by wodImapServer. Rather, it will depend on your code when messages are accessed, hoping that you provided properly formatted messages and proper flag information. If you don't - it will not complain, but IMAP clients may...
You should consider all wodImapServer folder as virtual folders - none of them doesn't necessarily exist on your system. Each time wodImapServer requires list of folders, or list of messages - event is fired to notify you to populate his collections with appropriate information - and that's all. You can keep messages in database, on external system, or wherever you need - as long as you can provide necessary information on wodImapServer's request.
Additional notes
NOTE: In DEMO version you cannot change GreetingMessage property, and cannot Deny user in Connected event.
Add to cart
General information
Copyright © 2001-2013 WeOnlyDo All Rights Reserved