ap2021 0 Posted October 27 (edited) Trying to send an email (through ICS), but getting it BASE64 encoded. The Content-Transfer-Encoding header on the message is set to just a single letter "b". Looks like the encoding is messed up somewhere, but it's all ICS vanilla code, all I do is call the SslSmtpCli object and have a callback to perform the steps. Also, I think it used to work for me before. Were there any breaking changes there recently? PS: Changing the DefaultEncoding to smtpEncQuotedPrintable, for instance, sets that header to "q" and the message contains some garbage. Edited October 27 by ap2021 Share this post Link to post
Angus Robertson 575 Posted October 27 There were massive changes to Base64 to use TBytes due to your complaints about it not working with AnsiChars, although no problems were ever found. What is the last history date in the Utils unit? Angus Share this post Link to post
ap2021 0 Posted October 27 (edited) Oct 13, 2024 You should get rid of those ansistrings in all callable routines and do the conversions behind the scenes if you must. Edited October 27 by ap2021 Share this post Link to post
Olli73 5 Posted October 27 15 minutes ago, ap2021 said: Note, that it encodes it just fine, it's just that it somehow screws up the message, so its header just reads Content-Transfer-Encoding : b How do you set the encoding? Share this post Link to post
ap2021 0 Posted October 27 Just set the DefaultEncoding property to smtpEncBase64. The text is fine, it just gets BASE64-encoded and then never decoded by the mail client. TSslSmtpCli works with normal UTF16 strings and theres very little stuff going on outside of it, so there are no character conversions that I can see and none that I do, all text I tested so far was just plain English. Share this post Link to post
Angus Robertson 575 Posted October 27 I asked for the date in the unit, not for you to waste space here copying text from the unit. If you can reproduce the problem using the OverbyteIcsMimeDemo sample, I will put it on the list to investigate. Angus Share this post Link to post
Olli73 5 Posted October 27 (edited) In the unit "OverbyteIcsSmtpProt.pas" you can find this line: StrCat(PAnsiChar(Line), PAnsiChar(SmtpDefEncArray[FMailMsgText.TransferEncoding])); But it must be: StrCat(PAnsiChar(Line), PAnsiChar(AnsiString(SmtpDefEncArray[FMailMsgText.TransferEncoding]))); Edit: Text translated, first I wrote in German 😉 Edited October 27 by Olli73 Share this post Link to post
ap2021 0 Posted October 27 24 minutes ago, Olli73 said: In the unit "OverbyteIcsSmtpProt.pas" you can find this line: StrCat(PAnsiChar(Line), PAnsiChar(SmtpDefEncArray[FMailMsgText.TransferEncoding])); But it must be: StrCat(PAnsiChar(Line), PAnsiChar(AnsiString(SmtpDefEncArray[FMailMsgText.TransferEncoding]))); Edit: Text translated, first I wrote in German 😉 Many thanks, that was indeed the solution! Wunderbar! Share this post Link to post
ap2021 0 Posted October 27 I guess an even easier fix would have been to define Smtp DefEncArray with pansichar in the first place. Angus, please add it to your list. I can confirm that Olli73's solution works. Share this post Link to post
Angus Robertson 575 Posted October 28 Historically there were several Base64 implementations in different units, which I've been slowly consolidating. I did look at the email MIME stuff briefly, but it was too convoluted to update to TBytes, and also lacks means to test stuff easily without building emails. But I will look at AnsChar casting, that code is probably unchanged for 20 years. I never write code using null terminated strings, unless needed for APIs. Angus Share this post Link to post
Angus Robertson 575 Posted October 28 This was a bug I introduced in V9.3 attempting to reduce the amount of string casting by avoiding AnsiStrings which normally give compiler warnings, but not in the case of bad pointer casting, and the SMTP unit is unique in building strings using pointers. The AnsiString cast mentioned earlier fixes the problem, not in SVN yet. Angus Share this post Link to post