Mail.app does not use activesync, it uses ews (check in your account settings) ews means exchange web services, this is quite separate from the activesync provider that the iphone uses. I find it confusing that apple can release activesync capabilities on the iphone and not the mail.app on osx (i have 10.6.4).
This has bugged me for ages! At our company i am the only external user who has a mac, so the problem has only appeared since i started. The owa virtual directory and the activesync api has been exposed through the firewall with certificate translation but the /ews hasn't been.
Long story short, i can access exchange from mail.app and entourage when i am in the office and via VPN but not externally.
The way to make mail.app work with ews is to get the network guys to expose the /ews virtual directory to the firewall and use ssl mapping so that the external requests use the external SSL cert.
E.g.
Internal config - exchangeServer.local/ews uses the normal certificate or no cert (if possible)
External config - exchange.mydomain.com/ews uses TMG or ISA to present the certificate for that address and transports the ssl-encrypted comunication to the exchange server.
Its as much work as getting owa to work, in fact its the same setup, just with a different virtual folder.
If you still have access to the original service, the best method by far is to use the tool ìmapsync (or OfflineIMAP as an alternative).
This will allow you to temporarily sync from the old service to the new one. It will retain all of the flags as well so that unread markers are retained. It will also retain any folder structures.
The second most common way of achieving this would require some careful coordination of mail routing. That would be a file copy of the source data which would normally be either in maildir or mbox format. This may also require help from the previous mail provider unless you have shell access to the old service.
imapsync is certainly the preferred method. Trying to do a transfer using eml files is not recommended. For starters, you will have lost all of the flags and folders. In addition, trying to do this for 5-6GB per user is going to take a LONG time. You will have to do it in stages.
Additionally, I'm not really sure that Pine or MUTT is going to help doing it the way you've outlined although you may be able to write macro's to transfer the files a few at a time.
UPDATE:
As we now know that sync from the original is not possible. The best way to script input from EML files to a maildir based system (if that is what you have, it is the most common storage format for Linux IMAP servers) is to use
getmail_maildir ~/Maildir/ < email_file.eml
getmail_maildir is part of the getmail package. This only works if you have direct access to the mail folders though this is commonly true with the better hosts. Not so sure about doing this with the other mail storage format mbox but I think that getmail also has a getmail_mbox command. In addition, the Windows application "IMAPSize" has a command for converting from EML to mbox.
So again, it is much easier to migrate the emails to a physical mail store rather than trying to pass everything through IMAP. However, it may be that you have to do this because the new provider cannot provide suitable access (as would be the case if migrating to GMail for example).
If this is the case, what may be best is to migrate the EML files to maildir format using a "synthetic" local maildir (there is nothing really special about maildir except the naming conventions so you don't actually need an IMAP server to use them) and getmail_maildir. Then use IMAPSync or OfflineIMAP to push from that local maildir to the new service. That way you don't need to mess with trying to script MUTT.
Best Answer
You can try this tool: Chrome WebMail Notifier
Your question doesn't state what protocol you're using (POP3, IMAP, Exchange)... The link I've sent does
You get all the options you would expect:
And just for completeness: Firefox WebMail Notifier