On Jun 11, 2005, at 10:46, Francois PIETTE wrote:
Thanx Francois. Would you think its better to implement a
look-ahead, so that every time that a blank line is found, we check
if the next line is a boundary before adding it to the output stream;
or remove it from the output stream after a bou
Thanx Francois. Would you think its better to implement a look-ahead,
so that every time that a blank line is found, we check if the next
line is a boundary before adding it to the output stream; or remove it
from the output stream after a boundary is found? By the way, is the
output stream a
On Jun 11, 2005, at 09:11, Francois PIETTE wrote:
InternalDecodeStream read the input stream and find line end (using
only LF because so much messages are mal formed and use only LF
instead of CR/LF pair). Of course if CR is there, it is processed
transparently.
This is easily explained -- a
On Jun 11, 2005, at 09:11, Francois PIETTE wrote:
1. Change the boundary detection to look for
"#10#13--#10#13" instead of just "--#10#13". But
this might be hard, because as far as I understood MimeDec, it
already has the stream split into lines before testing for
boundaries, and so it is n
1. Change the boundary detection to look for "#10#13--#10#13"
instead of just "--#10#13". But this might be hard, because as
far as I understood MimeDec, it already has the stream split into lines
before testing for boundaries, and so it is not looking for
"--#10#13", but for "--" in the next
On Jun 11, 2005, at 02:08, Francois PIETTE wrote:
I wonder if Francois has noticed this thread?
Yes, I have noticed this thread.
I'm just waiting to see if someone can take this problem in charge to
reduce my own charge.
Well, I will gladly write the code to fix it, but I would like the
IL PROTECTED]>
To: "ICS support mailing"
Sent: Friday, June 10, 2005 9:36 PM
Subject: Re: [twsocket] E-Mail SmtpCli/MimeDec
DZ-Jay wrote:
On Jun 2, 2005, at 06:04, Arno Garrels wrote:
[snip a lot]
[snip some more!]
In essence, what that means is that the second that you see
DZ-Jay wrote:
> On Jun 2, 2005, at 06:04, Arno Garrels wrote:
>
>> [snip a lot]
>>
> [snip some more!]
>>> In essence, what that means is that the second that you see
>>> belongs to the boundary itself and should have been removed by
>>> MimeDec.
>>
>> Thanks DZ and Michael,
>>
>> After a brie
On Jun 2, 2005, at 06:04, Arno Garrels wrote:
[snip a lot]
[snip some more!]
In essence, what that means is that the second that you see
belongs to the boundary itself and should have been removed by
MimeDec.
Thanks DZ and Michael,
After a brief look at MimeDec.pas I gave it up (too comp
DZ-Jay wrote:
> On Jun 2, 2005, at 02:29, Arno Garrels wrote:
>
[snip a lot]
>> 1.Line
>>
>> --010609020500050508040002
>> [..]
>>
>> MimeDec decodes it to "1.Line"
>> I would like to know if it is save to replace the trailing
>> by .
[snip a lot]
> In essence, what that means
On Jun 2, 2005, at 03:13, Michael Preslar wrote:
(First time posting to the list, so go easy on me :) )
Welcome! Very good post, so no worries :)
To the best of my knowledge, the RFC says that its
--(identifier) to start a section and --(identifier)-- to
end a section.. To me, MimeDec sho
On Jun 2, 2005, at 02:29, Arno Garrels wrote:
Arno Garrels wrote:
I'm having problems with the last CRLF in plain mime parts.
OE as well as SmtpCli put a CRLF between part content and the closing
boundary. MimeDec however reads this extra CRLF as content, so I get
corrupted messages.
Are there
I'm having problems with the last CRLF in plain mime parts.
...
Are there mailers running arround that do not append this 'spacer' CRLF?
Mozilla Thunderbird behaves the same, here is an example:
Message text: "1.Line"
Encoded:
[..]
--010609020500050508040002
Content-Type: text
Arno Garrels wrote:
> I'm having problems with the last CRLF in plain mime parts.
> OE as well as SmtpCli put a CRLF between part content and the closing
> boundary. MimeDec however reads this extra CRLF as content, so I get
> corrupted messages.
> Are there mailers running arround that do not ap
Hello,
I'm having problems with the last CRLF in plain mime parts.
OE as well as SmtpCli put a CRLF between part content and the closing boundary.
MimeDec however reads this extra CRLF as content, so I get corrupted messages.
Are there mailers running arround that do not append this 'spacer' CRLF
15 matches
Mail list logo
