Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The P7M file type is primarily associated with a <a href="http://en.wikipedia.org/wiki/S/MIME" rel="nofollow"><code>PKCS #7 MIME Message</code></a>. See <a href="http://tools.ietf.org/html/rfc2311#section-3.2" rel="nofollow">Section 3.2 in RFC 2311</a>:</p> <blockquote> <pre><code>3.2 The application/pkcs7-mime Type The application/pkcs7-mime type is used to carry PKCS #7 objects of several types including envelopedData and signedData. The details of constructing these entities is described in subsequent sections. This section describes the general characteristics of the application/pkcs7-mime type. This MIME type always carries a single PKCS #7 object. The PKCS #7 object must always be BER encoding of the ASN.1 syntax describing the object. The contentInfo field of the carried PKCS #7 object always contains a MIME entity that is prepared as described in section 3.1. The contentInfo field must never be empty. Since PKCS #7 objects are binary data, in most cases base-64 transfer encoding is appropriate, in particular when used with SMTP transport. The transfer encoding used depends on the transport through which the object is to be sent, and is not a characteristic of the MIME type. Note that this discussion refers to the transfer encoding of the PKCS \#7 object or "outside" MIME entity. It is completely distinct from, and unrelated to, the transfer encoding of the MIME entity secured by the PKCS #7 object, the "inside" object, which is described in section 3.1. Because there are several types of application/pkcs7-mime objects, a sending agent SHOULD do as much as possible to help a receiving agent know about the contents of the object without forcing the receiving agent to decode the ASN.1 for the object. The MIME headers of all application/pkcs7-mime objects SHOULD include the optional "smime- type" parameter, as described in the following sections. </code></pre> </blockquote> <p>This is basically a secure E-mail file sent in encrypted form. If everything is set up properly you should have a public key necessary to decrypt the file. If not, download it.</p> <p>In your case the transfer encoding is Base64. Decode the attachment first (if you don't have done this so far) and then process the binary data.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload