vb-roar
/
pEpMIME
forked from pEp.foundation/pEpMIME
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

add design criteria of pEpMIME to README.md :-)

APPLEMAIL-59
roker 2021-07-08 19:09:48 +02:00
parent c67b8c1105
commit 85bc2b34ca
1 changed files with 45 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
README.md
View File

@ -25,3 +25,48 @@ 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
# Design criteria of pEpMIME
## Normalization
pEpMIME "normalizes" the MIME messages during parsing, and uses some heuristics especially for
non-MIME-compliant inputs. The generated `struct message` always
* contains UTF-8 NFC-compliant text in `longmsg` and `longmsg_formatted`
* contains appropriate MIME headers, e.g. `Mime-Type` and `charset`
* …
The MIME generator also serializes data in a special and predictive manner:
* Non-7bit data in MIME leaves' headers and bodies are always base64 encoded. "quoted printable"
encoding is never generated.
* MIME delimiter are short and predictive "=pEp=#=", where `#` 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:
1) "MIME_text" --> `struct message` --> "MIME_text2"
"MIME text" and "MIME_text2" usually differ due to normalization
2) `struct message msg1` --> "MIME_text" --> `struct message msg2`
The content of `msg1` and `msg2` is identical, except …
(*FIXME*: AFAIK there are special bizarre cases, but I don't remember at the moment)
## Special Headers
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:format` and `: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_possible_pEp_msg` / `has_pEp_msg_attachment`.
This field is used only internally and does not occur in the returned `struct message`.