openclaw/memory/gitea-specs/issue-34.md

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.