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 © 2008 WeOnlyDo All Rights Reserved