Hello David,

first of all, many thanks for not giving up on this one!

David Bremner <david@tethera.net> writes:

> [...]
> I think this might be a deeper issue. Looking at the structure of
>
>   test/corpora/protected-headers/smime-sign+enc.eml
>
> it looks like there is an application/pkcs-7 part for the outer
> container with an encstatus, and one inside that (with the same mime
> type) with a sigstatus. So maybe the right thing is to just ignore
> missing encstatus?
> [...]

Conceptually, a typical s/mime message looks like this:
----------------------------------------------------------------------
Received:
From:
To:
Subject:
Date:
MIME-Version: 1.0
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
[more headers (opt.)]
                              <empty line>
gibberish (the CMS)
----------------------------------------------------------------------

After decrypting the gibberish (CMS), you get a new mime tree structure,
in which the top-level entity can be a multipart/signed (most often), or
a message/rfc822 (sometimes), or something else (rarely seen) [1].

[1] https://tools.ietf.org/html/rfc8551

I.e. you decrypt, and further mime parts appear. No assumptions should
be made about the tree's structure. Quoting from [1]:

---------------------------- Begin Quote -----------------------------
3.1.  Preparing the MIME Entity for Signing, Enveloping, or Compressing

   S/MIME is used to secure MIME entities.  A MIME message is composed
   of a MIME header and a MIME body.  A body can consist of a single
   MIME entity or a tree of MIME entities (rooted with a multipart).
   S/MIME can be used to secure either a single MIME entity or a tree of
   MIME entities.  These entities can be in locations other than the
   root.  S/MIME can be applied multiple times to different entities in
   a single message. [...]
----------------------------- End Quote ------------------------------

After decrypting your "outer" container (the CMS), the result is a mime
tree, i.e. should start with "Content-Type:". Standard mime tree
processing should be applied (recursively).

The bodypart handler error message shows this "embedded (inner) mime
tree", and in my case the top-level entity is a multipart/signed. You
wrote "the outer container with an encstatus, and one inside that (with
the same mime type) with a sigstatus". So it seems that at that point
you have access to the root of the "inner tree" (multipart/signed, you
can access the sigstatus), but the content-type information is from the
"outer" container (the CMS) still. Perhaps the recursive mime re-parsing
after the decryption is not happening?


More new questions than answers...

  --alexander
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org