Add notifier driver: `email` (SMTP)
- Dominant language
- Rust
- Stars
- 3
- Forks
- 1
- Avg merge
- 4h 50m
- Merged PRs (30d)
- 1
Description
For environments without Slack/Discord/Telegram (regulated industries, internal corporate tooling, family-shared homelab), email is still the lingua franca. dotagent has no email notifier.
## Proposal
A new in-process driver `email` that sends via SMTP.
Manifest shape:
```toml
[[notifiers]]
driver = "email"
smtp_host = "smtp.fastmail.com"
smtp_port = 587
username = "${SMTP_USER}"
password = "${SMTP_PASS}"
from = "dotagent@example.com"
to = ["me@example.com"]
tls = "starttls" # starttls | implicit | none
```
The driver opens an SMTP connection, sends a single message per notification event, and closes. No persistent connection — keep state minimal.
## Acceptance criteria
- [ ] Sends a multipart message with plain-text body. HTML optional.
- [ ] STARTTLS and implicit-TLS both work; plain SMTP is allowed only for `smtp_host = "localhost"` (warn otherwise).
- [ ] Auth methods: PLAIN, LOGIN (cover what self-hosted SMTP servers commonly need).
- [ ] Credentials never logged.
- [ ] Connection timeout configurable, default 10s.
- [ ] Doc page + example with a known provider (Fastmail, Postmark, Mailgun) in the example.
## Where to start
- `crates/dotagent-notify/src/lib.rs` — driver registration.
- `lettre` is the canonical SMTP crate in the Rust ecosystem (evaluate maintenance, MSRV).
- `[security]` `network` field allow-list integration.
## Non-goals
- DKIM signing. Out of scope; let the SMTP server handle it.
- Inline images / rich HTML templates. Plain-text + minimal HTML is enough.
- IMAP / receiving. Out of scope.
Contributor guide
Research direction
Start in crates/dotagent-notify/src/lib.rs by inspecting driver registration and existing notifier implementations. Then evaluate the lettre crate's maintenance and MSRV, and trace the [security] network allow-list integration. Done means SMTP delivery, TLS modes, supported authentication, timeout and credential-safety behavior meet the acceptance criteria, with a documentation example for a named provider.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend, documentation, networking, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100