You are here

mail migration from Luminis (Sun One) to live@edu

Submitted by robking on Tue, 12/13/2011 - 11:44

Hi there,

I'm currently investigating how to migrating mailbox contents from our Luminis mail system to Microsoft's Live@edu cloud-based mail service, using live@edu's email migration tool.

One of the requirements for this migration is that we are not allowed to use the users' passwords. So, I'm trying to figure out how to use an administrator account on our Luminis system that has access to each users mailbox.

There's a page here which makes reference to using an administrator account to do so:
I've tried the examples that use an administrator account, but have not been successful.

Here's my questions:

  1. Do you know if Sun One Messaging Server supports an admin-type account to fetch a users mail via IMAP?
  2. Do you know what the expected format of the .csv file should be when using an admin account to access a user's email?

I know there's a number of you who are now on live@edu. Has anyone ever gone through a similar mail migration? If so, did you use an administrator-type account for migrating each mailbox?

We're using Sun One Messaging Server 6.3. (I've checked the documentation for something that deals with this topic, but I cannot seem to find any relevant info)

Any assistance would be appreciated greatly!


Luminis Version:

I don't think there is a way. We did migrate our Sun One 5x a couple years ago and I had to reset user account passwords then use imapsync to finish the task.
Good luck,

Copy and paste of an email thread where our email admin was describing our process of migrating to gmail using imapsync

local.service.proxy, local.service.proxy.adminpass

In JSMS (or whatever name your version has), those
variables hold the name and password for an administrative user
in IMAP. This user can assume the identity of any other message
store user for the purposes of accessing that user's mailbox.
There are two ways to use it:

1. Authenticate to the server using the admin user's
credentials, then assume the target user's identity using the
PROXYAUTH command, e.g.:

C: . LOGIN adminuser adminpass
S: . OK Completed
C: . PROXYAUTH otheruser
S: . OK Completed

at which point IMAP commands will access otheruser's mailbox
until the session is finished. This is an older method that
works only with the Netscape/Sun servers, but works fine.

2. Authenticate using the SASL PLAIN method, which per
RFC 4616 can include the admin and target users' names and the
admin user's password, separated by NULs, e.g.:

C: adminusertargetuseradminpass
S: . OK

This method works on a wider variety of servers, including

We used the ``imapsync'' package, basically a wrapper to
Mail::IMAP, with the PROXYAUTH method to access user mailboxes to
copy to the Gmail server. Unfortunately, Gmail does not support
this concept of an administrative mailbox user, so we had to set
user passwords beforehand on the Gmail side. Then we would call
imapsync for each user like this:

imapsync --host1 --port1 993 \
--user1 $loginid --proxyauth1 \
--authuser1 adminuser --passfile1 $passfile1 \
--ssl1 --host2 --port2 993 \
--user2 $loginid\ --password2 $uid \
--ssl2 --delete2 --expunge2 \
--exclude \'Trash|Drafts|Deleted|Deleted Items|Sent|Sent Items\'

where $passfile1 held the admin password for our server, and the
--delete2 --expunge2 options would delete and expunge messages on
the Gmail side that weren't on the local side. We could therefore
``pre-sync'' large mailboxes from the live server.

We used separate wrappers to run multiple instances of
imapsync in parallel up to a 50-session limit.