To build p≡p MIME it's necessary that header files of p≡p engine are already installed. Because of the dependency loop of p≡p MIME needing these headers and p≡p engine depending on p≡p MIME you best do things in this sequence:
The build of p≡p MIME can be customized. Makefile variable PREFIX is the install directory. The environment variables CXXFLAGS and LDFLAGS are being used. So a typical build on macOS i.e. looks like this:
CXXFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib make PREFIX=$HOME -j4 all install
pEpMIME "normalizes" the MIME messages during parsing, and uses some heuristics especially for
non-MIME-compliant inputs. The generated
struct message always
The MIME generator also serializes data in a special and predictive manner:
#is the smallest possible hexadecimal number so the delimiter does not occur in the message.
Due to this normalization there is no round-trip guarantee that a generated MIME message is identical to the original MIME message:
struct message --> "MIME_text2"
"MIME text" and "MIME_text2" usually differ due to normalization
struct message msg1 --> "MIME_text" -->
struct message msg2
The content of
msg2 is identical, except …
(FIXME: AFAIK there are special bizarre cases, but I don't remember at the moment)
Additionally pEpMIME adds some internal annotations into
message->opt_fields using keys that start
with ":pEp:MIME:", a string that can never occur in MIME messages, so they cannot be set by external
attackers. The MIME generator of pEpMIME is aware of these special header lines, acts appropriately
and skips any element in
message->opt_fields that start with ":", so they will never occur as
MIME header in the generated MIME message.
Adapters and clients are allowed to use these special header fields and might also define their own (with another prefix, so they won't interfere with future pEpMIME headers).
Currently these special headers are used by pEpMIME:
:pEp:MIME:longmsg:delsp: to store the special annotations for plaintext bodies, according to RFC 3676 https://datatracker.ietf.org/doc/html/rfc3676.
:pEp:MIME:attachment1:forwarded: represents the flag
has_pEp_msg_attachment. This field is used only internally and does not occur in the returned