Closed Inkrementator closed 7 months ago
basically just line wraps right? what part of the rfc talks about this? been a while since i read it
https://www.ietf.org/rfc/rfc2045.txt
The commit message for 315a886 already cites the relevant rfc section.
Section 6.8 is about base64. On page 24, it says:
The encoded output stream must be represented in lines of no more than 76 characters each.
oh lol i don't read commit messages unless i figured the code was already buggy
but that's ok this looks ok to me then the standard does say "must"
Content-transfer-encoding: 8bit
isn't perfect, but seems to work ok on many clients/ servers. GMail will just convert it to quoted-printable for you.
Section 5.2:
- Content-Transfer-Encoding Header Field
Many media types which could be usefully transported via email are represented, in their "natural" format, as 8bit character or binary data. Such data cannot be transmitted over some transfer protocols. For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII data with lines no longer than 1000 characters including any trailing CRLF line separator.
Yeah. At least it shouldn't be any worse than it is now. Some of my day job use this lib for attachments but i can't imagine this breaking anyhting.
Some small patches for better RFC 2045 conformance. The behaviour introduced is equivalent to what thunderbird would produce, thus should not break anything (unless thunderbird has some special handling for weird public mailservers, in which case all of this hopeless anyways)