E-Mail-Versand #

owncloud.online verschickt Mails an mehreren Stellen: Freigabe-Einladungen, Passwort-Zurücksetzen, Kontoanlage und Kalendereinladungen. Ist kein Versand eingerichtet, fallen diese Funktionen aus — meist ohne sichtbare Meldung, der Fehler landet nur im Serverprotokoll. Diese Seite beschreibt die Einrichtung über die Oberfläche und über config/config.php, den Testversand sowie die Fehlersuche.

Was ohne Mailversand ausfällt #

Zwei Einschränkungen, die häufig anders erwartet werden:

• Eine eigene Warnmail vor dem Ablauf einer Freigabe verschickt der Kern nicht. Das Ablaufdatum wird in die Einladungsmail eingesetzt (createMailBody() in lib/private/Share/MailNotifications.php), danach erfolgt keine weitere Erinnerung.
• Aktivitäts-Zusammenfassungen entstehen erst im Hintergrund-Job der App activity. Ohne laufenden Cron werden sie nie verschickt, siehe Hintergrund-Jobs (Cron). Ein Nachholen von Hand:

sudo -u www-data php8.4 occ activity:send-emails

Einrichtung über die Oberfläche #

Der Abschnitt E-Mail-Server liegt unter Einstellungen → Administration → Allgemein (settings/Panels/Admin/Mail.php, Abschnitt general).

Das obere Formular speichert bei jeder Änderung sofort (settings/js/panels/mail.js sendet bei change an /settings/admin/mailsettings). Benutzername und Passwort gehen einen eigenen Weg und werden erst mit dem Knopf übernommen. Wird die Authentifizierung abgeschaltet, löscht MailSettingsController::setMailSettings() Benutzername und Passwort aus der Konfiguration.

Ist config_is_read_only auf true gesetzt, entfallen beide Formulare. An ihrer Stelle steht der Hinweis „Die Konfigurationsdatei ist schreibgeschützt. Bitte passe deine Einstellungen durch manuelle Bearbeitung der Konfigurationsdatei selbst an." samt Zusatz zur Synchronisierung im Cluster — dann führt nur der Weg über config/config.php. Das Feld für den Testversand und der Knopf E-Mail senden bleiben auch dann sichtbar.

Einrichtung über config.php #

Typische SMTP-Anbindung mit STARTTLS auf Port 587:

sudo -u www-data php8.4 occ config:system:set mail_smtpmode --value smtp
sudo -u www-data php8.4 occ config:system:set mail_smtphost --value smtp.example.com
sudo -u www-data php8.4 occ config:system:set mail_smtpport --value 587 --type integer
sudo -u www-data php8.4 occ config:system:set mail_smtpsecure --value tls
sudo -u www-data php8.4 occ config:system:set mail_smtpauth --value true --type boolean
sudo -u www-data php8.4 occ config:system:set mail_smtpauthtype --value LOGIN
sudo -u www-data php8.4 occ config:system:set mail_smtpname --value noreply@example.com
sudo -u www-data php8.4 occ config:system:set mail_smtppassword --value 'CHANGE_ME'
sudo -u www-data php8.4 occ config:system:set mail_from_address --value noreply
sudo -u www-data php8.4 occ config:system:set mail_domain --value example.com

--type ist bei mail_smtpport und mail_smtpauth nötig, sonst landen die Werte als Zeichenkette in der Datei. Gleichwertig ist der direkte Eintrag in config/config.php:

'mail_smtpmode' => 'smtp',
'mail_smtphost' => 'smtp.example.com',
'mail_smtpport' => 587,
'mail_smtpsecure' => 'tls',
'mail_smtpauth' => true,
'mail_smtpauthtype' => 'LOGIN',
'mail_smtpname' => 'noreply@example.com',
'mail_smtppassword' => 'CHANGE_ME',
'mail_from_address' => 'noreply',
'mail_domain' => 'example.com',

Kontrolle der gesetzten Werte:

sudo -u www-data php8.4 occ config:system:get mail_smtphost

occ config:list system blendet mail_smtphost, mail_smtpname, mail_smtppassword, mail_from_address und mail_domain aus — sie stehen in lib/private/SystemConfig.php als schutzwürdig. config:system:get gibt den Klartext aus.

Alle mail_-Schlüssel #

Zum Sendemodus im Detail (Mailer::getInstance() und Mailer::getSendMailInstance()):

• smtp — Verbindung zu mail_smtphost:mail_smtpport. Nach 100 Nachrichten wird die Verbindung neu aufgebaut.
• qmail — Aufruf von /var/qmail/bin/sendmail -bs.
• php, sendmail und jeder andere Wert — Aufruf von /usr/sbin/sendmail -bs. Der Modus php benutzt also nicht die Funktion mail() und nicht den in der php.ini eingetragenen sendmail_path, auch wenn der Beschreibungstext in config/config.sample.php das nahelegt. Ohne lokal installierten MTA schlägt dieser Weg fehl.

Ergänzend gehört zu diesem Themenblock, ohne mail_-Präfix:

Absenderadresse und Antwortadresse #

Die Absenderadresse baut \OCP\Util::getDefaultEmailAddress() zusammen. Jede Stelle im Code gibt einen Standard-Lokalteil vor, den mail_from_address überschreibt:

Den Domain-Teil liefert mail_domain, ersatzweise der Hostname des Servers. Ergibt sich daraus keine gültige Adresse, fällt der Code auf <lokalteil>@localhost.localdomain zurück — solche Mails werden von den meisten Empfängerservern abgelehnt. Setzen Sie deshalb auf Produktivsystemen mail_from_address und mail_domain immer explizit, und zwar auf eine Domain, für die Ihr SMTP-Server versenden darf.

Die Antwortadresse wird nur bei Freigabemails gesetzt (MailNotifications::getReplyTo()): Es ist die Adresse des Benutzers, der freigegeben hat. Hat dieser keine Adresse hinterlegt, wird auf die Standard-Absenderadresse mit dem Lokalteil sharing-noreply zurückgefallen — also ebenfalls überschrieben von mail_from_address, falls gesetzt. Kalendereinladungen sind ein Sonderfall: Dort setzt IMipPlugin den Absender der iTIP-Nachricht — je nach Methode der Organisator oder ein antwortender Teilnehmer — sowohl als Absender- als auch als Antwortadresse; mail_from_address greift dort nicht. Alle übrigen Mails haben keine eigene Antwortadresse.

Testversand #

Im Abschnitt E-Mail-Server steht unten das Feld Test Empfänger E-Mail Adresse, vorbelegt mit der Adresse des angemeldeten Kontos, und der Knopf E-Mail senden. Ergebnis:

• Erfolg: „E-Mail wurde verschickt".
• Fehler: „Beim Senden der E-Mail ist ein Problem aufgetreten. Bitte überprüfe deine Einstellungen. (Fehler: …)" — in der Klammer steht die Meldung des Transports, siehe Fehlersuche.
• Ist das Feld leer — das ist der Fall, wenn beim eigenen Konto keine Adresse hinterlegt ist —, bricht bereits settings/js/panels/mail.js ab und zeigt die fest einprogrammierte, unübersetzte Meldung „Please provide an test receiver email". Es wird dann gar nicht erst gesendet.

Die Testmail geht mit dem Standard-Lokalteil no-reply heraus (also no-reply@<mail_domain>, sofern mail_from_address nicht gesetzt ist), Betreff „E-Mail-Einstellungen testen". Sie prüft damit nur den Weg vom Server zum Mailserver, nicht die spätere Zustellbarkeit der Freigabe- und Passwortmails.

Adressen von Benutzern setzen oder nachtragen:

# Adresse eines vorhandenen Kontos setzen
sudo -u www-data php8.4 occ user:modify benutzername email person@example.com

# Konto samt Adresse anlegen
sudo -u www-data php8.4 occ user:add --email person@example.com benutzername

Benutzer selbst pflegen ihre Adresse unter Einstellungen → Persönlich → Allgemein im Abschnitt E-Mail.

SMTP-Dialog protokollieren #

Für die Fehlersuche lässt sich der gesamte SMTP-Dialog mitschreiben. Das protokolliert auch den Benutzernamen, deshalb nur kurzzeitig einschalten:

sudo -u www-data php8.4 occ config:system:set mail_smtpdebug --value true --type boolean
sudo -u www-data php8.4 occ config:system:set loglevel --value 0 --type integer

loglevel 0 ist nötig, weil der Transport auf Debug-Ebene schreibt. Danach beides zurückstellen (loglevel auf 2, mail_smtpdebug auf false). Zum Lesen des Protokolls siehe Serverprotokoll und Fehlermeldungen.

Fehlersuche #

Bleibt die Ursache unklar, den SMTP-Dialog wie oben beschrieben mitschreiben — darin steht die Antwort des Mailservers im Klartext.