>On Fri, Jan 28, 2000 at 04:35:31PM -0600, Dennis Duval wrote:
>
>> to retrieve the file with OE and voila! it worked. When I pull the file
>> into a dos-based text editor in binary mode, it shows them as the NUL char,
>> hex 00. I'm not sure whether this editor is showing the actual data, or
>> just replacing the characters with NUL.
>
>Most likely NUL. Seen similar problems with Eudora. qmail/ezmlm have no
>problems with such messages and transport them happily (and correctly).
>
>> I guess the only questions are: where did the control chars come from, and
>> if they are some uncontrollable artifact of transmission, should OE be able
>> to retrieve the item even though they are present.
>
>Of course. At worst it should say that there are errors in that message and
>continue with the next. Write to microsoft.com support to get the bug fixed.
>
>(they may tell you that a POP3 transmission may not contain NUL, which may
>be correct in some sense, but is irrelevant to the need of the client to
>handle it).
Well - but them how about qmail not handling bare newlines in the body of
a message (and with the patch I use still not being recognizing \n.\n as
the end of a message)...
If OE shpuld handle NULL characters (which can stress you, if you program
in C/C++), than qmail should handle "strange" messages or smtp/pop3
commands too...
just my $0.2
mfg, fgp
