I've now done some more detailed testing of this problem, and I think it
might be a bug in the mime_parse_line function. I really don't know enough
about base64 encoding to be certain though.
I created a debug version of Exim and ran it in gdb to trap where the error
was being raised, and it's on line 179 of mime.c, which is in
mime_parse_line when it's checking the second byte of the 3-byte data item.
The error is raised if this byte is 255:
177: /* byte 1 ---------------------- */
178: if (*(p+1) == 255) {
179: mime_set_anomaly(MIME_ANOMALY_BROKEN_BASE64);
180: break;
181: }
I've done some basic reading of how base64 encoding works, and it appears
that if there isn't sufficient data to make the 3-byte encoding it get
padded with '=' characters. In mime.h in the mime_b64 array, the '='
character is mapped to 255. So it looks like the trailing '=', which are
supposed to indicate an end of the data, are causing the error to be raised
when there isn't anything wrong with the data. The base64 encoded data which
is being parsed at the time is: "eAAAUEsFBgAAAAB6AHoA5SMAALlLAQAAAA==\n"
(excluding the quotes).
I do note that in the exiscan code from the patch to Exim 4.44 no error is
raised if byte 1 is 255:
+ /* byte 1 ---------------------- */
+ if (*(p+1) == 255) {
+ break;
+ }
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@???
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
