Haven't seen this one before... "Premature padding of base64 data"

[Philip Prindeville <ph...@redfish-solutions.com>]

This appeared in my logs.  Running 3.1.1 on Linux FC3 (x86_64) with
Sendmail 8.13.1 and Mimedefang 2.56:

Apr 13 16:57:05 mail sendmail[23371]: NOQUEUE: connect from
lists-outbound.sourceforge.net [66.35.250.225]
Apr 13 16:57:05 mail sendmail[23371]: k3DMv5s4023371: Milter
(mimdefang): init success to negotiate
Apr 13 16:57:05 mail sendmail[23371]: k3DMv5s4023371: Milter: connect to
filters
Apr 13 16:57:05 mail mimedefang.pl[22325]: helo:
lists-outbound.sourceforge.net
(66.35.250.225) said "helo lists-outbound.sourceforge.net"
Apr 13 16:57:05 mail sendmail[23371]: k3DMv5s4023371:
from=<al...@lists.sourceforge.net>, size=15309, class=-60,
nrcpts=1, msgid=<....@msn.com>, proto=ESMTP, daemon=MTA-v4,
relay=lists-outbound.sourceforge.net [66.35.250.225]
Apr 13 16:57:06 mail mimedefang-multiplexor[11341]: Slave 8 stderr:
Premature padding of base64 data at
/usr/lib/perl5/vendor_perl/5.8.5/MIME/Decoder/Base64.pm
line 109.
Apr 13 16:57:07 mail mimedefang.pl[22325]: k3DMv5s4023371: hits=18.463,
req=5,
names=DATE_IN_PAST_96_XX,FORGED_MSGID_MSN,HTML_IMAGE_ONLY_12,HTML_MESSAGE,HTML_SHORT_LINK_IMG_1,L_ALSA_DEVEL,MIME_HTML_ONLY,MSGID_SHORT,SPF_PASS,URIBL_SBL,URIBL_WS_SURBL
Apr 13 16:57:07 mail mimedefang.pl[22325]:
MDLOG,k3DMv5s4023371,spam,18.463,66.35.250.225,<al...@redfish-solutions.com>,[Alsa-devel]
Your mortagee approval
Apr 13 16:57:07 mail mimedefang.pl[22325]: filter: k3DMv5s4023371: 
bounce=1 discard=1
Apr 13 16:57:07 mail mimedefang[11357]: k3DMv5s4023371: Bouncing because
filter
instructed us to
Apr 13 16:57:07 mail sendmail[23371]: k3DMv5s4023371: Milter: data,
reject=554 5.7.1 Message rejected; scored too high on the Spam test.


Any ideas?  Didn't see any mention of it in previous postings...

Interesting msg-id.  Hmmm.  Already a rule for that.  Good...

-Philip

Re: Haven't seen this one before... "Premature padding of base64 data"

[Matt Kettler <mk...@evi-inc.com>]

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.