If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/rnwood/smtp4dev shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 5d ago
• 5 active contributors
• BSD-3-Clause licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 69% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live rnwood/smtp4dev repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/rnwood/smtp4dev.

What it runs against: a local clone of rnwood/smtp4dev — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in rnwood/smtp4dev | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-3-Clause | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 35 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of rnwood/smtp4dev. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/rnwood/smtp4dev.git
#   cd smtp4dev
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of rnwood/smtp4dev and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "rnwood/smtp4dev(\\.git)?\\b" \\
  && ok "origin remote is rnwood/smtp4dev" \\
  || miss "origin remote is not rnwood/smtp4dev (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-3-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-3-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-3-Clause" \\
  || miss "license drift — was BSD-3-Clause at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 35 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~5d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/rnwood/smtp4dev"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

smtp4dev is a lightweight, cross-platform fake SMTP server for development and testing that captures outbound emails without actually sending them. Built on .NET (C# 3.9MB codebase), it provides a web UI (Vue 267KB) and terminal UI for inspecting emails, with advanced features like IMAP/POP3 access, message relay rules, HTML validation, and TLS/SSL support with auto-generated certificates. Hybrid monorepo: C# backend in Rnwood.Smtp4dev/ with controllers and services; Vue 3 + TypeScript frontend in Rnwood.Smtp4dev/ClientApp/; separate desktop wrapper in Rnwood.Smtp4dev.Desktop/; comprehensive test projects (Rnwood.Smtp4dev.Tests/, Rnwood.Smtp4dev.Desktop.Tests/) using xUnit-style patterns. Docker builds and dev containers (.devcontainer/Dockerfile) support local development.

Full-stack and backend developers building applications that send emails (registration confirmations, password resets, marketing campaigns) who need to test email functionality locally without spamming real users or setting up a complex email test infrastructure.

Actively maintained and production-ready. The codebase is substantial (3.9MB C#, comprehensive test suite in Rnwood.Smtp4dev.Tests/, CI/CD workflows in .github/workflows/), with multiple Docker targets (linux, windows variants), versioning via GitHub releases, and cross-platform support. This is a mature v3+ redesign (v2 was Windows-only).

Low risk. Single-maintainer repository (rnwood) but with CLA.md and contribution guidelines suggesting community involvement. Large dependency footprint in package.json (element-plus, vue-router, @microsoft/signalr, @fortawesome, jest, ts-jest, vite) increases maintenance burden. No obvious blockers—architecture is stable with .NET 10 as target.

Active development visible in workflow files (PR title checks, CLA enforcement, winget packaging, release automation). The presence of .devcontainer/ suggests recent push for dev environment standardization. Terminal UI mode and scripting expressions with error simulation represent recent feature additions mentioned in README.

git clone https://github.com/rnwood/smtp4dev.git && cd smtp4dev && dotnet restore && dotnet build. For frontend: cd Rnwood.Smtp4dev/ClientApp && npm install && npm run dev (Vite dev server on 127.0.0.1). Use .devcontainer/ for containerized setup via VS Code.

Daily commands: Backend: dotnet run --project Rnwood.Smtp4dev/Rnwood.Smtp4dev.csproj. Frontend dev: cd Rnwood.Smtp4dev/ClientApp && npm run dev (Vite watches on 127.0.0.1:5173 by default, proxies to backend). Desktop app: dotnet run --project Rnwood.Smtp4dev.Desktop/Rnwood.Smtp4dev.Desktop.csproj.

• Rnwood.Smtp4dev/ClientApp/package.json: Defines all frontend dependencies (Vue 3, Element Plus, Vite, SignalR) and build scripts; critical for understanding frontend toolchain and testing setup (jest, ts-jest, @vue/vue3-jest).
• Rnwood.Smtp4dev.Tests/Controllers/MessagesControllerTests.cs: Demonstrates the test pattern for API endpoints and shows how message handling is validated; blueprint for adding new feature tests.
• .devcontainer/devcontainer.json: Defines the containerized dev environment with extensions, ports, and setup scripts; essential for onboarding new contributors.
• Rnwood.Smtp4dev/ClientApp/src: Root of Vue application (implied by structure); contains all frontend components, stores, and routing logic.
• Rnwood.Smtp4dev.Tests/DBMigrations/TimezoneConvertMigrationTests.cs: Shows database migration testing patterns and timezone-aware data handling, critical for data model changes.
• .github/workflows: CI/CD automation: PR validation, CLA checks, release packaging, winget distribution; understand the automated testing and deployment pipeline.
• [Dockerfile.linux & Dockerfile.linux.arm64](https://github.com/rnwood/smtp4dev/blob/master/Dockerfile.linux & Dockerfile.linux.arm64): Production deployment templates for containerized SMTP server; shows multi-arch support and final app configuration.

Protocol handling: check Rnwood.Smtp4dev/ for SMTP/IMAP/POP3 server code. REST API endpoints: Rnwood.Smtp4dev.Tests/Controllers/ shows test patterns for MessagesController, ServerController, RelayMessage logic. UI components: Rnwood.Smtp4dev/ClientApp/ (Vue SFCs). Database schema: Rnwood.Smtp4dev.Tests/DBMigrations/ shows migration patterns and timezone handling. Add tests in respective Test projects using xUnit conventions.

No obvious required environment variables in visible config, but .devcontainer/installcustom.sh suggests toolchain setup may have platform-specific steps. Database migrations (Rnwood.Smtp4dev.Tests/DBMigrations/) imply EF Core schema management—ensure migrations run before first app run. Vue frontend dev server at 127.0.0.1:5173 requires explicit host binding (seen in package.json 'dev' script) for Docker scenarios. SignalR WebSocket connections from browser to backend need CORS configuration (not visible in snippet but likely in Startup.cs or appsettings.json). TLS/SSL auto-cert generation may fail in restricted network environments.

• SMTP Protocol Handling — smtp4dev's core function is receiving and storing emails via SMTP; understanding RFC 5321 (SMTP) and RFC 5322 (message format) is essential for adding server features, auth, or relay rules.
• IMAP and POP3 Protocols — smtp4dev uniquely offers IMAP and POP3 access to retrieve messages; implementing or debugging these protocols requires RFC 3501 (IMAP) and RFC 1939 (POP3) knowledge.
• TLS/SSL Handshake & Self-Signed Certificates — Auto-generated certificate feature requires understanding X.509, certificate generation APIs, and TLS negotiation in .NET (System.Net.Security namespace).
• SignalR Real-Time Bidirectional Communication — Frontend receives live email updates via SignalR (@microsoft/signalr dependency); understanding hubs, connection lifecycle, and reconnection logic is needed for UI state management.
• MIME Multipart Message Parsing — Email messages contain complex MIME structures (text, HTML, attachments, inline images); the MIME parts inspector feature requires parsing and traversing these hierarchies correctly.
• Entity Framework Core Migrations — Rnwood.Smtp4dev.Tests/DBMigrations/ shows the project uses EF Core for schema versioning; new features requiring database changes must follow migration patterns to maintain backward compatibility.
• Terminal User Interface (TUI) Frameworks — Full-featured TUI mode is a key differentiator; implementing or extending TUI requires understanding terminal control codes, asynchronous input handling, and screen buffer management (specific library inferred but not visible in snippet).

• mailhog/MailHog — Direct competitor offering similar fake SMTP + web UI in Go; smtp4dev's README explicitly compares features against it.
• maildev/maildev — Node.js-based alternative with web UI and REST API; targets same use case but different tech stack; mentioned in README comparison.
• sj26/mailcatcher — Ruby-based predecessor that inspired fake SMTP server category; smtp4dev improves on its basic feature set as shown in comparison table.
• dotnet/aspnetcore — Core dependency—smtp4dev is built on ASP.NET Core; understanding core framework internals helps with server architecture and SignalR real-time updates.
• vuejs/vue — Frontend framework dependency (v3.2.13); users contributing UI features need Vue 3 Composition API and SFC patterns.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add E2E tests for SMTP Authentication and TLS/SSL modes

The repo has comprehensive E2E tests in Rnwood.Smtp4dev.Tests/E2E/ for IMAP, POP3, and WebUI, but no dedicated E2E tests for SMTP authentication flows or TLS/SSL connection modes (implicit vs STARTTLS). Given that the README highlights 'TLS/SSL with implicit and STARTTLS modes and auto self-signed cert generation' and 'Authentication' as key features, these critical paths lack automated test coverage. This would catch regressions in security-sensitive code.

• [ ] Create Rnwood.Smtp4dev.Tests/E2E/Smtp/E2ETests_SmtpAuthentication.cs to test AUTH LOGIN, AUTH PLAIN with valid/invalid credentials
• [ ] Create Rnwood.Smtp4dev.Tests/E2E/Smtp/E2ETests_SmtpTls.cs to test implicit TLS, STARTTLS upgrade paths, and certificate validation
• [ ] Add test cases for mixed scenarios: TLS + Authentication, invalid cert handling
• [ ] Ensure tests follow the pattern in E2ETests.cs using the test collection fixtures (E2ECollection.cs, E2ETestCollection.cs)

Add unit tests for ClientApp Vue components and TypeScript utilities

The package.json shows Jest is configured ('test': 'jest') with @vue/vue3-jest, @types/jest, and ts-jest, but the file structure shows no existing test files in Rnwood.Smtp4dev/ClientApp/src/. Given the complexity of features like 'Multipart MIME inspector', 'HTML validation', 'viewport size switcher', and 'scripting expressions', the frontend lacks unit test coverage. This is a high-value contribution that improves reliability of the web UI.

• [ ] Create Rnwood.Smtp4dev/ClientApp/src/tests/ directory structure
• [ ] Add tests for core Vue components (e.g., message viewer, MIME inspector, HTML validator components)
• [ ] Add tests for TypeScript utilities (e.g., sanitization logic using sanitize-html, CSS tree parsing with css-tree)
• [ ] Configure Jest to work with Vue 3, TypeScript, and Vite (jest.config.ts or update existing config)

Add GitHub Actions workflow for cross-platform Docker image builds and registry pushes

The repo maintains multiple Dockerfiles (Dockerfile.linux, Dockerfile.linux.arm64, Dockerfile.windows.ltsc2019, Dockerfile.windows.ltsc2022) but the .github/workflows/ directory only shows cla.yml, cleanup-releases.yml, pr-title-check.yml, rebase.yml, and winget-stable.yml. There's no automated Docker build workflow that builds, tests, and pushes multi-arch images to registries (Docker Hub, GHCR). This is critical for a tool distributed as Docker images, ensuring consistency and reducing manual release burden.

• [ ] Create .github/workflows/docker-build.yml that triggers on tags/releases and pushes
• [ ] Configure docker/setup-buildx-action@v3 for multi-platform builds (linux/amd64, linux/arm64, windows/ltsc2019, windows/ltsc2022)
• [ ] Add build matrix to test all Dockerfiles; use docker/build-push-action@v5 with appropriate tags
• [ ] Integrate with existing winget-stable.yml and cleanup-releases.yml patterns for consistency

• Add unit tests for database migration helpers in Rnwood.Smtp4dev.Tests/DBMigrations/Helpers/ (FakeLocalTimeZone.cs, SqliteInMemory.cs) which lack dedicated test files—these are critical infrastructure utilities.
• Expand MessagesControllerTests.cs with tests for relay rules and mailbox routing logic mentioned in README features but not visible in test files; cross-reference RelayMessageTests.cs for patterns.
• Create frontend component tests for the HTML compatibility report viewer and MIME parts inspector UI (Rnwood.Smtp4dev/ClientApp/) using existing jest + @vue/vue3-jest setup but missing .spec.ts files in most feature areas.

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.