# Issue #34 – Kontaktformular: E-Mail-Versand via PHP

- **Repo:** `greggy/landingpage-haus-schleusingen`
- **Issue:** #34
- **Titel:** Kontaktformular: E-Mail-Versand via PHP
- **Komplexität:** **M**
- **Stand:** Analyse abgeschlossen
- **Datum:** 2026-05-14

## Kurzbewertung

Das Issue ist **Medium (M)**: Es ist kein großer Architekturumbau, aber es ist mehr als ein kleiner Bugfix, weil serverseitige PHP-Logik, Spam-Schutz, Validierung, sichere Header-Behandlung und UI-Feedback zusammen umgesetzt werden müssen.

## Abhängigkeiten

- **Keine blockierenden offenen Issues gefunden.**
- `index.php` existiert bereits auf `main` und ist die richtige Basis für die PHP-Umsetzung.
- Hinweis: Das bestehende Docker/Nginx-Setup dient weiter als statisches Preview, verarbeitet aber kein PHP-Mail-Handling. Für den echten Versand ist eine PHP-fähige Laufzeit nötig (Testumgebung: Apache/PHP).

## Anforderungen aus dem Issue

1. Kontaktformular verschickt E-Mails serverseitig via PHP.
2. Empfänger ist `mki@kies-media.de`.
3. Absender (`From`) ist die E-Mail-Adresse aus dem Formular.
4. Pflichtfeld-Validierung für Name, E-Mail und Nachricht.
5. Spam-Schutz via Honeypot und zusätzlicher Missbrauchsschutz.
6. Erfolgsmeldung nach erfolgreichem Versand.
7. Verständliche Fehlermeldungen bei ungültigen oder fehlenden Eingaben.

## Implizite Anforderungen / Edge Cases

- Header-Injection über Name/E-Mail darf nicht möglich sein.
- Ungültige E-Mail-Adressen müssen serverseitig abgelehnt werden.
- Leere oder nur aus Leerzeichen bestehende Nachrichten müssen abgelehnt werden.
- Bots sollen am Honeypot scheitern.
- Sehr schnelle Direkt-Submits sollen als verdächtig behandelt werden.
- Mehrfach-Submits in kurzer Zeit sollen begrenzt werden.
- Bei Mail-Fehlern darf kein falscher Erfolg angezeigt werden.
- Formulardaten sollen bei Validierungsfehlern im Formular erhalten bleiben.

## Technischer Plan

### Backend / PHP

- `index.php` bekommt einen serverseitigen POST-Handler.
- `session_start()` wird verwendet für:
  - Formular-Timestamp
  - einfaches Rate-Limit zwischen Submits
- Hilfsfunktionen:
  - `normalizeContactValue()` für Trim/Sanitizing
  - `escapeContactValue()` für sichere Ausgabe ins HTML
  - `containsHeaderInjection()` für Header-Schutz
- Versand über `mail()` mit Headern:
  - `From: <Formular-E-Mail>`
  - `Reply-To: <Formular-E-Mail>`
  - `Content-Type: text/plain; charset=UTF-8`
- Bei Erfolg: Formular leeren und Erfolgsmeldung rendern.
- Bei Fehlern: Fehlerliste oberhalb des Formulars rendern.

### Frontend / HTML

- Formular auf `method="post"` umstellen.
- Honeypot-Feld ergänzen (visuell versteckt, für Screenreader ebenfalls ausgeschlossen).
- Hidden-Feld für Formular-Token/Timestamp ergänzen.
- Bestehende Erfolgsmeldung auf serverseitig gesteuerten Zustand umbauen.
- Pflichtfelder klar markieren und `required` beibehalten.

### Frontend / JS

- Bestehende `mailto:`-Logik entfernen.
- Sonstige Interaktionen (Lightbox, Navigation, Scroll) unverändert lassen.

### Styling

- Styles für:
  - Fehlermeldungsbox
  - serverseitige Erfolgsmeldung
  - Honeypot-Hilfsklasse

## Sicherheitsbetrachtung

- Pflicht: serverseitige Validierung, nicht nur HTML5.
- Pflicht: Schutz vor Header-Injection in Mail-Headern.
- Pflicht: Honeypot leer + Mindestzeit bis Submit + Session-Rate-Limit.
- Keine sensiblen Daten in Logs oder im Frontend ausgeben.

## Teilaufgaben

1. `main`-Stand prüfen und Feature-Branch anlegen.
2. `index.php` serverseitig auf POST/Mailversand umbauen.
3. Formular um Honeypot, Hidden-Felder, Fehler-/Erfolgsausgabe ergänzen.
4. `js/haus-schleusingen.js` von `mailto:`-Submit befreien.
5. CSS für Meldungszustände ergänzen.
6. Linting / Formatierung / PHP-Syntaxcheck ausführen.
7. Self-Review dokumentieren.
8. QA inkl. Happy Path, Validierungsfehler und Spam-Schutz dokumentieren.
9. PR erstellen und Martin zur Freigabe vorlegen.

## Akzeptanzkriterien

- [ ] Formular sendet serverseitig eine E-Mail an `mki@kies-media.de`.
- [ ] `From` verwendet die eingegebene Formular-E-Mail.
- [ ] E-Mail enthält Name, E-Mail, optional Telefon, Anliegen und Nachricht.
- [ ] Honeypot + zusätzlicher Missbrauchsschutz aktiv.
- [ ] Erfolgsmeldung nach erfolgreichem Versand sichtbar.
- [ ] Fehlermeldungen bei fehlenden/ungültigen Pflichtfeldern sichtbar.

## Architekturentscheidung

Es wird bewusst **kein** SMTP-Layer oder externer Mailer eingebaut, weil das Issue explizit `mail()` erlaubt und für dieses Projekt eine schlanke, servernahe Lösung genügt. Falls Zustellbarkeit oder Hosting-Limits später Probleme machen, wäre ein Folge-Issue für SMTP/PHPMailer sinnvoll.