4

I am currently evaluating the redemption library for converting MSG files to EML files.

RDOSession session = new RDOSession();
RDOMail msg = session.GetMessageFromMsgFile(msgFile);
msg.SaveAs(emlFile, rdoSaveAsType.olRFC822);

So far Redemption is doing a really good job here in contrast to everything else I've tested against our "wild MSG-files corpus".

Nevertheless there is an issue with internal e-mail addresses. For internal e-mail addresses the resulting EML-file does contain the personal part of the addresses only but not the real e-mail address with the @ sign.

I can see that RDOMail's recipient objects contains the real e-mail address in the SMTPAddress property in any case. But there is a difference for the Address property which contains the "real e-mail address" for external addresses but something like /O=EXAMPLE ORGANIZAION/OU=SOME GROUP/cn=Recipients/cn=FBarney for internal addresses.

The latter ones are exactly the addresses that are missing the real e-mail address in the resulting EML-file.

So I tried to override the Address property like that:

recipient.Address = recipient.SMTPAddress;

But this does not have any effect on the resulting EML-file at the end.

How to convert MSG to EML with redemption without losing the real e-mail addresses for internal addresses?

Dmitry Streblechenko
  • 62,942
  • 4
  • 53
  • 78
Fabian Barney
  • 14,219
  • 5
  • 40
  • 60
  • Related question but not addressing conversion in particular: http://www.pcreview.co.uk/threads/how-to-get-the-recipients-email-address-in-redemption.1841215/ – Fabian Barney Aug 12 '15 at 15:44

1 Answers1

5

This is an indication that EX type addresses cannot be converted to SMTP. This usually happens if the current MAPI session does not have access to the Exchange server that hosts these GAL objects. In your particular case, there is no MAPI session at all. You can either set the RDOSession.MAPIOBJECT property to Namespace.MAPIOBJECT from the Outlook Object Model to share the session with Outlook or you can call RDOSession.Logon/LogonExchangeMailbox/etc.

You can also try to specify the olRfc822_Redemption format to force Redemption to use its internal MIME convertor (it jumps through quite a few hoops to get the SMTP addresses from the message itself rather than GAL). By default olRfc822 uses the built-in Outlook convertor (IConvertorSession) if Outlook is installed.

Dmitry Streblechenko
  • 62,942
  • 4
  • 53
  • 78
  • Thanks so far, Dmitry. Conversion will be done on a dedicated conversion server which will never ever have access to the Exchange Server. Outlook will be installed on the conversion server. Using `olRfc822_Redemption` is completely out of game, because it produces the same odd results for many msg-files like our current solution. I did not get the point with the `MAPIOBJECT` yet, but this is most probably because I am lacking knowledge here. Isn't it possible to cheat the available `SMTPAddress` into the *right fields* before conversion? – Fabian Barney Aug 12 '15 at 19:11
  • 1
    Besides the recipient address, you'd also need to set the entry id. What was wrong with the olRfc822_Redemption? Can you be a bit more specific? – Dmitry Streblechenko Aug 12 '15 at 19:58
  • We've msg-files here that are missing attachments after conversion to eml for example. It's the same with olRfc822_Redemption and our current solution. But Outlook is able to show up all attachments and the olRfc822 converted eml does it, too. That's just one of several issues of about 30 problematic msg-files I've in our unit tests here. olRfc822-converted eml-files pass them all expect for the address issue described here. – Fabian Barney Aug 12 '15 at 20:21