Re: [twsocket] E-Mail SmtpCli/MimeDec
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 boundary is found? By the way, is the output stream a buffer, or a file stream? If its a file stream, then its probably written to disk already. Look-ahead is the way to go. Great, Thanx! I'll work on implementing this next week (if I have time). dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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 buffer, or a file stream? If its a file stream, then its probably written to disk already. Look-ahead is the way to go. -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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 lot of people working on UNIX/Linux send "\n" at the end of a line in the socket stream, which in the UNIX world translates to only LF. It is easy and convenient to think that printing "\n" at the end of the line is the right thing to do, after all, that's the way to do it for any other output stream. But in most text-based, Internet protocols, this is wrong. I've seen many Perl and PHP scripts (like for webmail applications or error reporting tools) do this. The correct way, of course, is to send an explicit CRLF. dZ. -- I am a software developer; this is the path I have chosen. May God have mercy on my soul. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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 not looking for "--#10#13", but for "--" in the next string, which happens to be a line; in this case, it would need to combine with #2 below. 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. Lines are processed by the magic of FNext variable which is a pointer to the next procedure to handle data pointed by FCurrentData. FNext is changed according to the state or stage of decoding. FNext point to procedures like ProcessHeaderLine, ProcessMessageLine, ProcessWaitBoundary, ... So there is a finite state machine whose state variable is FNext. 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 buffer, or a file stream? If its a file stream, then its probably written to disk already. dZ. -- Trying to teach good programming habits in VB6 is like trying to teach proper hygiene in a sewer. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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 string, which happens to be a line; in this case, it would need to combine with #2 below. 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. Lines are processed by the magic of FNext variable which is a pointer to the next procedure to handle data pointed by FCurrentData. FNext is changed according to the state or stage of decoding. FNext point to procedures like ProcessHeaderLine, ProcessMessageLine, ProcessWaitBoundary, ... So there is a finite state machine whose state variable is FNext. -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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 opinion of others on my previous message, about the best way to go about it, as I am not very familiar with the best practices and code style of TWSocket innards. dZ. -- Time flies like the wind... Fruit flies like bananas. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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. -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: "Arno Garrels" <[EMAIL 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 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 complicated for me today), I fixed it on the application level :( Arno, Have you had a chance to look into this? No I haven't, I decided to not touch MimeDec.pas and fixed it on the application level (2 lines in my code). However it would be nice to get this fixed in the component. I wonder if Francois has noticed this thread? May be the subject should be changed to "BUG in MimeDec" ;-) May be he's currently more interested in HTTP and SSL stuff? Unfortunately I can't say more. Arno Garrels I tried to study MimeDec.pas a few days ago, but found it (like you) too complicated for the moment (its been a while since I touched TWSocket code specifically and Delphi in general). But the immediate problem that I saw is that the decoded string is being written to the output buffer "live", as it is being decoded, line by line, including the blank lines which come before boundaries and should be removed. Since these blanks belong to the boundary itself, I only see potential 3 solutions: 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 string, which happens to be a line; in this case, it would need to combine with #2 below. 2. Implement a look-ahead system when writing the buffer (or detecting boundaries) to remove blank lines belonging to the boundaries (or ignore them when detecting). 3. Remove the blank lines from the output buffer ex post facto, i.e. once we detect a boundary, we are guaranteed to have found a blank line before (a boundary must have a #10#13 before it -- or else this is not a valid MIME encapsulation!), which has already been written into the output buffer, and so we go back and remove it. This is fine if the output buffer is in fact a buffer, but I'm not sure if it is, or could be, a file stream, in which case removing a written line is not trivial. These are only very high-level ideas, because I didn't spend more than 30 minutes studying MimeDec, and so they could be way off the mark. What do you guys think? dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
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 >>> 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 complicated for me >> today), >> I fixed it on the application level :( > > Arno, > > Have you had a chance to look into this? No I haven't, I decided to not touch MimeDec.pas and fixed it on the application level (2 lines in my code). However it would be nice to get this fixed in the component. I wonder if Francois has noticed this thread? May be the subject should be changed to "BUG in MimeDec" ;-) May be he's currently more interested in HTTP and SSL stuff? Unfortunately I can't say more. Arno Garrels > I tried to study MimeDec.pas a > few days ago, but found it (like you) too complicated for the moment > (its been a while since I touched TWSocket code specifically and Delphi > in general). But the immediate problem that I saw is that the decoded > string is being written to the output buffer "live", as it is being > decoded, line by line, including the blank lines which come before > boundaries and should be removed. > > Since these blanks belong to the boundary itself, I only see potential > 3 solutions: > > 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 string, which > happens to be a line; in this case, it would need to combine with #2 > below. > > 2. Implement a look-ahead system when writing the buffer (or detecting > boundaries) to remove blank lines belonging to the boundaries (or > ignore them when detecting). > > 3. Remove the blank lines from the output buffer ex post facto, i.e. > once we detect a boundary, we are guaranteed to have found a blank line > before (a boundary must have a #10#13 before it -- or else this is not > a valid MIME encapsulation!), which has already been written into the > output buffer, and so we go back and remove it. This is fine if the > output buffer is in fact a buffer, but I'm not sure if it is, or could > be, a file stream, in which case removing a written line is not > trivial. > > These are only very high-level ideas, because I didn't spend more than > 30 minutes studying MimeDec, and so they could be way off the mark. > What do you guys think? > > dZ. > > -- > Trying to teach good programming habits in VB6 is like trying to teach > proper hygiene in a sewer. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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 complicated for me today), I fixed it on the application level :( Arno, Have you had a chance to look into this? I tried to study MimeDec.pas a few days ago, but found it (like you) too complicated for the moment (its been a while since I touched TWSocket code specifically and Delphi in general). But the immediate problem that I saw is that the decoded string is being written to the output buffer "live", as it is being decoded, line by line, including the blank lines which come before boundaries and should be removed. Since these blanks belong to the boundary itself, I only see potential 3 solutions: 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 string, which happens to be a line; in this case, it would need to combine with #2 below. 2. Implement a look-ahead system when writing the buffer (or detecting boundaries) to remove blank lines belonging to the boundaries (or ignore them when detecting). 3. Remove the blank lines from the output buffer ex post facto, i.e. once we detect a boundary, we are guaranteed to have found a blank line before (a boundary must have a #10#13 before it -- or else this is not a valid MIME encapsulation!), which has already been written into the output buffer, and so we go back and remove it. This is fine if the output buffer is in fact a buffer, but I'm not sure if it is, or could be, a file stream, in which case removing a written line is not trivial. These are only very high-level ideas, because I didn't spend more than 30 minutes studying MimeDec, and so they could be way off the mark. What do you guys think? dZ. -- Trying to teach good programming habits in VB6 is like trying to teach proper hygiene in a sewer. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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 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 complicated for me today), I fixed it on the application level :( Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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 should swallow that and not append it to the content of the section. Exactly. See RFC 1341, section 7.2.1. "Multipart: The common syntax": http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html dZ. -- Trying to teach good programming habits in VB6 is like trying to teach proper hygiene in a sewer. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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 mailers running arround that do not append this 'spacer' CRLF? Mozilla Thunderbird behaves the same, here is an example: 1.Line --010609020500050508040002 [..] MimeDec decodes it to "1.Line" I would like to know if it is save to replace the trailing by . Yes, it should be deleted. After digging a little, I found out that the only requirement by the RFC is that there must be a preceding the boundary, and that this is considered part of the boundary, so as to define it as: boundary-- Anything before the preceding is part of the content (in your case, the ending of the content). NOTE: The CRLF preceding the encapsulation line is considered part of the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, should have two CRLFs preceding the encapsulation line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary. http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html In essence, what that means is that the second that you see belongs to the boundary itself and should have been removed by MimeDec. Whenever you see 2 following the content, it means that the content itself ended with ONE (and therefore should stay), and that the second was part of the boundary. dZ. -- I am a software developer; this is the path I have chosen. May God have mercy on my soul. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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/plain; charset=ISO-8859-1; Content-Transfer-Encoding: 7bit 1.Line --010609020500050508040002 [..] MimeDec decodes it to "1.Line" I would like to know if it is save to replace the trailing by . (First time posting to the list, so go easy on me :) ) 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 should swallow that and not append it to the content of the section. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] E-Mail SmtpCli/MimeDec
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 append this 'spacer' CRLF? Mozilla Thunderbird behaves the same, here is an example: Message text: "1.Line" Encoded: [..] --010609020500050508040002 Content-Type: text/plain; charset=ISO-8859-1; Content-Transfer-Encoding: 7bit 1.Line --010609020500050508040002 [..] MimeDec decodes it to "1.Line" I would like to know if it is save to replace the trailing by . Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] E-Mail SmtpCli/MimeDec
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? Thanks, Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
