hansen(_at_)pegasus(_dot_)att(_dot_)com wrote:
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.
It is perfectly correct. If it makes sense for you to use QP for non-text
material you are free to do so.
The system I use makes this decision based on which encoding is more efficient.
(Not that either one is all that efficient...) There are plenty of cases where
QP is more efficient than base64 and I use it when it is, regardless of content
type.
o Is munpack wrong in stripping CR's when dealing with non-text
attachments?
It depends on what CRs you are referring to. There are three sorts in QP:
(1) Those that appear as =0D. These should only appear in the content of
types other than text -- the rules for text require that CR only be
used a part of a CRLF sequence and that such sequences be represented
as a line break in the encoded output. When they do appear in non-text
material, however, they must not be stripped.
(2) Those that appear as part of a =<CR><LF> sequence. These "soft breaks"
should always be removed regardless of the type of content involved.
(3) Those that appear as a <CR><LF> sequence that isn't preceeded by =. These
"hard breaks" are only supposed to be used in MIME text. They should not
appear in non-text material. When they appear in text material, however,
they must not be discarded.
My guess is that the case you're referring to is (3), and you did say that the
material isn't textual in form. In this case there aren't supposed to be any
hard breaks present. And if there are MUNPACK could strip them if it wanted to.
It is neither "correct" or "incorrect" to do so.
I could go either way on whether or not it is a good idea for MUNPACK to behave
this way. On one hand, it would be nice to accomodate improper usage of hard
line breaks when encoding non-text material. On the other hand, I can see an
argument for ignoring such breaks as possibly having originated in mishandling
of the encoded material at some point.
For what it's worth, I believe my decoder would turn hard breaks into CRLF
sequences in non-text material. In other words, I didn't do it the way
MUNPACK does, but I cannot claim that my approach is clearly the better
one. (In fact, now that I know what MUNPACK does, I'm going to rethink my
choice!)
Ned