After further investigation I made a small pop3 server emulator that sends all character codes except 0x00, 0x0A and 0x0D which should not be in message anyway.
Even though the LastResponse unicode looks a bit odd in debugger, after doing a SslPop3Cli->LastResponse.c_str(); and SslPop3Cli->LastResponse.t_str(); and assigning it to some single-byte string type like AnsiString the characters are back to original byte-codes. c_str return wchar_t pointer which is probably converted into single-byte string and t_str returns char_t pointer is for compatibility purposes for getting raw data (I read somewhere that it may be dangerous to use because of the conversions and mangling it could do but obviously it does the same thing in this case like c_str); I don't know how Delphi equvalent for c_str and t_str are named. So I guess that UnicodeString somehow preserves or converts raw bytes properly back to AnsiString and no further help is necessary I guess, unless of course someone wants to comment on this to add some useful additional info or if I figured it out totally wrong :) Also after reading a bit of RFC's char codes above 127 should not be in email anyway but should be encoded/quoted/whatever but it should be handled when reading it, thanks to other email programs that may use it. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
