If your application powered by MailBee.NET Objects or MailBee Objects needs to learn about new messages in mailbox immediately as they arrive, there are two approaches possible: waiting for notifications from the server and periodic polling the mailbox.
Waiting for notifications from the server. This means your application connects to the server and listens to the server events. Once a new message arrives to the mailbox, the server immediately sends a notification.
It wouldn't work with POP3 mailboxes as POP3 protocol doesn't support this. However, in case of IMAP protocol, it's possible to take advantage of IDLE feature.
IDLE is an optional IMAP extension, but most IMAP servers support it nowadays.
Once your application has switched the connection with IMAP server into IDLE mode, it can't send commands to IMAP server any longer but can receive notifications from it. Once your application receives a notification about a new message (or any other event), it should stop idling and start downloading messages/headers (or other appropriate activity like deleting a message which is no longer on the server in case of "message expunged" event). Once the download is complete, your application can start idling again. An important point is that duration of one IDLE session cannot be longer than 30 mins. This means your application must restart idling each 25 mins, moreover, we recommend restarting idling each 15 mins because some IMAP servers don't like to wait 30 mins and terminate connection after 20-25 mins.
Idling is quite a complex approach which involves asynchronous methods and event handlers. This complete sample demonstrates using IDLE in WinForms application (C# syntax, .NET 2.0-4.0). There is also a modern .NET 4.5 version which uses async/await methods.
It's important to understand that idling makes no sense in web applications because server-side code starts when receives a request from the web browser and terminates when responds to the request, i.e. it's usually running just for a second or less.
MailBee IMAP component (ActiveX) also supports IDLE, so IDLE approach can be used Windows/ActiveX applications as well. See The IDLE sample for MailBee IMAP4 ActiveX.
Polling mailbox approach assumes your application should periodically connect to the mail server and check if there are new messages. You need to implement "connect and check for new messages" routine in your application and create a timer which will periodically call that routine.
This approach can be used for both POP3 and IMAP protocols and this will work for both MailBee.NET Objects and MailBee Objects.
"Receiving new messages via POP3" tutorial for MailBee POP3 component (ActiveX) should be useful to you.
The same approach is viable for MailBee.NET POP3 component (.NET assembly). Please refer to MailBee.NET Objects documentation to learn about connecting to POP3 server, downloading messages, etc via MailBee.NET POP3 component.
The same approach can be used for IMAP protocol, but additionally IMAP provides a simpler way: instead of storing UIDs of already downloaded messages, you can take an advantage of read/unread (seen/unseen) flag stored on IMAP server. This is reliable if your application is the sole client accessing IMAP mailbox you need to process. If other IMAP clients (e.g. Outlook Express, Mozilla Thunderbird) are used to access the same mailbox, they can modify read/unread flags and your application would get puzzled in distinguishing between new and old messages.
If you decided to rely on IMAP server side flags, Imap.Search method (or IMAP4.Search for ActiveX version) would allow you to find UIDs of messages with UNSEEN flag.
Having those UIDs, you can easily download messages or just their headers. In ActiveX version, you can download entire messages or just headers via IMAP4.RetrieveEnvelopesEx method. When your application completely downloads a message with UNSEEN flag set, IMAP server automatically resets that flag, so the message becomes "old".