For a long time, TIdMessage would generate a “Message-ID” header if its MsgId property was not blank, but only when saving an email to a file, not when streamed or transmitted. Otherwise the MsgId was ignored and “Message-ID” was omitted.
However, many modern email servers will reject an outgoing email as spam if it does not have a client-generated “Message-ID” header, especially when sending a new email versus replying to another email. RFCs encourage clients to generate their own “Message-ID”, and many popular email clients (Outlook, Thunderbird, etc) do exactly that. And, Indy users have been asking for this ability. So, TIdMessage has been updated to always generate a “Message-ID” header if the MsgId property is not blank, regardless of whether the email is being saved, streamed, or transmitted. In a future release, TIdMessage may be updated further to auto-generate a “Message-ID” value if the MsgId property is blank.
Just know that if you reuse a TIdMessage object to create a reply email from another email, be sure to assign a new value to the MsgId property after copying the old value to the InReplyTo property, so else the reply will have the same “Message-ID” as the email being replied to.
Speaking of “In-Reply-To”, a logic change has been made for that header as well. For a long time, TIdMessage would always generate an “In-Reply-To” header if the InReplyTo property was blank but a “Message-ID” header was present (either from the MsgId or ExtraHeaders property), where the “Message-ID” value would be copied to the “In-Reply-To” header. However, when sending a new email, this confuses email servers, and can cause rejections as well. “In-Reply-To” should only be used in reply emails. So, TIdMessage has been updated to no longer generate an “In-Reply-To” header if the InReplyTo property is blank. When sending a reply email, you are now responsible for populating the InReplyTo property as needed.