Quantcast
Viewing all articles
Browse latest Browse all 11924

What's wrong with this one?

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:

--snip--

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

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


--RICOH-Smtp-BOUNDARY-xxxx
Content-Type: 'application/pdf';
name="130114141755.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="130114141755.pdf"

--endofsnip--

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
charset="utf-8"
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
charset=US-ASCII
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?

THX,
mb

Viewing all articles
Browse latest Browse all 11924

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>