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 http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
