Guard Mail Reply

Reply-thread shape validator for b.mail.agent.reply / b.mail.agent.forward. Composes b.guardMessageId (v0.9.19) for each Message-Id in the chain and adds reply-specific rules:

- References-chain cap — maxChainLength (default 100) defends infinite-loop forwards and References-bomb DoS - In-Reply-To continuity — when both inReplyTo and references are supplied, the last element of References must match In-Reply-To (RFC 5322 §3.6.4) - Quoted-original byte cap — when quotedOriginal is set, the byte cap defends pathological reply-of-reply chains that grow linearly with each hop - Forwarded-attachment cardinality — forwards may include the original's attachments by reference; cap at maxForwardedAttachments (default 32) to prevent attachment-bomb forwards

b.guardMailReply.validate(reply, opts?) #

{
  profile:   "strict" | "balanced" | "permissive",
  posture:   "hipaa" | "pci-dss" | "gdpr" | "soc2",
}

Validate a reply / forward envelope. reply.inReplyTo is the Message-Id of the parent; reply.references is the chain (oldest first); reply.quotedOriginal is the optional included original body (already redacted by the caller — guard validates byte cap only, not content).

b.guardMailReply.validate({
  inReplyTo:  "",
  references: ["", ""],
});

b.guardMailReply.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.guardMailReply.compliancePosture("hipaa");                   // → "strict"
b.guardMailReply.compliancePosture("not-a-regime");            // → null

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