Hello,
MapiMessage.FromMailMessage(source, options)
source only accepts file as string, can you please consider adding stream overload so we can pass an Eml stream as source?
I found using this will fix many of my conversion problems, but unfortunately not accepting stream as input 
Ok. We got your problem and will consider it.
Thank you,
MapiConversionOptions.Format = OutlookMessageFormat.Unicode
Does it have some parameter to convert to OFT instead of MSG?
To save from additional load and save?
If not, can you please kindly consider it?
And a question: when reading a pst, how to distinguish a MapiMessage is msg or oft ?
Thanks.
It won’t work, you can’t convert to OFT MapiMessage or MSG MapiMessage. Because there is no difference between them. The difference appears only after saving to MSG format.
There is no way. The PST format does not distinguish between OFT or MSG.
Hello, sorry to ask but any hope to get this in 23.5?
MapiMessage.FromMailMessage(stream overload)
From a developer’s POV, even for a newbie like me, adding such overloads will surely take less than 5 minutes 
We reviewed the request and reached the following conclusion:
var eml = MailMessage.Load(emlStream);
var msg = MapiMessage.FromMailMessage(eml, options);
So we have no plans to add FromMailMessage overload.
Hello,
Objection: There’s a logical fallacy here:
The name says that MapiMessage is converted from a MailMessage object :: True
If we say Stream is not a MailMessage, String is also not, if String is, Stream also can be! Logical fallacy!
I remember this was not just to save a few lines of code! But to prevent some conversion issues I had, this method did not have those issues, maybe because of bypassing an additional MailMessage.LoadOptions, every Load/Save Options can be destructive!
Since this is not harmful in any way, not time-consuming to add, and can be helpful, it seems like unreasonable obstinacy!
Just like MailMessage.Body case, which in case message has no plain text part, it must be string.empty or nothing, but the html parsed plain version is returned here!
And your response:
Maybe. But many users are confused by .Body == Nothing whereas HtmlBody returns a non-empty string. So it was decided to return a value even if there is no plain text part.
Those users when using MapiMessage which its Body/BodyHtml/BodyRtf properties are prefectly working as expected, will not be confused?!
Not an obstinacy, I forgot that there is already an overloaded method FromMailMessage(string). My apologies. Then, yes, it makes sense to add an overload with stream too. I have created the ticket to it: EMAILNET-41058.
Hello and thanks,
Finally added, but no use as MapiConversionOptions is excluded from this overload
Yes, sure, we’ll add that.
We apologize for the inconvenience.