Try to fix weird sender names: High level patch idea #212

New Issue

MrUnknownDE · 2026-04-05T16:17:05+02:00

MrUnknownDE commented

2026-04-05 16:17:05 +02:00

Originally created by @benhoff on 9/21/2025

Hey, I haven’t tested this locally since I don’t have a dev environment set up, but I wanted to put this up because I was hitting a problem importing PSTs.

When I try to import from a PST, the sender names look like this:

From: /O=EXCHANGELABS/OU=EXCHANGE ADMINISTRATIVE GROUP (************)/CN=RECIPIENTS/CN=********-********

That string is the Exchange LegacyDN (an internal X.500 identifier), not an SMTP address. It happens because when senderAddrtype === "EX", the MAPI properties PR_SENDER_EMAIL_ADDRESS or PR_EMAIL_ADDRESS only return the LegacyDN, not the real SMTP.

What this patch changes

From header:

Prefer SMTP if addrType === "SMTP" and the address looks like an email.
Otherwise, try to extract a From: line from PR_TRANSPORT_MESSAGE_HEADERS.
As a last resort, fall back to just the display name (but no ).
Sanitize names and RFC-2047 encode if non-ASCII.

Recipients (To/Cc/Bcc):

Build these from the recipient table rather than the displayTo/displayCc strings.
Use smtpAddress (or emailAddress when addrType === "SMTP").
Skip recipients without SMTP addresses so we don’t end up with names-only.

Why

This should avoid weird LegacyDNs showing up in headers and instead generate proper RFC-2822 headers like:

From: Ben <ben@company.com>
To: Jane Doe <jane.doe@company.com>

instead of leaking raw X.500 strings.

It needs to be thoroughly tested though.

If this is something that you would be open to testing, I would be grateful. As I'm not familiar with the buildstack, it would be difficult for me to get up and running.

*Originally created by @benhoff on 9/21/2025* Hey, I haven’t tested this locally since I don’t have a dev environment set up, but I wanted to put this up because I was hitting a problem importing PSTs. When I try to import from a PST, the sender names look like this: `From: /O=EXCHANGELABS/OU=EXCHANGE ADMINISTRATIVE GROUP (************)/CN=RECIPIENTS/CN=********-********` That string is the Exchange LegacyDN (an internal X.500 identifier), not an SMTP address. It happens because when senderAddrtype === "EX", the MAPI properties PR_SENDER_EMAIL_ADDRESS or PR_EMAIL_ADDRESS only return the LegacyDN, not the real SMTP. ### What this patch changes From header: - Prefer SMTP if addrType === "SMTP" and the address looks like an email. - Otherwise, try to extract a From: line from PR_TRANSPORT_MESSAGE_HEADERS. - As a last resort, fall back to just the display name (but no <LegacyDN>). - Sanitize names and RFC-2047 encode if non-ASCII. Recipients (To/Cc/Bcc): - Build these from the recipient table rather than the displayTo/displayCc strings. - Use smtpAddress (or emailAddress when addrType === "SMTP"). - Skip recipients without SMTP addresses so we don’t end up with names-only. ### Why This should avoid weird LegacyDNs showing up in headers and instead generate proper RFC-2822 headers like: ``` From: Ben <ben@company.com> To: Jane Doe <jane.doe@company.com> ``` instead of leaking raw X.500 strings. It needs to be thoroughly tested though. If this is something that you would be open to testing, I would be grateful. As I'm not familiar with the buildstack, it would be difficult for me to get up and running.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/OpenArchiver#212