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.