Skip to main content

meMIME

meMIME = 1

Example​

procedure ConfigureMIMELayout(Message: TIdMessage);
begin
  Message.Encoding := meMIME;
  Message.CharSet := 'utf-8';

  { Add the required text and attachment MessageParts next. }
end;

Usage​

meMIME selects Velox's MIME message layout with MIME headers, boundaries and encoded message parts.

Additional Technical Info​

meMIME is the TIdMessageEncoding member for MIME message layout. It controls how Indy organizes the whole message; CharSet, whole-body ContentTransferEncoding and each part's transfer encoding remain separate decisions.

The example selects MIME layout and a character set before parts are built. It is source-reviewed and is not executed by the documentation workflow.

Assignment side effect

Setting Encoding := meMIME stores the enum and immediately sets AttachmentEncoding to MIME. This can overwrite an earlier attachment-encoder choice. Set a deliberate override afterwards.

Encoder lookup can raise after the enum has already been stored, so a failed assignment can leave Encoding = meMIME with attachment state only partly updated.

Header generation

For MIME layout, GenerateHeader performs stateful preparation that includes:

  • clearing the boundary stack and generating a new top-level MIME boundary;
  • inferring ContentType when it is blank;
  • initializing message-part headers through the selected message encoder;
  • setting MIME-Version: 1.0 on MIME output paths;
  • detecting the special one-part MIME case; and
  • normalizing nonempty, unrecognized part transfer values to base64.

The recognized part transfer values are 7bit, 8bit, binary, base64, quoted-printable and binhex40. Generation also clears a nonempty whole-body transfer value other than 7bit, 8bit or binary when message parts exist, because this implementation does not support attachments inside an encoded whole body.

Content-type inference

When ContentType is blank, current Indy source infers:

Parts summaryInferred content type
More than one text part, with attachmentsmultipart/mixed
More than one text part, no attachmentsmultipart/alternative
Zero or one text part, with attachmentsmultipart/mixed
Zero or one text part, no attachmentstext/plain

This is a structural heuristic, not semantic validation of the parts. Set ContentType and parent relationships deliberately for nested or specialized MIME structures.

Single-part MIME and Body

Indy marks a message as single-part MIME only when Encoding = meMIME, there is exactly one message part and Body is empty under its whitespace-only test. That path lets the part supply the message-level content headers. Otherwise Body can serve as a MIME preamble or be converted into a text part according to ConvertPreamble and the generation path.

Input behavior

ProcessHeaders selects meMIME solely when MIME-Version is present. A boundary or MIME-looking Content-Type without that header still selects mePlainText; conversely the header selects MIME even when the structure is incomplete. Changing Encoding after loading does not reparse Body or MessageParts.

Errors and interoperability

Header/part/charset encoder lookup, malformed part relationships, I/O and transport can fail after generation has mutated the message. MIME improves modern interoperability but does not by itself guarantee a valid multipart tree, correct charset, safe filenames or accepted attachment size.

Performance and concurrency

Generation walks and can mutate all parts and allocates a fresh boundary. Sending large encoded attachments adds stream/encoding cost. Do not generate or mutate the same message concurrently.

Related entries

External references

Created 2026-07-15