Hallo zusammen,

ich habe das Problem, dass Apple Mail auf dem MBP meiner Frau seit längerer Zeit keine Emails mehr versendet. Dabei ist es irrelevant, ob sie das von zu Hause aus im WLAN durchführt oder z.b. über den Hotspot mit meinem Handy. System ist Mojave. Von Ihrem Iphone funktioniert das übrigens einwandfrei.

Im Folgenden mal ein paar Screenshots dazu.
1) Einstellungen
2) Funktionstest
3) Fehlermeldung
4) geänderte Einstellungen, aufgrund der Fehlermeldung
5) Funktionstest immer noch ok
6) neue/andere Fehlermeldung
7) vorgegebene Einstellungen (Server der Ruhr-Uni-Bochum)

Hat jemand eine Idee, woran es liegen könnte/welche Einstellungen noch geändert werden müssten?
Danke für Eure Hilfe.

Grüße

Zacke

"Authentifizierung" "ohne" kann ich mir nicht vorstellen.
Er will ja auch STARTTLS Authentifizierung haben.

Hatte ich vor kurzem auch mal und löschte die Verbindung komplett. Neu eingerichtet und alles lief wieder. Vielleicht beim Update irgendwas verschoben. Dieses "keine Anmeldung erforderlich" paßt ja auch irgendwie nicht zu den Daten, die dann doch gesetzt werden müssen.

Authentifizierung "ohne" dürfte schon mal falsch sein. Versuche es bitte mal mit CRAM-MD5, das wird vermutlich funktionieren.

Zusätzlich solltest Du Port 587 verwenden (das ist einmal so eingestellt und einmal auf 465) und "SSL/TLS verwenden" einschalten, zumindest wenn Du der Empfehlung der RUB folgen willst. Seit 2018 sieht das die IETF mal wieder anders (und hat, seit Port 465 auch wirklich für SMTPS reserviert ist, damit auch einen guten Punkt).

Also entweder 587 mit STARTTLS, 465 mit TLS, aber in beiden Fällen mit Authentifizierung.

Es kann übrigens gut sein, daß es aus dem Netz der RUB auch ohne Authentifizierung geht. Nur falls Du es im Institut getestet hast und da ging es noch ...

Hey, lieben dank. Alleine das Umstellen von "Ohne" auf "Passwort" hat schon funktioniert.
Vielen lieben Dank (Im Namen meine Frau)

Ein +1 für die seltene und sehr vorbildliche Fehlerbeschreibung!

Noch kurz dazu:

STARTTLS ist kein Authentifizierungsverfahren, sondern ein Protokoll, das es ermöglicht, über den gleichen Port (meist 25 für Server-Server- oder 587 für Client-Server-Verbindungen) sowohl verschlüsselte als auch unverschlüsselte Verbindungen anzunehmen. Dabei sagt der Server beim Aushandeln der Verbindung "Ich kann STARTTLS", und der Client kann sich dann aussuchen, ob er verschlüsseln will oder nicht.

Alternativ kann man einen Port benutzen, auf dem der Server gleich TLS spricht (also ohne vorher eine Klartextverbindung mit STARTTLS gemacht zu haben). Dann kann man auf dem Port nur verschlüsselt kommunizieren, was in der Regel die sicherere Variante ist. Neuerdings ist das offiziell 465 - bis 2018 wurde der Port auch verbreitet benutzt, war aber eigentlich für ein anderes Protokoll reserviert. Da hat die normative Kraft des Faktischen mal sinnstiftend zugeschlagen.

Viele Server gehen nun her und erlauben Authentifizierung nur dann, wenn vorher Verschlüsselung ausgehandelt wurde. Wenn als Protokoll CRAM-MD5 eingesetzt wird, ist das eigentlich unkritisch, aber es gibt auch Protokolle, bei denen das Paßwort schlimmstenfalls im Klartext bzw. BASE64-codiert übertragen wird. Wenn der Server also unverschlüsselte Authentifizierungsprotokolle anbietet, muß die Verbindung verschlüsselt weden, über die man sich mit dem Server unterhält.

Ein kurzer Blick auf den Server der RUB bestätigt das:


Aus der Antwort kann man erkennen, daß der Server kein Login akzeptiert (sonst stände da irgendwo eine Zeile drin, die mit "250-AUTH" anfängt. Wenn man die Verbindung nicht mit telnet (das unverschlüsselt arbeitet), sondern mit openssl aufmacht und das STARTTLS-Protokoll aktiviert, kommt man ein Stück weiter:


Jetzt darf man sich authentifizieren (übrigens nur mit PLAIN und LOGIN, was Klartext-Methoden sind. Siehe oben).

Was man hier nicht sehen kann ist, ob man jetzt über den Server Mail verschicken kann oder nicht. Ob das erlaubt ist, ist im SMTP-Protokoll gar nicht erkennbar, und es ist auch gar nicht so einfach zu sagen - so kann ein Server z.B. Mails an lokale Adressaten akzeptieren, Mails an externe Adressaten (also z.B. wie im Fall des OP oben) nicht. Der Sinn ist natürlich, daß man kein "Open Relay" betreiben will, also keinen Server, der alles weiterleitet, was er bekommt, und damit als SPAM-Schleuder benutzt werden kann.

Gängige Praxis bei Mailservern, die Mails von Clients entgegennehmen, ist, daß sie nur dann Mails extern weitersenden, wenn man sich authentifiziert hat. Und wie wir im vorliegenden Beispiel gesehen haben, setzt das schon allein deshalb Verschlüsselung voraus, weil es immer noch doofe Clients gibt, die keine Authentifizierung über CRAM-MD5 oder andere sichere Verfahren beherrschen.

Lieber Peter Eckel, ich verstehe kein Wort Deiner Ausführungen, was über die üblichen Subjekte, Prädikate und Objekte sowie irgendwelchen Pronomen etc. hinausgeht aber scheint mir, als würdest Du Dich da genauer auskennen....
Nun, jedenfalls funktioniert es jetzt wieder