Java Email client (POP3, IMAP) using server port 110

[Norman Meister]

hi all,

I need to process emails from a mailbox account.

The supplier of the email box has provided me with the host name of the server and stated the port number as 110. Also the supplier has given me with the access credentials.

My question is about the email reader client that I need to implement in Java. As per google search, 110 is the default port for POP3 interface, but can I implement the Java IMAP email client using port 110 instead?

Or in other words, is client development dependent on the type of protocol the email host supports?

Since the supplier of the email host has stated port 110, does that really mean that i can only use pop3 client to communicate with the server or can I also implement and use IMAP client that connects with the server on port 110?`

I see many advantages of using IMAP interface than POP3, specially in the context of already processed email. I only need to process emails which are new, and that can only be checked within IMAP (as per my current understanding). I could not find such check whether the email is new or not supported within pop3 protocol.

many thanks.

[Rob Spoor]

If the supplier has given you port number 110, that probably means that it's a POP server. Trying to use IMAP won't work then. Try asking the supplier if they support IMAP as well.

Regarding "new" status and POP, that should be maintained by the client. The client you're writing should keep track of (and store) which emails have already been encountered and which not. But yeah, if IMAP is available that would be better.

[Norman Meister]

Rob Spoor wrote:If the supplier has given you port number 110, that probably means that it's a POP server. Trying to use IMAP won't work then. Try asking the supplier if they support IMAP as well.

Regarding "new" status and POP, that should be maintained by the client. The client you're writing should keep track of (and store) which emails have already been encountered and which not. But yeah, if IMAP is available that would be better.

Thanks Rob for your reply. The supplier only provides POP3.

My scenario is that I have a scheduled java utility that checks the mailbox every 5 minutes. If there is a new email that I need to "forward" to another mailbox hosted on another mail server using SMTP. This other mailbox is checked by a local user using outlook. At this point, I have a problem since the application is unable to check if there is any "new" email in the INBOX. It forwards all the available set of emails in the inbox be it new or old to the other email address.

You suggested that the application should keep track of (and store) which emails have already been encountered and which not. What could be the standard criteria used for keeping track of already forwarded/old emails at the client side? Storing emails is not required and not in the scope of the client application.

Another option, I can think of is "moving" all those emails at the source mail account (which are forwarded) to another "folder". Next time, when the utitlity would check the inbox, it would it would only find any "new" email in the inbox if any. Do you think, this approach makes sense, and if yes, does POP3 api provide moving option or in other words, would that be a straight forward solution to implement in the java pop3 client?

many thanks.

[Tim Holloway]

POP isn't a very powerful protocol compared to IMAP. If I'm not mistaken, it doesn't have folders or a query-based retrieval capability. Personally, I'd run an "nmap" on the POP server and see if IMAP/IMAPS is truly not an option, since a lot of the popular email servers these days support multiple protocols. And if IMAP or IMAPS is available, lean on them. It's to their own benefit ultimately.

Every email should have a Message-Id header in it. When you download an email, keep a database of these Message-Ids and only forward the ones you haven't yet added to the database. That's less resource-intensive than keeping the entire email on file. And the Message-ID is designed to be unique, just like UUID/GUIDs are - perhaps moreso, since UUIDs and GUIDs are hash values and the email ID may be 100% unique.

[Norman Meister]

Tim Holloway wrote:POP isn't a very powerful protocol compared to IMAP. If I'm not mistaken, it doesn't have folders or a query-based retrieval capability. Personally, I'd run an "nmap" on the POP server and see if IMAP/IMAPS is truly not an option, since a lot of the popular email servers these days support multiple protocols. And if IMAP or IMAPS is available, lean on them. It's to their own benefit ultimately.

Every email should have a Message-Id header in it. When you download an email, keep a database of these Message-Ids and only forward the ones you haven't yet added to the database. That's less resource-intensive than keeping the entire email on file. And the Message-ID is designed to be unique, just like UUID/GUIDs are - perhaps moreso, since UUIDs and GUIDs are hash values and the email ID may be 100% unique.

Thanks for the pointer, Tim. Will look into that.

But how about deleting the emails from the server once they are forwarded to another email account? This way when the Java util checks the source mail account next time, it will only find new emails because older emails have already been deleted in the last run.

I also came across this thread: http://alvinalexander.com/java/javamail-search-unseen-unread-messages-mailbox-pop3

Regarding IMAP, unfortunately, I confirmed and the supplier said it is not supported.

Thanks.

[Tim Holloway]

I'm not sure that I'd trust that code. First of all, like I said, I don't believe that POP supports folders, so any "POP" code that opens folder "inbox" is suspect. Secondly, I cannot find a command in the POP3 RFC that would return "unseen/unread" messages or their IDs.

The yahoo server supports both POP and IMAP, and I suspect that if this example works it's because yahoo is serving up IMAP functions off the POP port.