email issues

[ap2021 0]

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

[Angus Robertson 574]

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

 

[ap2021 0]

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

[Olli73 4]

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?

 

[ap2021 0]

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.

[Angus Robertson 574]

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

 

[Olli73 4]

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

[ap2021 0]

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!

[ap2021 0]

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.

[Angus Robertson 574]

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

[Angus Robertson 574]

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