275470 - S/MIME signed message with added dspam section does not display.

Status: RESOLVED WONTFIX

(MailNews Core :: MIME, defect)

Description

[Eliot Blennerhassett]

A message with an extra multipart section added by spam filter appears blank (no
content, no 'pen' signature indicator.

If I manually remove the extra section, the message displays fine, and the
signature is verified.

The body of the email look like this:

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

The text.
--------------ms030007010205060305050000
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpDCC
<etc etc>
KXA2Lplt9P9hRtHC6BjEVbDTpjt5MXqOdwAAAAAAAA==
--------------ms030007010205060305050000
Content-Type: text/plain; name="dspam.txt"
Content-Disposition: attachment
Content-Transfer-Encoding: 7bit

!DSPAM:41c784f8966591314721177!
--------------ms030007010205060305050000--

If remove the dspam.txt "attachment", the message decodes fine.

At the least, the message body should be displayed, perhaps the signature will
not verify because of the modification.

Comment 1

[Eliot Blennerhassett]

another thing with this message - automatic "mark as read" does not happen even
though the message is selected for some time.

Comment 2

[Eliot Blennerhassett]

Thunderbird version 1.0 (20041206)

Comment 3

[Mike Cowperthwaite]

What mail client is creating the message?

What is the top-level Content-Type of the message?

Where is that 'dspam.txt' attachment coming from -- the sender?  Or could it be 
some sort of automated signature thingy being added by the client, an SMTP 
server or proxy, or the receiver's ISP?

Comment 4

[Eliot Blennerhassett]

Attachment: The mail 'folder' containing the one offending message

Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary="------------ms030007010205060305050000"

Comment 5

[Eliot Blennerhassett]

dspam.txt is coming from spam filter at receivers ISP.
http://www.nuclearelephant.com/projects/dspam/

Comment 6

[Mike Cowperthwaite]

Hm.  According to RFC1847, "The multipart/signed content type contains exactly 
two body parts."  The receiver's DSPAM scanner apparently is too dumb to realize 
that not all multipart/xxxx content-types are the same.  If they're going to add 
a part, it should be done more intelligently, along the lines of:
 Top: multipart/mixed
   Part 1: multipart/signed
     Part 1.1:  body
     Part 1.2:  signature
   Part 2: spam notice

I'll confirm this bug, but I'm not sure what TB can or should do about it; in 
the meantime you should complain to the DSPAM people.

Comment 7

[Jonathan Zdziarski]

This is a known bug and on the slate to be fixed... but I didn't realize TB had
such problems with it or it'd have been fixed sooner. 

Any reason TB can't just ignore the offending part? I know, it's DSPAM's
responsibility to stick to RFC...I just figured MTAs would handle this more
gracefully. I'll make this a higher priority.

As a temporary workaround, Thunderbird users can switch to putting the DSPAM
signature in the message headers, and forward as attachment from T. This should
work in 3.2.3 and above.

Comment 8

[Jonathan Zdziarski]

This has been fixed in cvs-devel of dspam, however I'd recommend also fixing it
in TB, as many other tools (including spammer tools) don't always follow RFC.

Comment 9

[Mike Cowperthwaite]

*** Bug 186076 has been marked as a duplicate of this bug. ***

Comment 10

[Mike Cowperthwaite]

*** Bug 281546 has been marked as a duplicate of this bug. ***

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to Jonathan Zdziarski from comment #8)
> This has been fixed in cvs-devel of dspam, however I'd recommend also fixing
> it
> in TB, as many other tools (including spammer tools) don't always follow RFC.

Joshua, do you know of data anywhere that would suggest this is, or is not, a problem worthy of fixing?

Comment 12

[Joshua Cranmer [:jcranmer]]

(In reply to Wayne Mery (:wsmwk) from comment #11)
> (In reply to Jonathan Zdziarski from comment #8)
> > This has been fixed in cvs-devel of dspam, however I'd recommend also fixing
> > it
> > in TB, as many other tools (including spammer tools) don't always follow RFC.
> 
> Joshua, do you know of data anywhere that would suggest this is, or is not,
> a problem worthy of fixing?

I am less cognizant of S/MIME issues than other MIME issues, but this bug gives indications that it is not worth fixing in TB.

Comment 13

[Lukas Tribus]

I understand your point and I agree that this is an RFC violation.

But I think TB's behavior could be more forgiving, so that the user doesn't have to read the source code of the email, or export it to read the email in a different MUA.

Yes, this still happens, it happens in certain cases with PGP + S/MIME, it happens on proprietary mailing list. Yes - they are all broken and violating the RFC, but not being able to read the actual mail is a very serious problem.


At the very least Thunderbird could advise the user of the MIME brokenness, instead of displaying a blank page.