Failed to authenticate on SMTP server with username "mrx@example.com" using 0 possible authenticators

🌐 Non-english support đŸ‡©đŸ‡Ș Deutsch (german)
1

Ich erhalte o.g. Fehlermeldung beim Versuch, eine Test-E-Mail via Grundeinstellungen|E-Mail-Server ĂŒber ein externes E-Mail-Konto (d.h. nicht via localhost) zu versenden.

System: Nextcloud 21.0.2
PHP Version: 7.4.3
Webserver: Apache 2

Der betreffende E-Mail-Server akzeptiert SMTP-Verbindungen auf Port 25 mit STARTTLS VerschlĂŒsselung und Authentifzierung. Mit den ĂŒblichen E-Mail-Clients wie Thunderbird lĂ€uft das fehlerfrei.

Mit Blick auf die ÜberprĂŒfung des Systems in der Übersicht liegen angeblich keinerlei Probleme bzw. Fehlkonfigurationen vor.

Da ich bereits so einiges versucht habe, hier eine Lösung zu finden, halte ich mich zunÀchst an die offizielle Dokumentation zu diesem Thema. daher notiere ich direkt die EintrÀge in der config.php

  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'mrx',
  'mail_domain' => 'example.com',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtphost' => 'mail.example.com',
  'mail_smtpport' => '25',
  'mail_smtpauth' => true,
  'mail_smtpname' => 'mrx@example.com',
  'mail_smtppassword' => 'geheim',
  'mail_smtptimeout' => 30,
  'mail_smtpsecure' => 'tls',
  'mail_smtpdebug' => true,

Zum einen wird vom Frontend hier bei ‘mail_smtpauth’ => 1, eingetragen. Naja, kann man als true auswerten. Ich habe es einmal auf true gemĂ€ĂŸ der Dokumentation geĂ€ndert - allerdings ohne Erfolg.

Zum anderen habe ich die Hinweise bzgl. Anti-Spam-Mechaniken in der Doku beim E-Mail-Server den ‘mail_smtptimeout’ => 30, zusĂ€tzlich eingetragen - gleichfalls ohne Erfolg

Mit Blick in das Protokoll des betreffenden E-Mail-Servers (Daten anonymisiert) wird deutlich, dass

Jun 23 16:58:58 host postfix/smtpd[212480]: connect from nextcloud.example.com[192.168.0.1]
Jun 23 16:58:58 host postfix/smtpd[212480]: Anonymous TLS connection established from nextcloud.example.com[192.168.0.1]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Jun 23 16:58:58 host dovecot: auth: Debug: auth client connected (pid=0)
Jun 23 16:58:58 host postfix/smtpd[212480]: lost connection after EHLO from nextcloud.example.com[192.168.0.1]
Jun 23 16:58:58 host postfix/smtpd[212480]: disconnect from nextcloud.example.com[192.168.0.1] ehlo=2 starttls=1 commands=3

eine STARTTLS Verbindung ĂŒber den SMTP-Port 25 korrekt aufgebaut wird, aber

aus unerfindlichen GrĂŒnden seitens Nextcloud offensichtlich nichts weiter unternommen wird, als so z.B. keine Login-Daten ĂŒbertragen werden. NatĂŒrlich kommt dann ein Timeout bedingtes Ende der Verbindung.

Was ich auch nicht verstehe, warum der Parameter ‘mail_smtpdebug’ => true, angeblich zusĂ€tzliche Log-EintrĂ€ge verursachen soll, aber die Logdatei abgesehen von diesem Fehler

Error index TypeError: Argument 3 passed to OCA\Files\Service\TagService::__construct() must be an instance of OCP\ITags, null given, called in /var/www/example.com/nc/apps/files/lib/AppInfo/Application.php on line 108

leer bleibt.

Zum einen wĂŒrde es mir helfen, wenn ich erfahren könnte, was denn wo als Debug-Informationen angezeigt werden, wenn eben dieser entsprechende Parameter aktiv ist. Ich habe den Log-Level fĂŒr NC auf 2 (also ab Warning aufwĂ€rts) stehen. Darunter wird das Protokoll völlig unĂŒbersichtlich. Aber, ok, wenn es nicht anders geht und hier mit dem Parameter ‘mail_smtpdebug’ => true, als Level DEBUG LogeintrĂ€ge erfolgen, dann geht es wohl nicht anders.

Zum anderen bin ich zur Zeit ratlos, da bei Abgleich mit der Dokumentation alle Werte eigentlich passend gesetzt sind.

2

Selbst mit loglevel 0 (debug) verweigert nc beharrlich die TÀtigkeit (Versand einer e-mail) jedoch ohne irgendeinen logeintrag mit dem man zumindest den Hauch einer Chance hÀtte, hier den Fehler zu finden.

3

Nach einigem Kopfzerbrechen und vergeblicher Suche nach dem Problem und Tests lÀsst sich folgendes festhalten.

Die Funktion fĂŒr die Nutzung von STARTTLS scheint hier fehlerhaft zu sein. SSL/TLS hingegen funktioniert.

Bei einem Server, der eben nur ĂŒber Port 25 und STARTTLS erreichbar ist, eben ungĂŒnstig.

4

Hi @Mike07

Du könntest einen Issue bei GitHub eröffen. Ich könnte mir gut vorstellen, dass diese Problem nicht auf dem Radar der Entwickler ist, weil eigentich generell davon abgeraten wird Port 25 fĂŒr die Verbindung von Clients zu verwenden. DafĂŒr wird normalerweise Port 587 verwendet. Du könntest auch versuchen die Logs des Servers zu kriegen und diese dann im Issue posten
 Und/oder die Jungs und MĂ€dels, die den Server betreiben (falls du es nicht selbst bist) fragen, ob sie das Ganze nicht standardkonform via Port 587 einrichten woillen :wink:

5

Oha, ich habe die Lösung gefunden. ZunÀchst einmal habe ich schön brav nach dem RFC Standard die Submission (Port 587 und STARTTLS) auf dem Server eingerichtet. Weiter getestet, weiterhin lost connection after ELHO ohne jeden weiteren Kommentar.

Mit einem anderen Provider, allerdings mit SSL/TLS und Port 465 getestet, siehe da, es funktioniert.

Eine Fehlkonfiguration des E-Mail-Server wÀre denkbar, aber wenn da x-beliebige andere E-Mail-Clients keine Probleme haben, doch recht unwahrscheinlich.

Der Fehler liegt in der falschen Interpretation von der Einstellung Authentifizierungsmethode sowie der Diskussion um den Standard, hier konkret den Sinn und Zweck einer weiteren VerschlĂŒsselung des Passworts, wenn doch die Verbindung an sich bereits verschlĂŒsselt ist.
In NC kann man das leider nicht so richtig nachvollziehen, hier gibt es “keine, Anmelden, Klartext und NT-LAN-Manager”. Man muss nun wissen, dass mit “Anmelden” → “verschlĂŒsseltes Passwort” gemeint ist. Nach der Änderung auf “Klartext”, dem Haken “Authentifizierung benötigt” und der Sicherheit “STARTTLS” und dem Port 587 lĂ€uft alles nun nach dem aktuellen “Standard” bzw. den aktuellen Empfehlungen. Hier wĂ€ren andere Beschriftungen evt. sinniger. Und die Fehlermeldung mĂŒsste evt. ein wenig aussagekrĂ€ftiger sein.

1 Like