larksuite/cli · error

emlbuilder: EML size %.1f MB exceeds the %.0f MB limit

Error message

emlbuilder: EML size %.1f MB exceeds the %.0f MB limit

What it means

Build() enforces MaxEMLSize; when the fully serialized EML exceeds the limit it returns this error instead of producing an oversized message that the mail API would reject. The error reports both the actual size in MB and the configured limit in MB. Wrapped into a typed ValidationError by the mail command layer.

Source

Thrown at shortcuts/mail/emlbuilder/builder.go:761

		outerB := newBoundary()
		writeHeader(&buf, "Content-Type", "multipart/mixed; boundary="+outerB)
		buf.WriteByte('\n')

		fmt.Fprintf(&buf, "--%s\n", outerB)
		writePrimaryBody(&buf, b)

		for _, att := range b.attachments {
			fmt.Fprintf(&buf, "--%s\n", outerB)
			writeAttachmentPart(&buf, att)
		}
		fmt.Fprintf(&buf, "--%s--\n", outerB)
	} else {
		writePrimaryBody(&buf, b)
	}

	raw := buf.Bytes()
	if len(raw) > MaxEMLSize {
		return nil, fmt.Errorf("emlbuilder: EML size %.1f MB exceeds the %.0f MB limit", //nolint:forbidigo // intermediate EML builder error; mail command layer wraps into typed ValidationError.
			float64(len(raw))/1024/1024, float64(MaxEMLSize)/1024/1024)
	}
	return raw, nil
}

// BuildBase64URL returns the EML encoded as base64url (RFC 4648).
// This is the value to place in the Lark API "raw" field.
func (b Builder) BuildBase64URL() (string, error) {
	raw, err := b.Build()
	if err != nil {
		return "", err
	}
	return base64.URLEncoding.EncodeToString(raw), nil
}

// ── internal helpers ──────────────────────────────────────────────────────────

// copySlices returns a shallow copy of b with independent slice headers,

View on GitHub (pinned to 7fd6ef3c07)

Solutions

1. Reduce the number or size of attachments; remove non-essential ones.
2. Upload large files via Drive/cloud links instead of embedding them as attachments.
3. Compress or resize attachments (e.g. images to jpeg/webp, zip archives where allowed) before adding them.
4. Check the estimated size in the application (sum of base64-encoded parts) before Build() and split into multiple messages.

Example fix

// before
b.AddFileAttachment("video-raw-4k.mp4") // 60 MB -> serialized EML exceeds limit
// after
link := uploadToDrive("video-raw-4k.mp4")
b.AddFileAttachment("link.txt") // or share the Drive link in the body

const maxEML = 25 << 20 // match MaxEMLSize
var total int
for _, a := range attachments {
    total += len(a.data) + len(a.data)/2 + 1024 // approximate base64 expansion
}
if total > maxEML {
    return fmt.Errorf("attachments (%d MB) would exceed the EML limit; use Drive links", total>>20)
}

raw, err := b.Build()
if err != nil {
    var verr *ValidationError
    if errors.As(err, &verr) && strings.Contains(err.Error(), "exceeds the") {
        return fmt.Errorf("message too large: %w", verr)
    }
    return err
}

When it happens

Trigger: Calling Build() after attaching many/large files or very large bodies such that the serialized raw EML byte length exceeds MaxEMLSize (reported as MB in the message).

Common situations: Attaching several large attachments (videos, datasets, high-res images) to one email; inlining many base64-encoded images; base64 expansion (~+33%) pushing a just-under-limit payload over the cap.

Understand the failure class

Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.

Related errors

• emlbuilder: header value contains dangerous Unicode characte
• emlbuilder: header name contains ':', CR, or LF: %q
• emlbuilder: header name contains non-printable character: %q
• emlbuilder: display name contains CR or LF: %q
• emlbuilder: content ID contains control character: %q

AI-assisted analysis of larksuite/cli@7fd6ef3c07 (2026-09-04). Data as JSON: /api/errors/cf4efec9f19cb914. Report an issue: GitHub.