GNOME Bugzilla – Bug 668158
base64 encode and line termination
Last modified: 2012-01-18 14:05:02 UTC
Long lines are braked and terminated with a single <LF> character in g_base64_encode_step/g_base64_encode_close functions. This causes problems when trying send emails through or to SMTP servers that enforce fairly strict email related RFC standards (http://www.networksorcery.com/enp/rfc/rfc2821.txt) in their email checks. The response from smtp.mail.yahoo.com in that case is: 451 Invalid Smtp line - Should end with CRLF
Hmm... "braked" (sorry ;-))
Hi Patricia, what is a testcase to reproduce this? (Or: Which email application uses g_base64_encode_step/g_base64_encode_close?) Which glib version is this about?
I'll try to provide a simple test application that exhibits this behavior.
(In reply to comment #2) > what is a testcase to reproduce this? It would show up with any app that used g_base64_encode* and then tried to pass the result directly to an SMTP server; evolution doesn't run into problems because it passes message bodies through a LF->CRLF filter after the base64 filter when sending through SMTP... However, we can't change this behavior now, because g_base64_encode_step() relies on the caller allocating a sufficiently-large buffer, and so if we started using CRLF instead of LF, existing callers wouldn't be allocating enough space and so would buffer-overrun themselves. The gbase64 APIs are generally pretty ugly and un-glib-like. We should replace them at some point. Anyway, I committed a clarification to g_base64_encode_step()s docs.