search

jstedfast / gmime

A C/C++ MIME creation and parser library with support for S/MIME, PGP, and Unix mbox spools.
GNU Lesser General Public License v2.1
113 stars 36 forks source link

Consider returning QP when guessing best encoding for data with long lines #93

Closed mjog closed 4 years ago

mjog commented 4 years ago

Not sure how feasible this is, or if you even want to, but it may be worth having GMimeFilterBest return GMIME_CONTENT_ENCODING_QUOTEDPRINTABLE at a minimum when guessing the best encoding for text content with line lengths that exceed the 822/SMTP maximum line length for the given constraint (i.e. >= 998 for 7 & 8 bit).

While the application can (and arguably should) pre-break text lines for the main, human-entered body of the message, it's probably reasonable to use QP for text parts that are attachments or that are actually application-specific like HTML, and that have lines longer than what SMTP allows.

For context, I just received a bug report for the new version of Geary where an SMTP server was correctly rejecting a message with a text/html part, because despite being short it had no line breaks and hence exceeded the STMP line length. Given this has only just ben reported, I suspect that something changed either with the HTML produced by newer versions of WebKitGTK, or by the port to GMime 3, but IIRC Geary never took any steps to ensure HTML parts had sufficiently short lines.

jstedfast commented 4 years ago

It already does?

mjog commented 4 years ago

Oh, really? Let me check...

mjog commented 4 years ago

Run out of time to check for the moment, will get back to it later today.

mjog commented 4 years ago

Our use of g_mime_filter_best_encoding currently always seems to be returning null at the moment with GMime 3.2.7, will look into seeing if its a vala binding issue, something with our port to 3.x, or something else.

mjog commented 4 years ago

Null issue is: https://github.com/jstedfast/gmime/pull/94

This issue was caused by not flushing the filter's stream after writing to it via a call to g_mime_stream_write_to_stream, so best filter's filter_complete was not getting called, and hence the single long line was not considered when determining the best encoding.

While this bug is clearly mine, it would be helpful if the API docs were a bit less sparse regarding otherwise unstated requirements such as the necessity of calling flush, whether or not closing a stream will flush it, etc.

jstedfast commented 4 years ago

I'm never against better documentation 😄