This is maybe a foul compromise between correctness and complexity of
implementation, but it should do the right thing in most cases, and
does not require fully parsing and reconstructing all headers that can
contain phrases.
An 'encoded-word' MUST NOT appear within a 'quoted-string'. We thus
completely encode the quoted-string (if necessary) as a single
encoded-word, and strip off the quotes.
This should fix encoding of addresses that have both non-ASCII and
special chars such as , and ;.
Characters such as , or ; mustn't appear in qp-encoded strings,
as they have a meaning in phrases. To be safe, encode all special
characters except for the safe ones in RFC 2047 5.(3).
_ is dealt with already.
Do not add additional Content-Type and Content-Transfer-Encoding headers
when using mmime on input already containing them.
Do not reencode the message if Content-Transfer-Encoding is set.
Based on a patch by Felix Van der Jeugt and duncaen.
All programs except mshow have a very tight set of promises. mshow
has a broad set of promises and might be a good future candidate
to further restrict using unveil(2).
This patch is based on commit 0300a112 by Alex Holst (dated
2017-12-07), which was proposed in GH PR #79.
* pledged mpick, mflow and mdate so that now all programs are pledged
* removed some unneeded promises and added some missing promises
* move err.h include and OpenBSD ifdef into a new xpledge.h
* cleaned up code aligning and whitespace
Closes: #179 [via git-merge-pr]
RFC2046 5.1.1 specifies that parts without trailing newlines are coded
without problems:
> NOTE: The CRLF preceding the boundary delimiter line is conceptually
> attached to the boundary so that it is possible to have a part that
> does not end with a CRLF (line break).
This if-statement now also codes empty files correctly.
See RFC2045 6.7.(3):
> It follows that an octet with decimal value 9 or 32 appearing at the
> end of an encoded line must be represented according to Rule #1.
Prefer this over generating a soft-line break and then a real line break.
RFC 2046, Section 5.2.1:
> No encoding other than "7bit", "8bit", or "binary" is permitted for
> the body of a "message/rfc822" entity.
(We'll generate 8bit when we have to and put the blame on the MTA.)
RFC2047, 5.(3):
> Each 'encoded-word' MUST represent an integral number of characters.
> A multi-octet character may not be split across adjacent 'encoded-
> word's.
Lines SHOULD not be longer than 78 chars, and we try to fold like that,
but we only enforce qp-encoding for 7-bit safe lines if they would be
longer than 998, which they MUST not be.
Simplifies the code considerably. QP-header-wrapping now happens inside
gen_qp. We wrap the line in advance when this will save QP-encoding, or
splitting a QP-word into two.
Fixes#20.