Understanding login strings with POP3/IMAP

Published 03-31-2004 09:21 PM 42.4K Views

Of the various processes for logging into a POP3/IMAP4 service of the Exchange server, the most commonly used is Basic Authentication through an SSL encrypted session.  When choosing this method, each client is asked to provide a username and password.  While this process may seem relatively strait forward in a simple, 1 domain topology, there are issues that can arise when organizations become complex (such as through a merger or acquisition, or when companies are using Exchange in a hosted environment.)  Therefore, understanding the process by which a user’s credentials are mapped to an Exchange mailbox can help answer many questions.

While the logon process is transparent to a user using an email client (such as Outlook Express), the process of Basic Authentication involves a client connecting to the server, waiting for a response, and then sending the username and password combo for logging in.  This process can be tested by using a telnet application, and manually issuing commands to the server.  For POP3, this is a 2-step process with the client sending the username using the USER command, waiting for a response, and then issuing a password using the PASS command.  For IMAP4 the process is done with one command, the LOGIN command, where the username and password are supplied in one request.


telnet exchangeserver 110
Server:> +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7217.0 (secundapin.corpdomain.extest.microsoft.com) ready.
Client:> user johndoe
Server:> +OK
Client:> pass j0hnsPa$$word
Server:> +OK User successfully logged on.

telnet exchangeserver 143
* OK Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7217.0 (secundapin.corpdomain.extest.microsoft.com) ready.
Client:>. login johndoe j0hnsPa$$word
Server>. OK LOGIN completed.

In both examples, the positive response from the server indicates that the user has authenticated to the server, and that their default mailbox is open for them to being operations against.

Using this simple method of operations, there are a great deal of ‘assumptions’ that are made.  First, the server assumes that ‘johndoe’ exists within the current domain of the Exchange server.  This may not always be the case, and if this is not the case, then it is necessary for the user to preface their username with a domain entry, and forward ‘/’ indicating the domain from which they are a part of.

. login corpdomain/johndoe j0hnsPa$$word

Another assumption made is that the user’s mailbox matches the users username.  The ‘mailbox’ can be thought of as the container in the Mailbox Storage database that holds the users data.  In the Active Directory Users and Computers snap-in, this is referred to as the “Alias”, and can be seen by navigating to the user, right click -> Properties -> Exchange General.  Additionally, if you are familiar with the Lightweight Directory Access Protocol (LDAP), then this property exists on the user as ‘mailNickname’.  To specify a particular mailbox, append the mailbox to the username string using a trailing ‘/’ and then the ‘Alias”

. login corpdomain/johndoe/johnsMailbox j0hnsPa$$word

In order to specify a mailbox, the complete domain/username/mailbox string is required.  Should the server see only a 2 item entry, (I.E. username/mailbox) then it will be interpreted as domain/username, not as username/mailbox. 

Appending a mailbox entry to the username is also useful for accessing a mailbox that is not the users ‘default’ mailbox, such as the mailbox of another user to which the person has access too.

. login corpdomain/johndoe/marysMailbox j0hnsPa$$word

Finally, I noted that the users ‘mailbox’ need not match the users ‘username’ (and in the previous example, it did in fact, not.)  If this is the case, then the mailbox must be appended to the username string, otherwise the login attempt will fail with an “unknown user name or bad password” error message.  (Essentially, the server is replying “unable to access a mailbox named “johndoe” using these credentials.)  Once the mailbox alias is appended, the login will succeed.

Client:> . login corpdomain/johndoe j0hnsPa$$word
Server:> . NO Logon failure: unknown user name or bad password.
Client:> . login corpdomain/johndoe/johnsMailbox j0hnsPa$$word
Server:> . OK LOGIN completed.



Using the User Principal Name (UPN logon)

Due to issues that can occur with users sharing the same ‘username’ between domains in an organization, the Active Directory system implements a second type of ‘username’ known as the “User Principal Name”.  This property is the joining of the users ‘username’ and the Fully Qualified Domain Name (FQDN) of the users domain.  For example, our user John Doe is a member of the corporate domain known as “Corpdomain”, this domain has an FQDN of ‘corpdomain.com’.  Therefore, John’s UPN is ‘johndoe@corpdomain.com’

The UPN property is very similar to a users primary-SMTP address, and in many cases, the two are similar.  (However, with nearly all of the properties described in this article, they need not be similar, and it is when these properties are altered from their original state that login’s fail)  The UPN can be viewed through the Active Directory Users and Computers snap-in by navigating to the user, right click -> Properties -> Account, it will be listed here under User logon name.  In this dialog, the User Logon Name is actually referring to the combination of 2 text boxes, not just the 1 text box the header is above.

Using a UPN logon is the same as using a simplified username

Client:> . login johndoe@corpdomain.com j0hnsPa$$word
Server:> . OK LOGIN completed.

The rules for appending a mailbox alias still apply as well

Client:> . login johndoe@corpdomain.com/marysMailbox j0hnsPa$$word
Server:> . OK LOGIN completed.

Since the FQDN of the domain is present in the UPN logon, there is no need for the user to ever preface the username string with the domain.  In fact, doing so will cause the login to be denied.

Client:> . login corpdomain/johndoe@bobbypin.com j0hnsPa$$word
Server:> . NO Logon failure: unknown user name or bad password

One big advantage of using the UPN logon, is that the mailbox alias need not match any particular part of the username string for there to be a successful login.  Such as in the case of where ‘. login corpdomain/johndoe’ would fail in the case that john’s Mailbox alias was ‘johnsMailbox’, using ‘. login johndoe@corpdomain.com’ will succeed.  This is because of the guaranteed uniqueness of the UPN for the user, and therefore the server doesn’t have to make as many assumptions when determining which mailbox the user wishes to access.

- Benjamin Spain

Not applicable
A very Useful link on understandin pop3 or imap login strings has been posted which will help. I can work my way around pop3 and smtp but knew nothing about imap. I've spent the best part of two days struggling...
Not applicable
Here are some simple directions for selecting a folder, getting a summary range of message Froms and dates, and then getting a full message from IMAP:

. Select <folder>
. Fetch <low>:<high> (flags body[header.fields (date from)])
. Fetch <msg> rfc822
. logout

<folder> is folder and path such as inbox
<low><high> are the low and high index numbers you want to the date/from fields to be returned
<msg> is the index number of the message you want to retrieve.
Not applicable
Thank you!

Just waht I needed to troubleshoot my issue keep'em coming.
Not applicable
Hi ,
I am unable to login to imap using my squirelmail when my passwor is having hexa characters like á·Pàww.
it i shoiwng bad password.
Not applicable
Try encasing the password in quotes (")
Not applicable
Enclosing the password in quotes does not help with Exchange 2003 IMAP from Outlook Express 6 (SP1) when the password contains the # symbol. This is a valid Windows password, but I cannot pass it to IMAP successfully. The exact same configuration works fine if I change the password to remove the # symbol or to substitute a letter/number. I see this as a security issue needing attention. How can we get users to use strong passwords when something like Exchange creates obstacles?

Not applicable
Also, I've tried escaping the # as:

# (C-style)
#35; (HTML-style, using delimited ASCII value in decimal notation)
#035 (fixed-length ASCII value)
## (typical "repeat the special character" approach)

And I've done all of this in a telnet session, so don't let my mention of Outlook Express suggest that the fix should be done there. No stateful inspection firewall in the middle, neither. Just plain bug in Exchange.

As best I can tell from RFC2060, either quotes or the escape character should do the trick, subject to any implementation-specific password requirements. And there isn't a more Windows-specific messaging product than Exchange. If only we were Premier so I could demand a QFE...
Not applicable
No need for a QFE when Service Pack 1 was released a few hours later. Problem seems to be fixed.
Not applicable
we have been having performance issues with heavy POP & IMAP users. I am thinking it can be attributed to http://support.microsoft.com/?id=318228

1) is there any way to be 100% sure this is the cause of the issue? (other than closely monitoring every aspect of the server and using process of elimination)

2) do the registry changes in the article take affect immediately, require services restarted, or require a reboot?

Thanks a million - i love the exchange blogs!
Not applicable
Hi Adam,

While this is a bit out of scope of blogs (more in the scope of Newsgroups or PSS call) - you can see how effective the cache is by monitoring the MSExchangeDSACCESS caches > Cache hits/sec and Cache misses/sec to see if cache would benefit from being bigger.

I am still looking into it but I would suggest restarting the SA to make sure that the changes take effect.

Please open up a case with our Support if problems continue!
Not applicable
Yes - I know blogs aren't really for this, but I gotta tell you it's tempting, but I will restrain myself. The thing is, I just can't justify using a PSS case for such small questions such as these, and forums & newsgroups sometimes don't have the answers. Oh well ...
Version history
Last update:
‎Jul 01 2019 02:54 PM
Updated by: