Offset: GW803HP1 on Netware, also duped with GW2012SP1 on SLES

The following is a snippet of a mail which gets generated by a scan on some sort of multifunction printer:


X-Mailer: RICOH Email Diag System Alert Info
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="RICOH-Smtp-BOUNDARY-xxxx"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Content-Type: 'application/pdf';
Content-Transfer-Encoding: base64
Content-Disposition: attachment;


All these mails fail conversion on the GWIA and go to the bad ones. Please note that the attachment itself is fine along with the proper boundary.
If i remove the
statement or change it to something silly such as
charsetisfromouterspace (note the missing equals sign)
i can reinsert the message into the GWIA queue and it's getting delivered just fine.

Seems that GWIA disregards an invalid charset statement, treats it just like missing one and defaults to us-ascii.
If i set the statement to read
it starts failing again. On the other hand i can safely generate a file with pretty much the same properties (as for content-type and transfer encoding of body and attachment), paste it into the queue and can watch it being processed just fine.
Does anyone see anything non-RFC-compliant in the message?