feat(dpi): add SMTP protocol detection and metadata extraction

[0xghost42]

Summary

Adds best-effort Deep Packet Inspection for the plaintext SMTP control channel (RFC 5321, RFC 1869 ESMTP, RFC 3207 STARTTLS, RFC 4954 AUTH). Once STARTTLS upgrades the channel, subsequent bytes are TLS and will be claimed by the HTTPS/TLS analyzer.

Tracks the DPI Enhancements roadmap item for SMTP.

What it does

Detection

• Ports 25 (SMTP), 465 (SMTPS), 587 (submission), 2525 (alternative), plus a cheap signature for non-standard ports.
• Server response: 3-digit reply code followed by space or - (continuation marker).
• Client request: known verb set (HELO, EHLO, MAIL, RCPT, DATA, RSET, NOOP, QUIT, VRFY, EXPN, HELP, STARTTLS, AUTH, BDAT, ETRN), case-insensitive, length-capped.

Extracted metadata

• Command + argument (EHLO client.example.org, AUTH PLAIN ..., …).
• Response code + message (250-mail.example.com Hello, 354 End data with …).
• Envelope sender from MAIL FROM:<addr> — surfaced as sender.
• Envelope recipient from RCPT TO:<addr> — surfaced as recipient.
• Server software extracted from the 220 greeting / 250 EHLO reply (e.g. Postfix).

Surfaces

• New ApplicationProtocol::Smtp(SmtpInfo) variant with a Display formatter tuned for the connection-table column (envelope hops show SMTP MAIL <alice@example.com>; greetings show SMTP 220 (Postfix)).
• DPI details panel in the TUI renders message type, command, arguments, response code, response message, envelope sender, envelope recipient, server software.
• ConnectionFilter general search matches smtp, command, sender, recipient, server software, and response code.
• Per-protocol merge keeps stable identity fields (sender, recipient, server_software) first-wins and dialog state latest-wins, mirroring how an SMTP session unfolds across many request/response pairs.

Tests

11 new unit tests in `src/network/dpi/smtp.rs`:

• Server greeting (`220 mail.example.com ESMTP Postfix`).
• EHLO multi-line continuation response.
• EHLO client request.
• `MAIL FROM:alice@example.com` envelope sender extraction.
• `RCPT TO: bob@example.org` envelope recipient extraction (whitespace tolerant).
• `STARTTLS` request.
• `354 End data with …` DATA prompt — software extraction not triggered for non-banner codes.
• Lowercase command accepted.
• HTTP payload rejected.
• Unknown verb rejected.
• Truncated / short payload rejected.

Full suite locally on macOS / Apple Silicon:

• `cargo test --all-features` → 335 passed, 0 failed.
• `cargo clippy --all-features --all-targets -- -D warnings` → clean.
• `cargo fmt --all -- --check` → clean.

Files touched

• `src/network/dpi/smtp.rs` — new module.
• `src/network/dpi/mod.rs` — register module, add `PORT_SMTP` / `PORT_SMTPS` / `PORT_SMTP_SUBMISSION` / `PORT_SMTP_ALT`, dispatch SMTP after HTTP.
• `src/network/types.rs` — `SmtpInfo`, `SmtpMessageType`, enum variant, `Display` arm, `sort_key`, dist counter, UDP state sentinel, idle timeout.
• `src/network/merge.rs` — `merge_smtp_info` (stable fields first-wins, dialog state latest-wins).
• `src/filter.rs` — general-search match arm for SMTP metadata.
• `src/ui.rs` — DPI details panel rendering for SMTP.

Test plan

• Unit tests pass locally on macOS (Apple Silicon).
• Live smoke against an SMTP server (recommended for the maintainer; I do not have an SMTP relay handy on this machine).

[domcyrus]

@0xghost42 thanks for the PR. Before merging I want to take a bit more time to think about whether SMTP DPI is the right addition for RustNet, and I would also like to hear from other users.

My main hesitation is around how much plaintext SMTP traffic RustNet would actually see in practice. Modern mail clients use submission on port 587 (STARTTLS-upgraded almost immediately) or SMTPS on 465 (implicit TLS from the first byte). The realistic plaintext window is server-to-server on port 25 before STARTTLS upgrade, which is useful for people running mail servers but not for typical end-user setups.

So the open question is whether enough RustNet users actually want SMTP visibility to justify the maintenance surface. If you (or anyone reading this) run a mail server or otherwise have a use case for this, please leave a note here so I can gauge demand. I will keep the PR open in the meantime.

I appreciate the work, but I want to think it through before merging.

[0xghost42]

@domcyrus thanks for thinking it through publicly. Adding some concrete use cases in case they shift the cost / benefit:

Plaintext SMTP visibility is still useful for:

• Mail-server operators on port 25 (MTA ↔ MTA). Server-to-server SMTP between MTAs still routinely traverses port 25 in cleartext before opportunistic STARTTLS. RustNet running on a relay or outbound MX would surface MAIL FROM / RCPT TO / response codes for deliverability debugging — which mailbox provider rejected, with which 5xx code — without needing to dig through Postfix / Exim logs.

• Internal mail / monitoring agents. Plenty of internal pipelines still send mail via plaintext SMTP on 25 over the local network: cron mailers, log shippers, monitoring agents (Nagios / Icinga / smartmontools / mdadm), cron job output, and lots of legacy embedded devices. RustNet operators investigating "why is this box sending mail at 3am" would benefit from seeing the SMTP envelope without spinning up tcpdump + a parser.

• STARTTLS upgrade visibility before the encryption kicks in. Even on submission port 587, the EHLO exchange + STARTTLS command + 220 2.0.0 Ready to start TLS response are plaintext. Surfacing those handshake lines in the details panel would let users confirm "this client does STARTTLS" vs "this client never upgrades" — useful for finding misconfigured legacy clients still sending mail in cleartext.

• Security audits / honeypots / detection labs. Anyone running cowrie, opencanary, mailpit, MailHog, or a custom mail honeypot wants the inbound MAIL FROM / RCPT TO and AUTH attempts visible at the network layer, not just in the trap's own logs. Same for incident responders looking at a compromised box phoning home over port 25.

• Submission port 587 in dev / staging. Plenty of staging setups disable STARTTLS to make local debugging easier; rustnet would render those exchanges directly.

If the maintenance worry is mainly about the parser surface, happy to keep the scope tight: command + response code + first response message + the sender / recipient hint from MAIL FROM / RCPT TO. No body / DATA inspection, no authentication-secret extraction (AUTH PLAIN payload deliberately not decoded), and detection still gates on EHLO / HELO / 220 reply + port 25/587 — i.e. the smallest plausible footprint, comparable to what landed for FTP in #266.

I'll let this sit and see if other users chime in. Happy either way — close it if the maintenance surface still doesn't pencil out for you.