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
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 :
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
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');
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
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
