Auf dem Server scheiterte der Login mit "Could not authenticate", während
dieselben Zugangsdaten vom Entwicklungsrechner angenommen werden. Beide Namen
(w01ca75d.kasserver.com und der Webserver) zeigen auf dieselbe IP — vom Webspace
aus verbindet sich PHP also mit der eigenen Maschine, und die kann Anmeldungen
anders behandeln als Verbindungen von außen.
--probe testet vier Zugangswege (587/STARTTLS, 465/SSL, localhost:25 mit und
ohne Anmeldung) und nennt den ersten, der trägt. Bewusst nur vier: jeder
Fehlversuch ist ein fehlgeschlagener Login, zu viele sperren ein Postfach.
--frage fragt das Passwort verdeckt ab, damit ein neu gesetztes Postfach-Passwort
geprüft werden kann, BEVOR es in eine Datei auf zwei Rechnern wandert.
Die Fehlerausgabe nennt bei "Could not authenticate" jetzt die drei Ursachen,
die dahinter stecken können.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NzeVVgMCrzCDJAKeLEdKr7
Versand läuft jetzt über das KAS-Postfach noreply@tsv08kulmbach.de
(w01ca75d.kasserver.com:587, STARTTLS) — ein Drittanbieter weniger,
SPF der Domain deckt den Server bereits ab. bin/smtp-test.php prüft
Verbindung, TLS und Login ohne eine Mail zu versenden (Debug bewusst
aus, damit keine Credentials im Terminal landen).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
