Closed Bug 162842 Opened 22 years ago Closed 22 years ago

Return receipt was requested from original sender of a mesg that has been fowarded(as attach)

Categories

(SeaMonkey :: MailNews: Backend, defect)

Product:
SeaMonkey
Component:
MailNews: Backend
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: neil, Assigned: bugzilla)

References

Details

Attachments

(2 files)

Proposed fix, v1
765 bytes, patch
sspitzer
: review+
Bienvenu
: superreview+
chofmann
: approval+
Details | Diff | Splinter Review
Additional test cases I tested
984 bytes, text/plain
Details
Using Build ID: 2002081308 Steps to reproduce problem: 1. Someone sends a message requesting a return receipt. 2. The recipient then forwards the message to a third party. Actual results: The third party is then asked to send a return receipt. Expected results: The third party is not asked to send a receipt. Of course, the original recipient was prompted to send a receipt.
dupe of bug 139617 *** This bug has been marked as a duplicate of 139617 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Eh? Bug 139617 is the wrong way around, I was receiving the forwarded message, not sending it, and I shouldn't have been prompted to send a receipt.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
updating this bug. thanks to m.knous for helping me reproduce this bug. She should take credit for finding a reproducable test case. Updating summary by adding 'as attach'. If you forw a mesg (that has a return receipt request on it) as an attachment, the recepients of the mesg will be prompted for a return receipt (because the original mesg had it). This would not be a bug if bug 139617 (have return receipt request on any mesg you forw or edit as new) is fixed. Below is msg source of a forw mesg that will request a ret recpt: Return-Path: <knous@netscape.com> Received: from netscape.com ([10.169.111.222]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H54ALO03.0OS; Tue, 5 Nov 2002 11:10:36 -0800 Message-ID: <3DC817AC.901@netscape.com> Date: Tue, 05 Nov 2002 11:10:36 -0800 From: knous@netscape.com (Marcia Knous) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcia Knous <knous@netscape.com>, Gary Chan <gchan@netscape.com> Subject: [Fwd: T] Content-Type: multipart/mixed; boundary="------------090602070409080904000301" This is a multi-part message in MIME format. --------------090602070409080904000301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------090602070409080904000301 Content-Type: message/rfc822; name="T" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="T" Return-Path: <knous@netscape.com> Received: from netscape.com ([10.169.111.222]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H54AKM01.VNE for <knous@netscape.com>; Tue, 5 Nov 2002 11:09:58 -0800 Message-ID: <3DC81786.6040101@netscape.com> Disposition-Notification-To: Marcia Knous <knous@netscape.com> Date: Tue, 05 Nov 2002 11:09:58 -0800 From: knous@netscape.com (Marcia Knous) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcia Knous <knous@netscape.com> Subject: T Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> <br> </body> </html> --------------090602070409080904000301-- Forw as inline doesn't reproduce this problem. Steps 1.edit|prefs|composition|forw mesgs as attchment 2.edit|prefs|Send format| ask me what to do 3.make sure you compose in html format 4.Compose a mesg to yourself 5.Go to menu item: options|return receipt and set it for this mesg 6.Send the mesg to yourself 7.Get the mesg 8.should be promted for a return receipt 9.Can decline or send the ret rcept request 10.Take that mesg and forw it 11.address it to yourself 12.verify menu item: options|return receipt is NOT SET 13.Send the mesg 14.Get the mesg 15.read the mesg result: you will be prompted for a Return Receipt request expected: to not be This bug is still present in the trunk: 2002-11-05-08-trunk/ and branch: 20021031
OS: Windows 95 → All
Summary: Return receipt was requested for fowarded message → Return receipt was requested for fowarded message(as attach)
I also experienced this bug yesterday. I received a forwarded message and was prompted for a return receipt request that I believe to be from the original sender. This could be a serious privacy issue if the receipt is for the original sender and not the forwarder. Mitchell, if you're reading bugmail can you comment here with mail client and version you used to forward that email to me and marcia yesterday? Thanks.
You're right Asa. The original sender of the mesg will get the return receipt request not the forwarder. So it behaves like the original sender sent it to any forward recepients.
reassigning and nominating. Privacy issue. As Asa pointed out, the original sender of the mesg would get the ret recpt back, not the forwarder
Assignee: jt95070 → bienvenu
Status: REOPENED → NEW
Keywords: adt1.0.2
Jean-Francois, when you call SetMimeHeaders on this message (the one that contains the forwarded message), we should only get the initial set of headers, right, not including the ones in the forward message? My guess is that SetMimeHeaders is giving us all the headers - I can verify that, but am I correct in saying that it should not?
right, it should not return headers for embedded messages
ExtractHeader is giving me a header in the forwarded message, so I'm going to reassign to you for now, JF.
Assignee: bienvenu → ducarroz
adt--and drivers for that matter--needs a reviewed patch (to judge risk, QA impact, etc) before we will approve it
Keywords: mozilla1.0.2
SetMimeHeaders is getting called twice - I wonder if the second one is for the forwarded message.
Accepting and looking into it...
Status: NEW → ASSIGNED
Blackbird is interested in this fix, but if we were to take it, we would need it pronto. We are driving toward a candidate build tomorrow, 11/6. Please update this bug as soon as you know what it might take to fix. Adding myself to the cc list.
I have a fix, I testing it now...
Whiteboard: Testing a fix
The fix works great
Whiteboard: Testing a fix → Have fix, seeking reviews
Attached patch Proposed fix, v1 — — Splinter Review
When we parse a message, we emitt the main message headers as well the headers of embedded messages. We must call nsIMsgMailNewsUrl::SetMimeHeaders only for the main headers.
Comment on attachment 105267 [details] [diff] [review] Proposed fix, v1 sr=bienvenu, great, thx.
Attachment #105267 - Flags: superreview+
I checked in the fix in the trunk.
Whiteboard: Have fix, seeking reviews → Have fix, seeking approval
Comment on attachment 105267 [details] [diff] [review] Proposed fix, v1 a=chofmann for 1.0.2
Attachment #105267 - Flags: approval+
Keywords: mozilla1.0.2 → mozilla1.0.2+
Fix checked in the 1.0 branch too.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Whiteboard: Have fix, seeking approval
Marking adt1.0.2+ and fixed1.0.2 since fix is in the branch. Gary, please verify and change fixed1.0.2 to verified1.0.2 on verification.
Keywords: adt1.0.2 → adt1.0.2+, fixed1.0.2
Jean-Francois , can you please land this in the 1.2 branch as well? Thanks.
Blocks: 1.2
FIxed in 1.2 branch too. Do we have keyword for that?
Trunk 2002-11-06-04-trunk xp 2002-11-06-04-trunk/linux 2.2 2002-11-06-03-trunk/ mac 10.1.5, mac 9.2.2 branch: 2002-11-06-07-1.0/ linux 2.2 2002-11-06-05-1.0/ mac 10.1.5,mac 9.2.2 2002-11-06-08-1.0 xp Verified that if you forward a mesg (that has a ret recpt) as an attachment to someone. The recepient of the mesg will not be prompted for a Return Recpt nor will a Return Receipt be sent back to the author of the original mesg that is being forwarded Tested following scenarios using 3 different email accnts Acnt A send a mesg w/rr to Acnt B Acnt B then Forwards it to Acnt C Acnt C then Reads it Tested forwarding using: -Default pref Edit|Pref|Composition|forward mesgs as attach -Message|forward as Attach -Default pref Edit|Pref|Composition|forward mesgs as inline -Message|forward as inline Tested sending to imap and pop accounts. marking verified. changing keyword:fixed1.0.2 to verified1.02
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.2 → verified1.0.2
Summary: Return receipt was requested for fowarded message(as attach) → Return receipt was requested from original sender of a mesg that has been fowarded(as attach)
Just tested some additonal stuff to make sure things are ok.
Product: Browser → Seamonkey
Component: MailNews: Return Receipts → MailNews: Backend
QA Contact: grylchan → offline
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: