Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
2011-05-25 16:14:17
John R. Levine wrote:
It tells me signing and encryption certificates are valid and even their
root certificates are valid...
Well, something's wrong with it. I checked the signature in Alpine,
Thunderbird, and Evolution, and they all agree it's fine.
I went back and looked in more detail. The problem appears to be that
this mailing list wraps the signed body in a MIME multipart/mixed
section including both the signed message and the unsigned footer. Some
MUAs look inside the mixed and see the signature, some don't. For the
ones that do, I haven't checked to see how if at all they distinguish
the signed part from the unsigned when they show you the message (shades
of all the l= arguments.)
So this tells me that existing mail software doesn't try very hard to
recover signatures from modified messages, even for simple changes that
don't need any guessing or heuristics to undo. Why would anyone think
that the situation with DKIM would be any different?
I think you were telling people for a while now to use it for some reason.
Anyway, I don't think the problem is as you state.
From what I see, I think the issue here is no MIME Application Type
association for the application and extension your message was made.
Your email provides this MIME info:
Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: BASE64
Content-Description: S/MIME Cryptographic Signature
Content-Disposition: attachment; filename=smime.p7s
Software that offer auto launching (generally with user permission
necessary) using MIME Application association, can either have its own
table or depends on the OS to provide it.
For example, under Windows, you can use a console window using the
ASSOC command to get the file type for the extension:
ASSOC .p7s
and it returns
.p7s=P7SFile
then you use the FTYPE command to see what application is responsible
to handle this file type.
FTYPE P7SFile
and it returns:
p7sfile=rundll32.exe cryptext.dll,CryptExtOpenPKCS7 %1
So if the email has an attachment file name/extension smime.p7s, then
it should allow the user (with permission) to load it by running the
above rundll32.exe process passing the rest of the line as parameters
and substituting %1 with the local temp storage FQFN for smime.p7s
Now, under TBIRD, it apparently is independent of the built-in Windows
MIME association table in the registry. So one would think that
Outlook would not have a problem and indeed it doesn't; it displays a
"seal icon" save button for the SMIME.P7S attachment file when viewing
the message under OE.
Under TBIRD, you can click
TOOLS | OPTIONS
and under the Attachments properties tab, you will see the View & Edit
Associations button. For me, it is empty list - no MIME associations
so shown as a file name "PART 1.2"
Now why didn't it atleast show SMIME.P7S as a file attachment? You
did have:
Content-Disposition: attachment; filename=smime.p7s
You should check bugzilla or asks the TBIRD folks why it doesn't at
least show the actual file name as the attachment because even if
TBIRD doesn't have its own table, when the user tries to save it,
Windows will most likely make the shell association.
BTW, under OE, while it does show the SMIME.P7S icon attachment, the
message display is blank. That may be related to what you are talking
about. In any case, its all fubar.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [ietf-dkim] DKIM Scouts, was 8bit downgrades, (continued)
- [ietf-dkim] DKIM Scouts, was 8bit downgrades, Hector Santos
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, Franck Martin
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, John R. Levine
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, Franck Martin
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, Hector Santos
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, John R. Levine
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, Franck Martin
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, John R. Levine
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, Hector Santos
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, John R. Levine
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades,
Hector Santos <=
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, Ian Eiloart
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, Hector Santos
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, Ian Eiloart
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, Hector Santos
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, John R. Levine
- Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades, Hector Santos
- [ietf-dkim] MLMs and signatures again, Murray S. Kucherawy
- Re: [ietf-dkim] MLMs and signatures again, Steve Atkins
- Re: [ietf-dkim] MLMs and signatures again, Murray S. Kucherawy
- Re: [ietf-dkim] MLMs and signatures again, John R. Levine
|
|
|