2 eml things

Aspose.Email Product Family
1

Hello :slight_smile:
I’ve attached a sample eml:

Dim xx As New Email.MailMessage
xx.Save(“d:\a.eml”)
a.zip (170 Bytes)

and email detect file format detects it as mhtml.
since you set:
X-Unsent: 1
by default, is that header supported by mht? or when X-Unsent is found, it can’t be mhtml and should be reported as .eml ?

2nd thing is that most SDKs do not set that X-Unsent by default, so:

xx.Headers.Remove(“X-Unsent”)

is Headers.Remove case sensitive?
and what if we run
xx.Headers.Remove(“X-Unsent”)
and X-Unsent does not exist?

controlling that in the mid-to-large code base is a challenge!

MsgSaveOptions had a SaveAsTemplate property, which later removed because moved to:

MsgSaveOptions(MailMessageSaveType)

now we specify it with

OutlookMessageFormatUnicode / OutlookTemplateFormat

Can you please consider adding a similar property to EmlSaveOptions ?

either

EmlSaveOptions.SaveAsTemplate

or

EmlSaveOptions(MailMessageSaveType)

or

EmlSaveOptions.SaveAsSent

This will be helpful.
Best.

2

Hello,

Thanks for the detailed report.

1) X-Unsent and format detection. X-Unsent: 1 is an Outlook/Windows Mail convention that marks a message as a draft, so double-clicking the .eml opens it in compose mode rather than read mode. It’s an email-side hint and carries no meaning in an MHTML (.mht) web archive.

You’re right that EML and MHT are both RFC 5322 / MIME containers, so DetectFileFormat relies on heuristics (MIME structure, Content-Type, etc.), not the extension. For a freshly created, essentially empty MailMessage, there’s very little to key off, which is likely why it leans toward MHTML here. Using the presence of X-Unsent as a signal that the file is EML rather than MHT is a sensible refinement.

2) Headers.Remove.

  • It is not case sensitive. Header names are case-insensitive, and the collection matches them that way, so Remove("X-Unsent"), Remove("x-unsent"), etc. all match.
  • Removing a header that doesn’t exist is a safe no-op, it won’t throw. So you can call Headers.Remove("X-Unsent") unconditionally, no Contains check needed.

For a mid-to-large codebase, the clean approach is to centralize it in one helper/extension so Remove calls aren’t scattered everywhere:

public static void SaveEmlClean(this MailMessage msg, string path)
{
    msg.Headers.Remove("X-Unsent");
    msg.Save(path, SaveOptions.DefaultEml);
}

3) EmlSaveOptions enhancement. The constructor already takes a MailMessageSaveType (new EmlSaveOptions(MailMessageSaveType.EmlFormat)), but that only selects the output format; it doesn’t cover the draft/sent state that X-Unsent represents, so there’s no first-class switch for it yet. I’d lean away from overloading MailMessageSaveType (mixes format and state) toward a dedicated boolean, e.g., your suggested EmlSaveOptions.SaveAsSent (or SaveAsDraft) that toggles the X-Unsent header, defaulting to current behavior for backward compatibility. Until then, Headers.Remove("X-Unsent") before saving gives you the “sent” output.

3

Hello and thanks for your kind response.

sample.zip (1.2 KB)

Please be kind and check this file against file type detector, it is not eml or mht at all, but is detected as mht
Best.

4

Hello,

Thank you for the detailed examples.

We understand the point you are making. However, format auto-detection is inherently heuristic. When the same input can legitimately satisfy the minimal characteristics of more than one supported format, there is no universally “correct” choice that will work for every scenario.

Our goal is to provide reliable detection for real-world files rather than artificially constructed edge cases. For ambiguous inputs, we recommend explicitly specifying the expected format instead of relying on automatic detection.

Improving detection for one ambiguous case may inevitably reduce detection accuracy for another, so we have to balance the heuristics based on practical, real-world data rather than theoretical edge cases.

If you have an example of a real-world file that is incorrectly detected and where the expected format is unambiguous, we’d be happy to investigate it.

1 Like
5

Thanks, this was a real world sample, it is Microsoft Visual Studio/.NET telemetry / Microsoft Application Insights

see:

and there are many mime files that are not eml or mht:

HTTP Raw Traffic Files (.http, .req, .res):

POST https://example.com
Authorization: Bearer xyz123
Content-Type: application/json

{“username”: “johndoe”}

or sip VoIP Telecom files :smiley:

6

Thank you for the additional context and for clarifying what the sample represents.

We agree that not every MIME-like text document is an email message. There are indeed other formats that may share similar syntax.

The purpose of our format detection is to identify formats supported by Aspose.Email from typical inputs encountered by its users. It is not intended to distinguish email messages from every MIME-based text format that may exist.

We’ll review this case internally and evaluate whether the detection heuristic can be improved without negatively affecting detection accuracy for the formats supported by Aspose.Email.