Knowledge Partner Knowledge Partner
Knowledge Partner
1742 views

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
If you like it: like it.
Labels (2)
0 Likes
10 Replies
Absent Member.
Absent Member.

On 1/14/2013 9:56 AM, mathiasbraun wrote:
>
> 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
>
>

Content-Type: 'application/pdf'

is wrong

no quotes

Content-Type: application/pdf;name="xxxx.pdf"

is correct




0 Likes
Cadet 1st Class Cadet 1st Class
Cadet 1st Class

What model Ricoh is this? What is the NIB code version?

We have bazillions of Ricoh devices, yet I've not noticed this... but I'll be looking for it tomorrow.

As a practical matter, I think the ( for get the name of it ) management crapware IKON installed to monitor everything gets these service alerts and concentrates them into e-mails, but they come from the management platform - which means not from the NIB and so not formatted strangely.

-- Bob
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

thanks. apparently GWIA is tolerant enough to ignore these single quotes. if i remove them the message still fails.
to get it processed i have to invalidate the charset statement in

Content-Type: text/plain; charset="utf-8"

by either removing it or changing it to rubbish, i.e.

Content-Type: text/plain;
or
Content-Type: text/plain; charsetutf-8

will both work. removing the attachment instead works either.
If you like it: like it.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

thanks. this i a Kyocera FS-C1020MFP. apparently they've rebranded a Ricoh model.
Firmware 1.05
Motor Firmware 01.04
PCL-Version 1.04
PS-Version 1.04
PDL Firmware-Version 1.04

the message is really a scan, resulting in an empty boby with a pdf attached. the pdf itself is ok, if i invalidate the charset statement for the body it gets processed fine.
apparently they had no problems with these messages running 802HP3. i likely have a VM with 802HP3 lurking around somewhere and will check...
If you like it: like it.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

the complete message is avail via

ftp://forum:novell@ftp.netlogix.de
If you like it: like it.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

and some more homework...

GW704 on netware -> works
GW802ftf3 on netware -> works
GW803FCS on linux -> does NOT work
GW803ftf1 on netware -> does NOT work
GW2012FCS on linux -> works
GW2012sp1 on linux -> does NOT work

so i'd assume a change in the common code base for 2012sp1 / 803 to cause this.
If you like it: like it.
0 Likes
Absent Member.
Absent Member.

On 1/15/2013 8:16 AM, mathiasbraun wrote:
>
> and some more homework...
>
> GW704 on netware -> works
> GW802ftf3 on netware -> works
> GW803FCS on linux -> does NOT work
> GW803ftf1 on netware -> does NOT work
> GW2012FCS on linux -> works
> GW2012sp1 on linux -> does NOT work
>
> so i'd assume a change in the common code base for 2012sp1 / 803 to
> cause this.
>
>

I'll be honest. you've done great research, and hence it will probably
be easier to push if you have an SR. Otherwise it's basically with us in
the middle, and we dont actually have more power (well maybe a little
personal/social lubricant) than you. You seem well equipped to file
this. just include the ZIPPED MIME message and the info above, and let
us know what bug # it gets filed under and we'll jump in if things stall.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Michael Bell;2244124 wrote:
On 1/15/2013 8:16 AM, mathiasbraun wrote:
>
> and some more homework...
>
> GW704 on netware -> works
> GW802ftf3 on netware -> works
> GW803FCS on linux -> does NOT work
> GW803ftf1 on netware -> does NOT work
> GW2012FCS on linux -> works
> GW2012sp1 on linux -> does NOT work
>
> so i'd assume a change in the common code base for 2012sp1 / 803 to
> cause this.
>
>

I'll be honest. you've done great research, and hence it will probably
be easier to push if you have an SR. Otherwise it's basically with us in
the middle, and we dont actually have more power (well maybe a little
personal/social lubricant) than you. You seem well equipped to file
this. just include the ZIPPED MIME message and the info above, and let
us know what bug # it gets filed under and we'll jump in if things stall.



i've opened SR 10811736311 2 weeks ago. while working on this issue i've found several other issues with the recent gwia builds, which are at least a little less tolerant than they've been up to 802ftf3 / 2012fcs.
apart from other stuff i've noticed that a current gwia (i.e. 803 / 2012sp1 and younger) rejects messages which have a NUL (ascii 0) at the end (likely also anywhere else) of a base64 encoded attachment.
apart from the fact that this character obviously doesn't make too much sense there i'm not sure if this is valid at all. RFC 2045 is a little unclear on this as it says that "...all characters not found in the base64 alphabet must be ignored by decoding software". on the other hand they could "...probably indicate a transmission error, about which a warning message or even message rejection might be appropriate under some circumstances".
so does NUL belong to the "family of line breaks and white spaces"?
If you like it: like it.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

mathiasbraun;2244384 wrote:
i've opened SR 10811736311 2 weeks ago. while working on this issue i've found several other issues with the recent gwia builds, which are at least a little less tolerant than they've been up to 802ftf3 / 2012fcs.
apart from other stuff i've noticed that a current gwia (i.e. 803 / 2012sp1 and younger) rejects messages which have a NUL (ascii 0) at the end (likely also anywhere else) of a base64 encoded attachment.
apart from the fact that this character obviously doesn't make too much sense there i'm not sure if this is valid at all. RFC 2045 is a little unclear on this as it says that "...all characters not found in the base64 alphabet must be ignored by decoding software". on the other hand they could "...probably indicate a transmission error, about which a warning message or even message rejection might be appropriate under some circumstances".
so does NUL belong to the "family of line breaks and white spaces"?


to anyone with similar problems, i.e. certain mails with pdf attachments which were processed fine by gwia go "bad" after applying gw803:

nts has builds available which fix the issues for both gw8 and gw2012.
If you like it: like it.
0 Likes
Micro Focus Expert
Micro Focus Expert

Thank you for the information - much appreciated.

Cheers,
Laura Buckley

Views/comments expressed here are entirely my own.
If you find this post helpful, please show your appreciation and click on "Like" below...
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.