mailforge

Quick Start

Install via jcli (recommended)

jcli install mailforge

If you don't have jcli yet, install it first with curl -fsSL https://cli.johlem.net/tools/jcli/install.sh | bash.

Or install directly

curl -fsSL https://cli.johlem.net/tools/mailforge/install.sh | bash

This drops a single Rust binary at ~/.local/bin/mailforge and verifies its SHA-256 (and Ed25519 signature, if signify is installed).

Generate per-recipient tracking pixels

mailforge beacon gen \
  --to alice@target.com,bob@target.com \
  --from noreply@example.com \
  --from-name "IT Help Desk" \
  --company "Target Corp" \
  --base https://t.example.com \
  --template password-reset \
  --allow-domain target.com \
  --engagement-id RT-2026-04 \
  --authorized-by "Jane Client" \
  --out-dir ./eml

Run the open-tracking callback server

mailforge beacon serve \
  --listen 0.0.0.0:8080 \
  --log ./opens.jsonl \
  --engagement-id RT-2026-04

Report on captured opens

mailforge beacon report ./opens.jsonl
mailforge beacon report ./opens.jsonl --output markdown
mailforge beacon report ./opens.jsonl --output json --out-file report.json

Offensive SPF / DMARC posture check

mailforge spoof check example.com
mailforge spoof lookalikes paypal.com

OSINT email harvesting

mailforge harvest crt-sh target.com
mailforge harvest wayback target.com --limit 50
mailforge harvest pattern target.com --names-file ./names.txt

What it does

mailforge consolidates the originally-planned six standalone red-team mail tools under one binary. Each subcommand shares the same engagement context, AUTHORIZED gate, HMAC token signer, operator secret store, evidence directory, and output formatter. One engagement uses one secret, one auth audit trail, one evidence tree.

• One unified binary. Beacon + landing + bench + spoof + harvest + spin all behind mailforge <subcommand>.
• Engagement-mandatory gates. Every output-producing subcommand refuses to run without --engagement-id and --authorized-by. Domain scope enforced by --allow-domain.
• HMAC-SHA256 tokens. Tracking pixels carry per-recipient tokens verified server-side; no cleartext recipient in URLs.
• AES-256-GCM credential encryption. Capture files (landing-page form submissions etc.) encrypted at rest with PBKDF2 600k-iter passphrase key.
• Pipe-clean output. Every command supports --output {json,csv,markdown} and -O/--out-file for stable scripting / SIEM ingest.

Subcommands

Pretext templates (beacon)

Eight pretexts ship embedded with MITRE ATT&CK mapping in the slug label. Operators select with --template <slug>.

On-disk layout

~/.local/bin/mailforge       # the static binary itself
~/.local/bin/mailforge.bak   # previous version (rollback target)
~/.mailforge/secret          # 32-byte HMAC secret (chmod 600, auto-init from /dev/urandom)
~/.local/share/mailforge/    # per-tool data dir (catalogues, state)

MAILFORGE_HOME overrides the secret-store location so each engagement can scope into its own secret (separate engagements should not share secrets).

Design choices

• Unified, not modular distribution. One binary, not six. The shared gate / secret / output / signature infrastructure is too valuable to fragment.
• No SMTP send built into beacon. Generates .eml; delivery is through the operator's own authorised mail server (msmtp / swaks / engagement relay). Decouples message authorship from sending infra.
• No TLS termination on the servers. Both beacon serve and land serve are HTTP-only — wrap with caddy / nginx for TLS. Keeps the binary small and rotates secrets via reverse-proxy config.
• Mandatory engagement scope. A red-team binary that produces outbound material without an engagement reference is malware; we refuse before doing anything.