Re: [twsocket] [TMimeDec] Beta version to test
Hello! Send me one (or all) of these messages (or better post them somewhere and give me the url) and I'll check it out. Not a single MIME message in my mailbox decoded the last attachment correctly, I don't suppose the issue is very hard to reproduce. I'll relay the two examples I posted before so you see the same headers I saw. HCM, which *bases* on my (beta) code decodes it properly! You've sent me a message containing a plain text part and html version of it, a Magenta Systems logo, Magenta Systems main WWW page, a Excel file and a zipfile with adult webcams list. Note that TMimeDec for a long time was broken and proper (RFC-compliant) part decoding required some coding - maybe that's the case. I've not added any extra code, I was using my TMimeDecEx component from the usermade page and reporting all the parts found by events, nothing complex atall. If every other mailer is producing non-compliant MIME that co-incidenally the old MimeDec handling OK, that's what we need to stick with, not changes to lose the message content. Okay, I agree, but having bugged code fix earlier bugs (like I did with the TSmtpCli - it was *not* flushing its buffer, and it was not resetting his buffer position, so although messages actually were concatenated, each of them was sent as a separate one) is not the solution. It's better to have two days of additional work more and then have additional four free days, than having to remember why that must be coded this way and not the logical one, or fighting with those (most of the time invisible) bugs. You have the sample of what hidden (for too long time) bug can do for you ;-) And what was the cause? In TMimeDecEx you set destination stream *after the part was decoded*. You lose your data, because you *don't save it*: In the old code you have: *part begin* Part 0, Content: multipart/mixed, Size: 44, Name: , FileName: , Encoding: *part end* *part begin* Part 1, Content: multipart/alternative, Size: 2, Name: , FileName: , Encoding: *part end* *part begin* Part 2, Content: text/plain, Size: 46, Name: , FileName: , Encoding: quoted-printable *part end* *part begin* Part 3, Content: text/html, Size: 320, Name: , FileName: , Encoding: quoted-printable *part end* *part begin* Part 4, Content: text/plain, Size: 0, Name: , FileName: , Encoding: *part end* *part begin* Part 5, Content: image/gif, Size: 3,640, Name: maglogo.gif, FileName: maglogo.gif, Encoding: base64 *part end* *part begin* Part 6, Content: text/html, Size: 6,825, Name: index.html, FileName: index.html, Encoding: quoted-printable *part end* *part begin* Part 7, Content: application/vnd.ms-excel, Size: 73,728, Name: bands.xls, FileName: bands.xls, Encoding: base64 *part end* *part begin* Part 8, Content: application/x-zip-compressed, Size: 5,327, Name: Defsites.zip, FileName: Defsites.zip, Encoding: base64 *part end* *part begin* Part 9, Content: text/plain, Size: 8, Name: , FileName: , Encoding: *part end* In the new one (note the indent): *part begin* Part 0, Content: multipart/mixed, Size: 44, Name: , FileName: , Encoding: *part begin* Part 1, Content: multipart/alternative, Size: 2, Name: , FileName: , Encoding: *part begin* Part 2, Content: text/plain, Size: 46, Name: , FileName: , Encoding: quoted-printable *part end* *part begin* Part 3, Content: text/html, Size: 320, Name: , FileName: , Encoding: quoted-printable *part end* *part end* *part begin* Part 4, Content: image/gif, Size: 3,640, Name: maglogo.gif, FileName: maglogo.gif, Encoding: base64 *part end* *part begin* Part 5, Content: text/html, Size: 6,825, Name: index.html, FileName: index.html, Encoding: quoted-printable *part end* *part begin* Part 6, Content: application/vnd.ms-excel, Size: 73,728, Name: bands.xls, FileName: bands.xls, Encoding: base64 *part end* *part begin* Part 7, Content: application/x-zip-compressed, Size: 5,327, Name: Defsites.zip, FileName: Defsites.zip, Encoding: base64 *part end* *part end* (actual part sizes may slightly differ in some cases) Old TMimeDec treated starting and ending (with additional -- at the end of line) boundary as one and the same thing, which is (was?) wrong - since parts can be stored in subparts (creating a such tree), not distinguishing between starting and ending MIME boundaries leads to phantom (short-length and empty) parts (in the above example, old TMimeDec's part 4 maps to the part between first text/html part end and multipart/alternative part end). Hope this helps... :) -- Piotr Hellrayzer Dalek Author of ICS-Based Hellcore Mailer - an Outlook Express killer http://www.hcm.prv.pl [EMAIL PROTECTED] -- Startuj z INTERIA.PL! http://link.interia.pl/f186c -- To unsubscribe or change your settings for TWSocket mailing list please goto
[twsocket] [TMimeDec] Boundary detection optimization
Hi!
There's possible optimization. Since all MIME boundaries start with
-- (=$2D2D), we could check whether FCurrentData points to two dashes
instead of copying whole data line, switching to lowercase and then
comparing:
procedure TMimeDecode.ProcessWaitBoundary; { ##ERIC }
var
t : Integer;
s : String;
begin
if (FCurrentData nil) and (FCurrentData^ #0) and
{$IFDEF DELPHI2_UP} (PWord(FCurrentData)^=$2D2D) {$ELSE}
((FCurrentData[1]=#$2D)and(FCurrentData[2]=#$2D)) {$ENDIF} then begin
[..]
procedure TMimeDecode.ProcessPartLine; { ##ERIC }
var
t : Integer;
s : String;{ ##ERIC }
begin
{ Check if end of part (boundary line found) }
if (FCurrentData nil) and (FCurrentData^ #0) and
{$IFDEF DELPHI2_UP} (PWord(FCurrentData)^=$2D2D) {$ELSE}
((FCurrentData[1]=#$2D)and(FCurrentData[2]=#$2D)) {$ENDIF} then begin
This optimization would make great difference when dealing with large
multipart MIME messages - parsing time of 9,1MB message (large Base64
attachment) was reduced by this optimization to ~20 seconds (from ~30) - on
my old Pentium 120 machine.
--
Piotr Hellrayzer Dalek
Author of ICS-Based Hellcore Mailer - an Outlook Express killer
http://www.hcm.prv.pl
[EMAIL PROTECTED]
--
Najlepszy serwis MOTO w Polsce! http://link.interia.pl/f18a8
--
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] [TMimeDec] Preamble and Epilogue
Hi!
TMimeDec does NOT ignore MIME preamble and epilogue, so it fails to decode
correctly complex multipart message from RFC 2049 Appendix A. Specifically,
when it sees ending boundary (--boundary--) it starts another part.
Disabling preamble parsing as text/plain is very simple, just have to
check in OnHeaderEnd if the ContentType starts with multipart/ - if so,
we have to ignore next part. With preambles and epilogues of embedded
parts is far worse. Let's see the ProcessPartLine:
procedure TMimeDecode.ProcessPartLine; { ##ERIC }
var
Len : Integer;
t : Integer;
s : String;{ ##ERIC }
begin
{ Check if end of part (boundary line found) }
if (FCurrentData nil) and (FCurrentData^ #0) then begin
s := LowerCase(StrPas(FCurrentData));
if (s = FBoundary) then begin
PreparePart;
exit;
end
else if (s = (FBoundary + '--')) then begin
FEndOfMime := TRUE;
PreparePart;
exit;
end
else begin
for t := 0 to FEmbeddedBoundary.Count - 1 do begin
if (s = FEmbeddedBoundary[t]) or
(s = (FEmbeddedBoundary[t] + '--')) then begin
{ we now have to wait for the next part }
PreparePart;
exit;
end
end;
end;
end;
[..]
What do we see? When we hit epilogue of *the message*, we get information
about that we're done with MIME (whatever that should mean...). We don't
get *any* information if we crossed the ending boundary (--boundary--)
and start parsing epilogue. TMimeDec simply starts another part! My fix:
procedure TMimeDecode.ProcessPartLine; { ##ERIC }
var
Len : Integer;
t : Integer;
s : String;{ ##ERIC }
begin
{ Check if end of part (boundary line found) }
if (FCurrentData nil) and (FCurrentData^ #0) then begin
s := LowerCase(StrPas(FCurrentData));
if (s = FBoundary) then begin
PreparePart;
exit;
end
else if (s = (FBoundary + '--')) then begin
FPartOpened := False; //phd
TriggerPartEnd; //phd
exit;
end
else begin
for t := 0 to FEmbeddedBoundary.Count - 1 do begin
if s = FEmbeddedBoundary[t] then begin //phd
PreparePart; //phd
Exit; //phd
end else if s=(FEmbeddedBoundary[t] + '--')) then begin
FPartOpened := False; /phd
TriggerPartEnd; //phd
exit; //phd
end
end;
end;
end;
[..]
And I propose that we throw away that FEndOfMime. From my point of view,
it's useless, and still eats that byte or four (if compiler aligns variables
on dword boundaries).
--
Piotr Hellrayzer Dalek
Author of ICS-Based Hellcore Mailer - an Outlook Express killer
http://www.hcm.prv.pl
[EMAIL PROTECTED]
--
Najlepszy serwis MOTO w Polsce! http://link.interia.pl/f18a8
--
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] Why exceptions?
Hi!
I just wonder - why we have to use exceptions and exception handling so
often? I mean, why exceptions, not function results? For example:
procedure TNntpCli.List(DestStream : TStream);
begin
if FState nntpReady then
raise NntpException.Create('Not ready for LIST');
FDataStream := DestStream;
FRequestType := nntpList;
FRequest := 'LIST NEWSGROUPS';
FNext:= GetArticleNext;
StateChange(nntpWaitingResponse);
SendRequest;
end;
Why not change it to
function TNntpCli.List(DestStream : TStream): boolean
begin
if FState nntpReady then
result:=false
else
begin;
FDataStream := DestStream;
FRequestType := nntpList;
FRequest := 'LIST NEWSGROUPS';
FNext:= GetArticleNext;
StateChange(nntpWaitingResponse);
SendRequest;
result:=true;
end
end;
Currently, when exception is raised, sometimes I don't know if the exception
was raised in TWSocket, or TNntpCli (and I know that I could find that
out by checking exception class, but sometimes exception is raised not
because broken program logic, but because - for example - broken connection)
and I'm forced to use procedure-global exception handlers, or else I'll
end with a hell-lot of small exception handlers that would give me a bit
more info about what went wrong, but also complicate, enlarge and slow down
RequestDone procedures (which have to handle 1 - yes, over ten thousand
- RequestDones per connection).
Personally... I hate exceptions...
--
Piotr Hellrayzer Dalek
Author of ICS-Based Hellcore Mailer - an Outlook Express killer
http://www.hcm.prv.pl
[EMAIL PROTECTED]
--
Startuj z INTERIA.PL! http://link.interia.pl/f186c
--
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] Datetime in mail headers
Hello! Do I need the MIME-Version, Content-Type and Content-Transfer-Encoding also or can it be left out ? There will be only plain text and never an attach. AFAIR if you won't put them in header, the default values should be assumed (respectively: 1.0, text/plain; charset=US-ASCII, 7bit) by the message parser. MailBody := 'Delivered-To: ' + EMail + #13#10 + 'Subject: ' + Subject + #13#10 + 'Date: ' + DT + #13#10 + 'MIME-Version: 1.0'#13#10 + 'Content-Type: text/plain; charset=us-ascii'#13#10 + 'Content-Transfer-Encoding: quoted-printable'#13#10 + 'From: ' + From + #13#10 + 'To: ' + DestName + #13#10#13#10 + Data; If you're using US-ASCII, consider using Content-Transfer-Encoding: 7bit. -- Piotr Hellrayzer Dalek Author of ICS-Based Hellcore Mailer - an Outlook Express killer http://www.hcm.prv.pl [EMAIL PROTECTED] -- Znajdz swoja milosc na wiosne... http://link.interia.pl/f187a -- 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] Any alternatives to multithreading?
Hello! so message queue overflow won't occur so often? What exacly flows over ? I mean, on what do you see this ? Application gets unresponsive. Simply refuses to react for mouse clicks, keypresses, anything except network operations. On my home P120 it shows up, when I download many 1-5kB messages with more than 75-100kB/s (actually I get no more than that). There's no problem with large (1MB) messages, while they're downloaded, everything works fine and transfer speed is also high (200kB/s). I know that parsing causes these trouble, but I just had to ask for any other solutions than putting network connections and parsers into a separate thread. -- Piotr Hellrayzer Dalek Author of ICS-Based Hellcore Mailer - an Outlook Express killer http://www.hcm.prv.pl [EMAIL PROTECTED] -- Startuj z INTERIA.PL! http://link.interia.pl/f186c -- 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
