Philip Prindeville wrote: > Apr 13 16:57:06 mail mimedefang-multiplexor[11341]: Slave 8 stderr: > Premature padding of base64 data at <snip> > > > Any ideas? Didn't see any mention of it in previous postings... >
Looks like someone screwed up their base-64 encoding. Base64 encodes into "quartets", where 3 8-bit bytes get encoded as 4 ascii characters containing 6 bits of data each, so they can fit into ascii-text ranges. At the end of the input, Base64 is normally padded out to make a quartet with = characters if the input ends in a non-even multiple of 3 bytes (thus not making a complete quartet) Because it's a 3->4 encoding, even one byte of input generates two bytes of code output, the first holding 6 of the 8 input bits, and the next holding the remaining 2. In this case, the last two characters of the quartet get filled with = as a pad. If you were to think of base-64 as a series of the input is 3 8-bit bytes, like so: 12345678 12345678 12345678 That input gets re-split into 4 pieces of 6-bits each, like this: 123456 781234 567812 345678 But with a short input: 12345678 encodes as something like: 123456 780000 '=' '=' The error message you see means that an = was inserted in the first or second position of the last quartet of encoded data. That can never happen, unless the data is invalid or corrupted. Either some bytes were dropped, resulting in a base64 encoding that's not a multiple of 4 bytes, causing a pad to get shifted up. Or more than 2 pads exist at the end.
