The "Return-Path" Header field is beeing ommitted

NEW
Unassigned

Status

10 years ago
a year ago

People

(Reporter: torge.kummerow, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Build Identifier: 2.0.0.19 - 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:  
"some@email.com"

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.

Updated

10 years ago
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

Comment 2

10 years ago
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.
Assignee: dmose → nobody
Assignee: nobody → dmose

Comment 3

3 years ago
bug still relevant?
Assignee: dmose → nobody
Target Milestone: Thunderbird 3.0rc1 → ---

Comment 4

2 years ago
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.