Smtp avoid spam classification

[chkaufmann 17]

Hi,

my provider uses https://rspamd.com/ to check emails before sending out. Now my emails get classified by some modules and I would like to solve this:

 

One is https://rspamd.com/doc/modules/chartable.html

 

Normally I just add text with FMessage.Body.Add() and then I set this:

 

FMessage.ContentType := 'text/plain';
FMessage.CharSet := 'UTF-8';
 

Is Indy not doing the conversion correctly?

 

The second one is https://www.rspamd.com/doc/modules/mime_types.html this one. The others don't give a big score:

 

R_MIXED_CHARSET        2.89     Mixed characters in a message
MISSING_MIME_VERSION   2.00     MIME-Version header is missing in MIME message
R_BAD_CTE_7BIT         1.05     Detects bad content-transfer-encoding for text parts 7bit;utf8;
 

Can somebody give me a hint on how to fix this?

 

Christian

 

[Remy Lebeau 1421]

11 minutes ago, chkaufmann said:

my provider uses https://rspamd.com/ to check emails before sending out. Now my emails get classified by some modules and I would like to solve this:

It is hard to diagnose your issue without seeing the raw email data, and/or your code that is creating the email, and even knowing which version of which Pascal compiler you are using (Delphi vs FreePascal), since string handling varies by compiler and even by version.

11 minutes ago, chkaufmann said:

Normally I just add text with FMessage.Body.Add() and then I set this:

 

FMessage.ContentType := 'text/plain';
FMessage.CharSet := 'UTF-8';
 

Is Indy not doing the conversion correctly?

I can't answer that with the limited details you have provided so far.  For instance, if you are using a Unicode version of Delphi (2009+ or later) or FreePascal (3.0+ with UnicodeStrings enabled), then yes, it should be converting to UTF-8 property.  But if you are using a pre-Unicode version of Delphi/FreePasscal, then no, it will not convert to UTF-8 automatically, so you are responsible for encoding your own strings to UTF-8 before giving them to Indy.

11 minutes ago, chkaufmann said:

R_MIXED_CHARSET        2.89     Mixed characters in a message

What does your actual text look like?  This score implies that you have a lot of script changes happening inside of individual words.  Which might just be a side effect of UTF-8 not being encoded properly.  Hard to say without seeing the raw data.

11 minutes ago, chkaufmann said:

MISSING_MIME_VERSION   2.00     MIME-Version header is missing in MIME message

What do you have the TIdMessage.Encoding property set to?  It is set to meDefault by default, which will be auto-updated to either mePlainText or meMIME depending on whether the TIdMessage.MessageParts collection is empty or not, respectively.  A 'MIME-Version' header is generated only when TIdMessage.Encoding is meMIME.  In general, you don't need to use MIME if your email contains only plain text, but it sounds like the provider may be requiring MIME.  So, you may need to force the TIdMessage.Encoding to meMIME.

11 minutes ago, chkaufmann said:

R_BAD_CTE_7BIT         1.05     Detects bad content-transfer-encoding for text parts 7bit;utf8;

UTF-8 is an 8-bit encoding, so it requires a transfer encoding that supports 8-bit data.  '7bit' will truncate/zero the high bit of each byte, thus corrupting non-ASCII characters.  So, you need to set the TIdMessage.ContentTransferEncoding property (and the TIdMessagePart.ContentTransfer property in entries of the TIdMessage.MessageParts collection) to either '8bit', 'base64', or 'quoted-printable' when using UTF-8 text to avoid any potential data loss.  Note that '8bit' emails do require additional support from an SMTP server (features which Indy does not currently implement), so use 'base64' or 'quoted-printable', which are compatible with 7-bit systems.  If the text is mostly ASCII characters, I would use 'quoted-printable'.  If the text is mostly non-ASCII characters, I would use 'base64' instead.