Sending raw MIME

When to send the message already built, and the four things we rewrite.

If you already have a system that builds messages, with attachments, embedded images and headers of your own, you can send them whole. The field is called raw.

curl -X POST https://app.c-connect.pt/v1/messages \
  -H "Authorization: Bearer $CCONNECT_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'JSON'
{
  "from": "receipts@mail.mycompany.com",
  "to": "somebody@example.org",
  "raw": "From: Receipts <receipts@mail.company.com>\r\nSubject: Your receipt\r\nMIME-Version: 1.0\r\nContent-Type: text/plain; charset=UTF-8\r\n\r\nThank you."
}
JSON

When raw is present nothing else is rendered: subject, text and html are ignored, and what arrives is what goes out.

What we rewrite

Four things, and nothing else. The body is never read.

Line endings become CRLF. A message built with \n would have its body hash computed over bytes no receiver ever sees, and would fail DKIM everywhere.
The Message-ID is replaced with ours. It is the same identifier the API gives you back, the same one the events carry, and the same one in the bounce envelope: it is what ties a bounce to its message without opening it.
The Date is rewritten in your account's time zone. A Date in the future, or far in the past, is a signal some filters use.
The DKIM signature is added, over the headers and the body as they ended up.

Everything else stays byte for byte. There is no MIME parser here rebuilding the message, precisely because rebuilding would lose whatever you did that we do not model.

What is refused

Situation	Why
No blank line after the headers	It is not a MIME message.
A header with no `:`	Same.
No `From`	We do not know who to sign for.
The `From` is at another domain	You can only send from a verified domain of yours.
Marketing with no `List-Unsubscribe`	See Unsubscribing.

List-Unsubscribe is refused rather than added, because adding it would mean inventing an unsubscribe URL on your behalf, and a one-click unsubscribe that unsubscribes nobody is worse than none.

Headers you should not set

Do not write DKIM-Signature, Return-Path or Received. The first two are ours, and the third is written by the servers the message passes through.

You can set Reply-To, References, In-Reply-To and your own X- headers. A correct In-Reply-To is what makes mail clients group a conversation, and it is worth having if you send automated replies.

Size

The raw field is limited to 25 MB, which is the practical limit at nearly every receiver. A message larger than that is not refused by us and is refused by them, which is worse, because it has already spent the attempt.

For large files, send a link rather than an attachment. It also avoids the message being refused for size at an intermediate server that is not even the final destination.