mailhook

The project uses GitHub Issues as its issue tracker for individual bug reports and feature requests: https://github.com/izm1chael/mailhook/issues

No vulnerability reports have been received or resolved in the last 12 months (project released May 2026).

SECURITY.md documents the full vulnerability response process: reports go to GitHub Security Advisories (private), acknowledgement within 48 hours, resolution plan within 14 days. URL: https://github.com/izm1chael/mailhook/blob/main/SECURITY.md

CONTRIBUTING.md identifies the coding style guides: gofmt for formatting, go vet for static analysis, gosec for security linting, and standard Go community conventions. URL: https://github.com/izm1chael/mailhook/blob/main/CONTRIBUTING.md

CI automatically enforces coding standards on every push and pull request: go vet ./... and gosec are required steps in the security job and must pass before any merge. URL: https://github.com/izm1chael/mailhook/blob/main/.github/workflows/ci.yml

The build is reproducible: -trimpath removes all local file system paths from the binary, CGO_ENABLED=1 with pinned libyara-dev version produces deterministic output, and no build-time timestamps are embedded. The same source + toolchain produces bit-for-bit identical binaries

The project provides five installation methods using standard conventions: Docker Compose (docker compose up), Debian/Ubuntu .deb package (apt install), RHEL/Fedora .rpm package (dnf install), a bare binary download, and build from source (go build). URL: https://github.com/izm1chael/mailhook/blob/main/README.md#installation-and-deployment

The project does not use a POSIX make install system. Package installation is handled by the .deb/.rpm package managers which use standard system paths by convention.

All Go dependencies are listed in machine-readable form in app/go.mod and pinned to exact versions in app/go.sum. URL: https://github.com/izm1chael/mailhook/blob/main/app/go.mod

External dependencies are monitored automatically: govulncheck cross-references all Go dependencies against the Go vulnerability database on every CI run and every release; trivy scans for HIGH/CRITICAL CVEs in dependencies before each release. Dependabot is configured to open weekly PRs for Go module and GitHub Actions updates. URL: https://github.com/izm1chael/mailhook/blob/main/.github/dependabot.yml

All Go dependencies are managed via Go modules and can be updated with go get -u and go mod tidy. Dependabot automatically opens pull requests for available updates on a weekly schedule. No vendored copies or embedded dependency snapshots are used.

GitHub Actions runs the full test suite (go test ./...) on every push to main and every pull request via ci.yml. The workflow produces a pass/fail report visible on the commit and PR. The matrix covers both amd64 and arm64 runners. URL: https://github.com/izm1chael/mailhook/blob/main/.github/workflows/ci.yml

No bugs have been fixed since the initial release — there are no prior bug-fix commits to measure against.

gosec suppressions are kept to a minimum and annotated inline with #nosec Gxxx and a justification comment. The G104 exclusion (unhandled errors in HTTP/SSE writers) is explicitly justified in the workflow file. go vet has no suppressions.

The software implements multiple secure design principles: fail-closed verdicts (quarantine when a critical scanner is unavailable), defence-in-depth (five independent scanning engines), least privilege (IMAP connections request only IDLE capability), SSRF prevention (custom dialer blocking RFC-1918 ranges), nonce-based CSP with no unsafe-inline, CSRF token protection, and AES-256-GCM encryption of all stored secrets. URL: https://github.com/izm1chael/mailhook/blob/main/README.md#security-model

No algorithms with known serious weaknesses are used for security functions. SHA-256 is used for hashing, AES-256-GCM for authenticated encryption, and bcrypt for password storage. TLS 1.2 minimum enforced on all IMAP connections.

All authentication credentials and private keys are stored in environment variables and the config file, entirely separate from application code and the database. Credentials can be rotated by updating the environment variable or config file and restarting the service — no recompilation required. The encryption key (MAILHOOK_ENCRYPTION_KEY) and admin password hash (MAILHOOK_ADMIN_PASSWORD_BCRYPT) are independently updatable

All network communication uses secure protocols: IMAP connections enforce TLS 1.2 minimum (MinVersion: tls.VersionTLS12) with per-account opt-in for self-signed certs (warned in logs); the web dashboard is served over plain HTTP locally and documented to require a TLS-terminating reverse proxy in production; all external API calls (VirusTotal, AbuseIPDB, MalwareBazaar) use HTTPS exclusively.

All IMAP connections set MinVersion: tls.VersionTLS12 in the tls.Config, enforcing TLS 1.2 as the minimum. TLS 1.0 and 1.1 are not negotiable. URL: https://github.com/izm1chael/mailhook/blob/main/app/imap/manager.go

TLS certificate verification is enabled by default for all IMAP connections. It can be disabled per-account via tls_skip_verify: true in the configuration, which is an explicit operator opt-in for self-signed certificates and is accompanied by a warning log at connection time. The default is always verify.

All inputs from untrusted sources are validated: email content is parsed via Go's net/mail package before scanning; web form inputs (allow/block list entries, settings) are validated server-side before persistence; IMAP server responses are parsed through the go-imap library which enforces RFC compliance; URL inputs are normalised and checked against allowlists before external requests are made. Invalid inputs are rejected with appropriate error responses.

Multiple hardening mechanisms are applied: Go's memory-safe runtime eliminates buffer overflows and use-after-free; per-request CSP nonces prevent XSS; CSRF tokens on all state-changing endpoints; bcrypt with rate-limited login prevents brute force; the binary is built with -trimpath to remove local path information; the release pipeline runs trivy to detect known CVEs in dependencies before shipping.

gosec is specifically designed to detect common Go security vulnerabilities including SQL injection, hardcoded credentials, weak crypto, SSRF, path traversal, insecure TLS, and unsafe use of os/exec. govulncheck cross-references all dependencies against the Go vulnerability database (CVE-backed). Both tools target vulnerability classes rather than general code quality.

MailHook is written in Go (a memory-safe language). While it uses CGO to call into libyara (a C library), that C code is produced and maintained by the YARA project, not by this project. The software produced by this project is Go code only.