questions on QP, non-text attachments and munpack
hansen@pegasus.att.com Thu, 08 February 1996 14:32 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12547;
8 Feb 96 9:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12543;
8 Feb 96 9:32 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa06677; 8 Feb 96 9:32 EST
Received: from localhost (localhost [127.0.0.1]) by list.cren.net
(8.6.12/8.6.12) with SMTP id JAA10396; Thu, 8 Feb 1996 09:06:53 -0500
Received: from gw3.att.com (gw4.att.com [204.179.186.34]) by list.cren.net
(8.6.12/8.6.12) with SMTP id JAA10375 for <ietf-822@list.cren.net>;
Thu, 8 Feb 1996 09:05:25 -0500
Received: from pegasus.UUCP by ig4.att.att.com id AA07818;
Thu, 8 Feb 96 08:58:11 EST
Message-Id: <9602081358.AA07818@ig4.att.att.com>
Date: Thu, 8 Feb 1996 08:53 EST
X-Orig-Sender: owner-ietf-822@list.cren.net
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: hansen@pegasus.att.com
To: ietf-822@list.cren.net
Subject: questions on QP, non-text attachments and munpack
Content-Type: text
X-Listprocessor-Version: 8.0(beta) -- ListProcessor by CREN
I have a mailer that encodes non-text attachments using either b64 or QP
depending on which would produce the smaller output. This is particularly
useful dealing with almost-text attachments, such as some EDI streams, which
are MOSTLy ascii text but either have extremely long lines or a small number
of binary characters. Encoding these attachments with QP gives a much
smaller increase in size over what would be produced by using b64.
We recently ran into a problem where a customer received a MIME mail
message with such a QP encoded attachment. This customer was using munpack
to extract the attachments.
Now, munpack is a great tool. However, it does one thing that messed up the
attachment for our customer. In the process of decoding the attachment, it
makes the assumption that QP is only being used in text attachments and
STRIPS all CR characters, evidently trying to merge the UNIX CRLF->NL
conversion into the same pass. Unfortunately, this messed up the customer's
software considerably when it tried to use the reconstructed attachment.
Now for the questions:
o Is my mailer correct in believing that it should be able to use QP
for non-text attachments? After all, QP IS supposed to just be an
encoding.
o Is munpack wrong in stripping CR's when dealing with non-text
attachments?
Tony Hansen
hansen@pegasus.att.com, tony@attmail.com
http://ourworld.compuserve.com/homepages/Tony_Hansen
- questions on QP, non-text attachments and munpack hansen
- Re: questions on QP, non-text attachments and mun… Jamie Zawinski
- Re: questions on QP, non-text attachments and mun… Ned Freed
- Re: questions on QP, non-text attachments and mun… Jamie Zawinski
- Re: questions on QP, non-text attachments and mun… hansen
- Re: questions on QP, non-text attachments and mun… hansen
- Re: questions on QP, non-text attachments and mun… Ned Freed
- Re: questions on QP, non-text attachments and mun… John Gardiner Myers
- Re: questions on QP, non-text attachments and mun… John Gardiner Myers
- Re: questions on QP, non-text attachments and mun… hansen
- Re: questions on QP, non-text attachments and mun… hansen
- Re: questions on QP, non-text attachments and mun… Ned Freed
- Re: questions on QP, non-text attachments and mun… Keith Moore
- Re: questions on QP, non-text attachments and mun… Ned Freed