Guard Message-Id

RFC 5322 §3.6.4 Message-Id validator. Gates Message-Id / In-Reply-To / References header values at the entry to b.mailStore.appendMessage (v0.9.19), b.mail.server.mx (v0.9.23), and the outbound submission path (v0.9.25).

Refuses:

- oversized (default 998-byte cap per RFC 5322 §2.1.1 line cap) - bare CR / LF / NUL / C0 control chars (header-injection defense — defends From: / Bcc: smuggling via folded Message-Id continuation) - DEL (0x7F) anywhere - unbracketed under strict profile (the wire form per RFC 5322 §3.6.4 is — operator with legacy mail can opt down to balanced to accept bare tokens) - empty value - bidi codepoints in the local-part / domain (RFC 5322 + EAI allow non-ASCII per RFC 6532 + RFC 5335 but bidi-marker codepoints are operator-unfriendly and refused outright)

Profile vocabulary follows the existing guard-family convention:

- strict (default) — bracketed , length cap, no control chars, no bidi - balanced — accepts unbracketed tokens (legacy mail compat) - permissive — minimal validation (NUL + CR/LF refused; rest passes); use only for forensic-only flows

Posture vocabulary:

- hipaa / pci-dss / gdpr / soc2 — each pins the active profile to strict regardless of operator's profile opt; refuses to relax under regulated postures.

Composes the framework's existing guard-family pattern via b.gateContract (the same shape b.guardEmail / b.guardCsv / b.guardArchive use). Registers in b.guardAll's STANDALONE_GUARDS map.

b.guardMessageId.validate(value, opts?) #

{
  profile:    "strict" | "balanced" | "permissive",     // default "strict"
  posture:    "hipaa" | "pci-dss" | "gdpr" | "soc2",    // pins profile to strict
  maxBytes:   number,                                    // per-profile default
}

Validate a Message-Id / In-Reply-To / References header value. Returns the input value on success; throws GuardMessageIdError on refusal.

b.guardMessageId.validate("");
// → ""

try { b.guardMessageId.validate("abc@example.com"); }
catch (e) { e.code; }
// → "message-id/unbracketed" (strict profile)

b.guardMessageId.validateList(value, opts?) #

{
  profile:        same as validate
  posture:        same as validate
  maxBytes:       per-id cap
  maxIds:         number,    // default 100 — References-chain cap
}

Validate a Message-Id-list header value (References / In-Reply-To may carry multiple ids separated by whitespace per RFC 5322 §3.6.4). Returns the array of validated Message-Ids; throws on any single refusal.

b.guardMessageId.validateList("  ");
// → ["", "", ""]

b.guardMessageId.compliancePosture(name) #

Return the effective profile NAME for a compliance posture, or null for a name this parser does not map. Unlike the content-guard variant this returns the resolved profile string (every line-protocol parser composes gateContract.ALL_STRICT_POSTURES, so "hipaa" / "pci-dss" / "gdpr" / "soc2" all resolve to "strict") and never throws — the parser shape carries no overlay-clone, no buildProfile, and no loadRulePack. Wired by gateContract.defineParser.

b.guardMessageId.compliancePosture("hipaa");                   // → "strict"
b.guardMessageId.compliancePosture("not-a-regime");            // → null

Last updated 2026-08-08T16:39:49.652Z by seeder.