The information in this article is only for those who administer Resource Accounts where the mail is automatically retrieved by an application, such as a ticketing system, web bulletin board, or discussion list archiver. Everyone else should leave now.

In most cases, the applications mentioned above have instructions on how to set them up to retrieve mail through a POP or IMAP connection. Typically they require you to store credentials (username and password) in the setup for the application. 

We recommend that you do not use POP if at all possible.

Entering Credentials

Since Resource Accounts do not have their own password, you must first obtain a HoldingID (the steps for creating and assigning privileges to a HoldingID can be found in our Automated Processes article).

Use the following information in your automated process to access the Resource Account.

Userid

@cornell.edu\yourega where yourega is the name part of your EGA's email address, that is, everything to the left of the @ symbol

Password

the HoldingID's password

Server (use for all servers)

outlook.office365.com

Port

IMAP: 143 (with StartTLS) or 993 (with SSL)

POP with SSL encryption: 995

Connection security

SSL/TLS

Dealing with MIME

Exchange stores mail in a database. It parses the incoming email into its components, and then reconstructs the email when it is fetched. It may not always put the email back together in the same order or with the same MIME types as the original email. It may convert plain-text messages to an equivalent MIME type. Your application will need to deal with full MIME-encoded email, possibly by adding a MIME parsing stage before passing the message to the application. The approach you take will vary depending on the structure of the application and the platform on which it runs.

Dealing with IMAP

Applications that use IMAP may encounter problems with Microsoft's implementation. There are many differences from other IMAP implementations, and some Standards violations. You may need to check that your application can respond appropriately to any errors.

There are some known problems with fetching large messages using the IMAP partial fetch command. Segments may be returned with an incorrect length header, leading the application to stop before the entire message has been read. The workaround in this case seems to be to always fetch the full message, or to ignore the length header and read until an error is returned. This can also arise in listing messages in a mailbox that has more than about 3000 messages.  

There have also been reported problems in the handling of messages with digital signatures that cause otherwise valid signatures to appear invalid.

Test Early, Test Often

If you feel your application may hit any of the issues that are described above, begin testing as early as possible to identify potential problems and to leave yourself sufficient time to work out solutions. Construct a rigorous test plan that presents your application with all the combinations of valid and invalid input that might present themselves.