293981 - RFC2634 suggests user undeactivateable S/MIME return receipts if requested

Status: RESOLVED DUPLICATE of bug 386313

(MailNews Core :: Security: S/MIME, enhancement)

Description

[tom schorpp]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2

Yes, I've searched the bugbase.

Yes, I'm sure its not a duplicate.


S/MIME implementations MUST be able to generate return signed receipt messages.
s/mime return receipts are not implemented in mozilla suite, why?

S/MIME receipts are digitally signed, as is the request. The S/MIME
specification requires compliant clients to honor receipt requests, without
including an option to suppress receipts like for ordinary messages.

theres no other interpretation of RFC2634.

so it should be impl'd soon...

Reproducible: Always

Steps to Reproduce:
1. send signed mail with return receipt request. you get it from conformant clients.
2. receive signed mail with return receipt req with mozilla. it deliveres the
receipt UNSIGNED.
3.

Actual Results:  
you get it from conformant MUA clients.
mozilla. it deliveres the receipt UNSIGNED.

Expected Results:  
1. sign the return receipt.
2. do not allow supression by user if S/MIME request.

--------------mdn070205010204010305060003
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This is a Return Receipt for the mail that you sent to [e-mail].

Note: This Return Receipt only acknowledges that the message was displayed on
the recipient's computer. There is no guarantee that the recipient has read or
understood the message contents.

--------------mdn070205010204010305060003
Content-Type: message/disposition-notification; name="MDNPart2.txt"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Reporting-UA: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050420
Debian/1.7.7-2
Final-Recipient: rfc822; [e-mail]
Original-Message-ID: <[e-mail]>
Disposition: manual-action/MDN-sent-manually; displayed

--------------mdn070205010204010305060003
Content-Type: text/rfc822-headers; name="MDNPart3.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

X-UIDL: a45ce4c04bf044211da16bcc710b1ba2.1115961193.1
X-UIDL: a45ce4c04bf044211da16bcc710b1ba2.1115961193.1
Return-path: <[e-mail]>
Envelope-to: [e-mail]
Delivery-date: Fri, 13 May 2005 05:13:08 +0000
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by tom3.schorpp.dyndns.dk with smtp (Exim 4.50)
	id 1DWSTp-00041K-PD
	for [e-mail]; Fri, 13 May 2005 05:13:08 +0000
Received: (qmail invoked by alias); 13 May 2005 05:12:25 -0000
Received: from p83.129.182.144.tisdip.tiscali.de (EHLO [192.168.2.100])
[83.129.182.144]
  by mail.gmx.net (mp002) with SMTP; 13 May 2005 07:12:25 +0200
X-Authenticated: #17142692
Message-ID: <[e-mail]>
Disposition-Notification-To: thomas schorpp <[e-mail]>
Date: Fri, 13 May 2005 07:12:14 +0200
From: thomas schorpp <[e-mail]>
Reply-To:  [e-mail]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050420
Debian/1.7.7-2
X-Accept-Language: en
MIME-Version: 1.0
To: thomas schorpp <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary="------------ms090103050504040202060101"
X-Y-GMX-Trusted: 0
X-SA-Exim-Connect-IP: 213.165.64.20
X-SA-Exim-Rcpt-To: [e-mail]
X-SA-Exim-Mail-From: [e-mail]
Subject: [Fwd: Hays]
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on 
	tom3.schorpp.dyndns.dk
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=3.0 tests=AWL,BAYES_00,HTML_50_60,
	HTML_MESSAGE,HTML_TEXT_AFTER_BODY,HTML_TEXT_AFTER_HTML,
	MIME_HTML_MOSTLY autolearn=no version=3.0.2
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on tom3.schorpp.dyndns.dk)

--------------mdn070205010204010305060003--

Comment 1

[tom schorpp]

no.

some diverting opinions around.

the rfc has set this to optional.

changed to enhancement.

y
tom schorpp

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[tom schorpp]

Suggest to leave open.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Considering the reaction and response that bug 295922 got, I am VERY confident
that, if we add the signed return receipt feature to mozilla mail/news, we 
will absolutely make it something that the user can override and disable.

Any other choice would make sending a signed message to someone an invasion
of privacy, a way to probe for live mailboxes, whether the user of that mail
box wanted to reveal his existence or not.  

This RFE is a duplicate of bug 386313.