Konzept

Eigenständiges Konzept — bewusst so geschrieben, dass es aus diesem Repo herausgezogen und als separates Projekt aufgesetzt werden kann. Es geht nicht um das Kontaktformular dieser einen Seite (das kommt später als kleiner Zwischenschritt), sondern um einen wiederverwendbaren Dienst für viele statische Webseiten.

1. Vision & Problem

Statische Seiten (Astro, Hugo, Eleventy …) sind schnell, sicher und günstig — aber sie können keine E-Mails versenden: kein Backend, kein Geheimnis, das im Browser sicher wäre. Jede statische Seite läuft früher oder später gegen dieselbe Wand: Kontakt-, Lead-, Bewerbungs- oder Bestellformulare.

Es gibt Drittdienste (Formspree, Web3Forms, Basin, Getform, Formsubmit), aber:

Daten laufen über einen Dritten, meist US-basiert → DSGVO-Reibung.
Wiederkehrende Kosten pro Seite, Vendor-Lock-in.
Wenig Kontrolle über Zustellung, Reputation, Aufbewahrung.

Ziel: Ein selbst gehostetes, DSGVO-sauberes Gateway, das viele Seiten gleichzeitig bedient. Einmal bauen → für alle künftigen Astro-Projekte nutzen. Perfekt zum Profil einer Agentur mit eigener Infrastruktur und eigenem Mailserver — und potenziell selbst vermarktbar (siehe §12).

2. Grundprinzip (das muss sitzen)

Bei statischen Seiten gibt es kein Geheimnis im Browser. Alles im Client-JS ist öffentlich. Konsequenzen:

Der „API-Token” ist keine Authentifizierung, sondern eine öffentliche Kennung (Site-Key): Er sagt dem Gateway nur „welcher Mandant bin ich” → welche erlaubten Domains, welches Kontingent, welche Schutz-Config.
Sicherheit heißt hier nicht „Unbefugte aussperren”, sondern Missbrauch teuer, wertlos, sichtbar und abschaltbar machen — und die geteilte Versand-Reputation schützen.
Defense in Depth: keine einzelne Silberkugel, sondern Schichten, die zusammen die Latte hochlegen.

3. Architektur (Überblick)

 Statische Seite (Browser)                 Techeve Form Gateway
 ┌───────────────────────┐        ┌──────────────────────────────────────┐
 │  Formular + Snippet    │        │  API-Dienst (langlaufend)            │
 │  (Site-Key, öffentl.)  │──1────▶│   GET  /v1/challenge                 │
 │                        │◀───────│   POST /v1/submit                    │
 └───────────────────────┘        │        │                              │
                                   │        ▼                              │
                                   │  Prüf-Pipeline (siehe §5)            │
                                   │        │ ok                          │
                                   │        ▼                              │
                                   │  Versand via eigenem SMTP (DKIM)     │
                                   └───────┬───────────────┬──────────────┘
                                           │               │
                                     ┌─────▼─────┐   ┌─────▼──────┐
                                     │ Datastore │   │ Admin-UI   │
                                     │ (Mandanten,│   │ (Domains,  │
                                     │  Logs,     │   │  Quotas,   │
                                     │  Nonces)   │   │  Kill-Sw.) │
                                     └───────────┘   └────────────┘

Bausteine:

API-Dienst — langlaufend (Go/Deno), nimmt Challenge- und Submit-Requests entgegen, führt die Prüf-Pipeline aus, sendet.
Admin-Backend + UI — hier werden Mandanten/Domains/Kontingente verwaltet (das „kleine Backend”, §6). Anders als die Seiten-Frontends ist das ein echtes Backend mit echter Auth.
Datastore — Mandanten, erlaubte Origins, Kontingente, Signing-Secrets, verbrauchte Nonces, Submission-Log/Audit, Blocklisten.
SMTP-Versand — über den eigenen Mailserver, feste DKIM-Absenderdomain.
(optional) Queue/Worker — Versand asynchron, Retries, Spitzenpuffer.

4. Der Kern: Challenge-/Handshake-Flow

Statt „ein POST → Mail raus” ein zweistufiger Ablauf. Das ist die wichtigste Einzelmaßnahme, weil ein naiver Bot, der nur POSTet, gar kein gültiges Ticket hat — und es nicht fälschen kann.

Seite lädt → JS ruft GET /v1/challenge?site=SITEKEY.
- Gateway prüft Origin gegen die Allowlist des Mandanten.
- Gibt ein HMAC-signiertes Challenge-Token zurück (Server-Secret), das enthält: tenant, origin, issued_at, Einmal-Nonce, optionale pow_difficulty, kurze TTL (z. B. 5–10 Min).
Client löst optional den Proof-of-Work und/oder holt ein Captcha-Token.
POST /v1/submit mit: Challenge-Token, PoW-Lösung, Captcha-Token, Honeypot-Feld, Formulardaten.
Gateway verifiziert (Reihenfolge = billig-zuerst, siehe §5) und sendet oder lehnt ab.

Der Handshake liefert gleichzeitig Replay-Schutz (Nonce einmalig), Timing-Check (zu schnell = Bot) und Origin-Bindung.

5. Security-Schichten (ausführlich)

Reihenfolge in der Pipeline: billige/harte Checks zuerst, teure zuletzt. Jede Schicht sagt, was sie leistet — und was nicht.

5.1 Origin-/Referer-Allowlist (serverseitig!)

Gateway prüft den Origin-Header gegen die für den Site-Key registrierten Domains. Wichtig: CORS erzwingt der Browser, nicht der Server — ein Bot mit curl ignoriert CORS. Also immer serverseitig prüfen und ablehnen. Und: Origin/Referer sind von Nicht-Browser-Clients fälschbar. → Schützt vor „Formular auf fremder Seite nachgebaut” und Browser-Missbrauch. Nicht vor headless Bots. Nützliche, aber schwache Schicht.

5.2 Signierte Challenge + Nonce + TTL + Timing

Siehe §4. HMAC mit Server-Secret → nicht fälschbar. Nonce → Replay-Schutz. TTL → kein Horten. Mindest-Ausfüllzeit → zu schnell = Bot. Rückgrat des Systems.

5.3 Proof-of-Work (PoW)

Die Challenge verlangt ein Rechenrätsel (Hashcash-artig), das der Browser lösen muss. Jede Absendung kostet CPU-Zeit → Massenversand wird teuer. Selbst hostbar, kein Dritter, DSGVO-sauber. Schwierigkeit pro Mandant/adaptiv steuerbar.

5.4 Captcha (optional, pro Mandant)

Wenn’s hart wird: Turnstile / hCaptcha / Friendly Captcha (EU). Token serverseitig verifiziert. Stärkste Anti-Bot-Schicht, aber mehr Reibung/ggf. Dritt-Request. Als zuschaltbare Option pro Mandant.

5.5 Mehrdimensionales Rate-Limiting

Nicht nur pro IP (IPs rotieren billig über Botnets/Proxys). Zusätzlich:

pro Site-Key (Mandanten-Kontingent, z. B. 100 Mails/Tag),
pro Empfänger/Formular,
global (Notaus / Circuit Breaker),
adaptiv (exponentielles Backoff bei Verdacht).
ASN-/IP-Reputation: Datacenter-/Tor-ASNs sind für ein Kontaktformular verdächtig; bekannte Bad-Ranges blocken.

5.6 Inhalts-/Spam-Bewertung

Score statt Hart-Block: Anzahl Links, Keywords, Sprache-Mismatch, All-Caps, Bayes/Rspamd. Ab Schwelle → Quarantäne (nicht senden, aber im Admin sichtbar) statt still verwerfen.

5.7 Honeypot + Timing-Fallen

Unsichtbares Feld (Bot füllt es → verwerfen). Billig, fängt die dumme Masse.

5.8 Mandanten-Isolation & Secrets

Pro Mandant: öffentlicher Site-Key (im JS) und privates Signing-Secret (nur im Gateway). SMTP-Zugangsdaten leben nur im Gateway. Kompromittierung eines Seiten-Frontends leakt nichts Sensibles.

5.9 Monitoring, Anomalie-Erkennung, Kill-Switch

Missbrauch kommt irgendwann. Entscheidend: Spikes pro Mandant sehen, alarmiert werden, einen Mandanten sofort deaktivieren können. Reaktionsfähigkeit > perfekte Prävention.

5.10 Zustellbarkeit & Reputations-Schutz (kritisch bei Multi-Tenant!)

Das Gateway sendet immer von seiner eigenen, DKIM/SPF/DMARC-signierten Absenderdomain; Reply-To = Absender; kein frei wählbares From. Sonst reißt ein missbrauchter Mandant mit Spam die geteilte Versand-IP in Blocklisten — und alle Kundenseiten können nichts mehr senden. Deshalb sind Mandanten-Kontingente + Monitoring hier reputationskritisch, nicht „nice”. Kein Backscatter: keine automatischen Bounces/Bestätigungsmails an fremde Adressen ohne strenge Ratenbremse.

5.11 Eingabe-Härtung

Feld-Whitelist, Längenlimits, Header-Injection-Schutz (keine \r\n in Betreff/Absender), Anhang-Policy (Typen/Größe/Menge oder gar keine Anhänge im MVP), Encoding-Prüfung.

5.12 Abuse-Response-Playbook

Definierte Schritte bei Missbrauch: Mandant drosseln → quarantänisieren → deaktivieren; IP/ASN sperren; Signing-Secret rotieren; Betreiber informieren.

6. Das kleine Admin-Backend

Der einzige Teil mit echter Authentifizierung (Admins haben echte Geheimnisse). Aufgaben:

Mandanten anlegen/verwalten: Site-Key erzeugen, Domain-/Origin-Allowlist pflegen, Kontingente setzen, Empfänger-/Routing-Regeln, Captcha an/aus, PoW-Schwierigkeit, aktiv/inaktiv.
Dashboard: Absendungen, Spam-/Quarantäne-Quote, Kontingent-Auslastung, Fehlerrate — je Mandant.
Quarantäne-Ansicht: geblockte/verdächtige Mails einsehen, freigeben oder verwerfen.
Kill-Switch je Mandant, Blocklisten (IP/ASN/Email-Muster).
Audit-Log.

MVP: reicht ein simples Admin-UI (oder erstmal CLI/DB), später hübsche Oberfläche.

7. Datenmodell (Skizze)

tenants: id, name, site_key (public), signing_secret, smtp_route/recipient, daily_quota, pow_difficulty, captcha_cfg, active, created_at.
origins: tenant_id, origin (erlaubte Domain) — n:1.
nonces: nonce, tenant_id, expires_at, used_at (Replay-Schutz; TTL-Cleanup).
submissions: id, tenant_id, received_at, ip_hash, origin, score, status (sent/quarantined/blocked), payload_snippet (nach Policy), error. (Aufbewahrung begrenzt, siehe §10.)
rate_buckets: Zähler pro IP/Site-Key/Fenster (oder in Redis).
blocklist: IP/ASN/Email-Muster.

8. API-Design (Skizze)

GET /v1/challenge?site=SITEKEY → { challenge: "<hmac-token>", pow: { difficulty }, captcha?: { provider, sitekey } }
POST /v1/submit → Body: { site, challenge, pow_solution, captcha_token, hp (honeypot), fields: {…} } → 200 { ok: true } | 4xx { ok: false, reason }
Admin (auth): POST /admin/tenants, GET /admin/tenants/:id/stats, POST /admin/tenants/:id/disable, GET /admin/quarantine …

Antworten bewusst wenig aussagekräftig nach außen (keine Hinweise, welche Schicht griff), Details nur im Admin-Log.

9. Tech-Stack-Gedanken

API-Dienst: Go (ein Binary, dependency-arm, robust, ideal als langlaufender Dienst) oder Deno (nah am JS-Stack, TS, sicher-by-default). Beides sauber als systemd-Service / Container auf Proxmox.
Datastore: PostgreSQL (Multi-Tenant, Reporting) oder SQLite für den Anfang. Redis optional für Rate-Limits/Nonces (schnell, TTL nativ).
Versand: eigener Mailserver (SMTP 587, STARTTLS), DKIM/SPF/DMARC gepflegt.
Deployment: eigener Server / Proxmox-VM / Container. Reverse-Proxy nginx.

10. DSGVO / Datenschutz (Verkaufsargument!)

EU-gehostet, eigene Infrastruktur → AV-Verträge sauber möglich.
Datensparsamkeit: nur nötige Felder, IP nur gehasht/kurz, Submission-Log mit kurzer Aufbewahrung (z. B. 30 Tage) + Auto-Löschung.
Selbst gehostetes PoW/Captcha möglich → kein Google/US-Dritter.
Transparente Doku, was gespeichert wird — genau euer „datensparsam”-Anspruch.

11. Client-Integration (wie eine Astro-Seite es nutzt)

Winziges JS-Snippet oder npm-Paket (@techeve/form-gateway): liest data--Attribute am <form> (Site-Key, Ziel), macht Challenge→PoW→Submit, zeigt Inline-Erfolg/Fehler.
Progressive Enhancement: ohne JS optionaler mailto-Fallback.
Ergebnis für den Entwickler: Formular + ein Snippet + Site-Key eintragen → fertig. Kein Backend pro Projekt mehr.

12. Vermarktung als Service (erste Gedanken)

Positionierung: „EU-/DSGVO-first Form-Backend für statische Seiten — selbst gehostet oder gemanagt.” Das ist die Lücke, die Formspree & Co. für den DACH-Markt offen lassen.

Zielgruppe: Agenturen und Jamstack-/Astro-Entwickler, besonders DSGVO-sensibler DACH-Raum; eigene Kundenprojekte als erster Markt (Dogfooding).

Differenzierung vs. Formspree/Web3Forms/Basin:

EU-gehostet, AV-Vertrag/DSGVO out of the box.
Self-hosted-Option (kein Vendor-Lock, Datenhoheit).
Kein Dritt-Captcha nötig (eigenes PoW).
Transparent, faire Kontingente.

Geschäftsmodelle (Optionen):

Managed SaaS: Free-Tier (z. B. 50 Submissions/Monat), dann Staffelung nach Volumen/Formularen/Mandanten.
Self-hosted-Lizenz: einmalig/jährlich, für Firmen mit Datenhoheits-Anspruch.
Hybrid: gemanagt + „bring your own SMTP”.
Als Add-on zu euren Web-/Hosting-Paketen bündeln.

Branding: „Techeve Form Gateway” — passt zu euren eigenen Produkten (DNS-Editor, Mailserver). Positioniert Techeve als Anbieter eigener, datensouveräner Bausteine.

Go-to-Market: 1) intern für eigene Projekte nutzen (härtet & referenziert das Produkt), 2) als Beta für befreundete Agenturen öffnen, 3) öffentlicher Free-Tier + Landingpage.

13. Roadmap: MVP → später

MVP (intern, ein/wenige Mandanten):

Challenge-Flow (HMAC + Nonce + TTL + Timing), Honeypot, Rate-Limit, PoW, Origin-Check, SMTP-Versand mit DKIM, minimales Admin (DB/CLI).

v2 (Multi-Tenant-Produkt):

Admin-UI, Kontingente, Captcha-Option, Spam-Scoring/Quarantäne, Dashboards, Kill-Switch, npm-Client-Paket.

v3 (SaaS):

Self-Service-Registrierung, Billing, Nutzungsmetriken, Statuspage, Self-hosted-Distribution.

14. Offene Fragen

Anhänge erlauben? (Risiko/Aufwand — im MVP eher nein.)
Eingehende Bestätigungs-Mails an Absender (Double-Opt-in) — ja/nein, wegen Backscatter-Risiko nur streng ratenbegrenzt.
Ein geteilter SMTP/Absender für alle Mandanten oder „bring your own”? (Reputations-Trade-off.)
Free-Tier-Grenzen & Missbrauchs-Ökonomie durchrechnen.
Hosting-Region/Redundanz für den Managed-Betrieb.