v1.13.0

Outlook Message Parser 1.13.0 aligns activation support with the Jakarta/Angus dependency split.

v1.12.0

Outlook Message Parser 1.12.0 ignores malformed recipient records that have a name but no address.

v1.11.1

Missing attachment data

• Keep ordinary empty attachments available to callers.
• Exclude attachments whose binary data is missing from the embedded-image CID map, preventing downstream failures without regressing normal attachment handling.

See #69.

Compatibility: this corrects the overly broad behavior in 1.11.0 without changing the public API; use 1.11.1 or newer on this release line.

v1.11.0

Outlook Message Parser 1.11.0 attempted to tolerate attachments whose MSG storage contains no data.

Empty attachment records were ignored during parsing. This behavior was immediately refined in 1.11.1: ordinary empty attachments are retained, while invalid empty embedded-image candidates are excluded. Consumers should use 1.11.1 or later.

v1.10.2

Broader X.500 recipient recognition

• Recognize general X.500 Directory Access Protocol recipient addresses instead of depending on a narrow set of real-world prefixes.
• Retain the existing SMTP-address paths while improving fallback coverage.

See #101.

Compatibility: this is an additive parsing improvement with no public API change.

v1.10.1

Outlook Message Parser 1.10.1 corrects the X.500 recipient parsing introduced in 1.10.0.

v1.10.0

Outlook Message Parser 1.10.0 introduced initial parsing support for unresolved Exchange X.500 recipient names through #67.

v1.9.6

#57 Headers should be more accessible, rather than just a big string of text, but this time with collections as values so we keep headers that occur multiple times with different values.

v1.9.5

#57 Headers should be more accessible, rather than just a big string of text

v1.9.4

Outlook Message Parser 1.9.4 removes a downstream Maven convergence conflict.

The redundant commons-codec transitive dependency from poi-scratchpad is excluded because Apache POI already supplies the required codec integration (#100). Parser behavior and public APIs are unchanged.