User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:22.214.171.124) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) Build Identifier: 126.96.36.199 - 3.0b2 The Return-Path field is beeing handled as a special Header field and saved in m_Return_Path. http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsParseMailbox.cpp#1001 But this variable is a dead end. Because of the special treatment it is also not accessible through the mailnews.customDBHeader option. Thus rendering it invisible for Add-Ons. but never given to any variable. So it is not accessible throu Reproducible: Always Steps to Reproduce: 1. set the variable mailnews.customDBHeader to return-path 2. get a nsIMsgDBHdr instance of an E-Mail with that header 3. call getStringProperty("return-path") Actual Results: "" Expected Results: "firstname.lastname@example.org" Quickest solution would be IMHO to drop the line where "Return-Path" is handled. http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsParseMailbox.cpp#1000 That way the fallback (customDBHeader) will catch it and it will be accessible again.
Component: General → Backend
Product: Thunderbird → MailNews Core
QA Contact: general → backend
Confirming, as I looked over the code with Torge and agree that it's pretty clear what the problem is. I think this should block Tb3, because the minimal fix (as proposed by Torge) is trivial, and is something that extension authors might want. It would be interesting to do a bit of version control/bugzilla archeology to understand why this header is getting special-cased in the first place in case for some reason it would make sense to actually stuff it into the nsIMsgDBHdr...
Assignee: nobody → dmose
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Thunderbird 3.0rc1
I bet you'd have to go pretty far back - I never remember sticking m_returnPath in the db. And I agree with Torge's diagnosis and solution.
bug still relevant?
Assignee: dmose → nobody
Target Milestone: Thunderbird 3.0rc1 → ---
Was just going to open a new bug but found this one. I'm using thunderbird 47.0 and can confirm this bug is still valid.
You need to log in before you can comment on or make changes to this bug.