Kmail5 versendet partout nicht

Das muss dir nicht peinlich sein.
Und - falls dich das tröstet: Das ist auch ganz und gar nicht in Ordnung.

Jetzt kann im Netz Hinz&Kunz mitlesen, solange er irgendwie in den auf dem Weg zwischen dir und dem Mailprovider beteiligten Netzen mit drinhängt.
Das ist indiskutabel und heute nicht mehr empfehlenswert.

Die TLS Verschlüsselung MUSS funktionieren.
Das ist der Mindestschutz.
Anständige Mailprovider lassen gar keine ungesicherten Verbindungen mehr zu.
Das war nur ein Test, ob es generell geht, oder schon im einfachsten Falle hakt.

Versuche jetzt auf blöd, die startTLS Konfig noch mal, wie in dem vorherigen Posts beschrieben, einzustellen.
Es mag sein, dass beim Provider deine Kiste auf der Blacklist stand.
(Durch zu viele Fehlversuche hat der Server dort gedacht, du wolltest TLS hacken.... oder so'n Kram)

Und wenn du die Konfig -gemäß Providervorgaben- wieder auf TLS umgestellt hast, könnte es sein, dass jetzt Mails auch anständig verschlüsselt gesendet werden können.
Berichte nach Versuch.

Wieso SSL/TLS?

Laut Doku von denen ist das STARTTLS !!!!
Bei startTLS wird die Verschlüsselung erst ausgehandelt. Der Verbindungsaufbau ist unverschlüsselt.
Bei SSL oder TLS wird sofort verschlüsselt.
So kann das nicht funktionieren.

Das sollte Kmail aber auch alleine rausfinden, wenn man es einfach mal checken lässt.

**soifz**

Und startTLS ?

ÖHA!! Früher®™ gab es da eine extra Option für startTLS.
Ich selbst verwende Kmail/Kontact habe aber das Problem nicht.
Mag sein,, dass das jezt vereinheitlicht ist und KDE das intern "regelt".

Jetzt wird's doof.
Und etwas mehr Arbeit.
Und nur Vermutungen.

Ich denke, dass zwar der Mailprovider nach wie vor startTLS anbietet und verwendet, das aber Kmail nicht erkennt.
Um das rauszufinden, wäre es wohl das einfachste einen zweiten Mailclient (Thunderbird) zu konfigurieren und zu gucken, ob damit Versand möglich ist. Da kann man startTLS explizit angeben.

Sicherheitshalber solltest du dem Provider das nochmal schildern und nachfragen, ob sich das wirklich so verhält.

Und dann halt einen Bugreport erstellen, wenn dem so ist.
(Also Thunderbird tut und Provider bestätigt, dass sie nichts geändert haben)

Also jetzt passt gar nichts mehr zusammen.
Es beginnt Spass zu machen.

Mit STARTTLS auf Port 143 kann es -laut Post #38- definitiv nicht gehen.
Dort geht NUR unverschlüsselt.
Du MUSST dafür Port 993 verwenden.
Zumindest legt das die Providerinfo nahe.
Und das solltest du schleunigst auch so probieren und einstellen.

Also für den IMAP- Teil auf Port 993 mit STARTTLS.
Ich denke mal, dass das dann klappt.
Wenn dem so ist, wirst du das einfach nicht mehr anfassen.

Klappt das nicht, wird weiter unten klar, was zu tun wäre.
Dann wäre tatsächlich ein solches TLS-ClientCert nötig.

Hintergrund:
Dein Provider verwendet für das gesamte Mailgedöns die URL mail.macbay.de
Dahinter kann nun ein Host stehen, oder die Arbeit wird via DNS- Trickery auf sehr viele Hosts verteilt.
Wir wissen das nicht, und könnten wir das leicht wissen, wäre der Provider längst keiner mehr.
Das wäre ein übles Sicherheitsloch.

Bei einem Mailsystem gibt es prinzipiell zwei völlig verschiedene Teile, der sehr eng miteinander agieren.
Beide Teile verwenden wiederum meist sehr viele andere Milter (ein neudeutsches Kunstwort, das Mischung aus Mail und Filter == Milter ist).
Die beiden Hauptteile sind der MTA (==MessageTransferAgent) und der POP (==PostOfficeProtocol) oder IMAP (=InternetMessageAccessProtocol).

Der MTA kümmert sich nur um das Empfangen und Senden; meist ist das ein postfix- Server.
Der POP/IMAP - Server kümmert sich um die Mailaccounts und hält die Mails für die berechtigten User vor, um sie dann bei Bedarf auszuliefern. Das können nun zwei verschiedene Server -einmal POPx und einmal IMAP- tun, oder ein Server handelt beide.
Je nach Gusto.

Geht nun eine Mail an dich bei deinem Provider ein, so guckt der dortige MTA erst einmal, ob er die überhaupt annehmen will. Zuerst wird die Domain gecheckt und entschieden, ob man für diese Domain überhaupt zuständig ist, sie evtl. zu einem anderen Mailsystem weiterleiten wird (ein MTA kann selbst eine, mehrere oder keine Domain beackern; bei mehreren oder keiner Domain kann er quasi als Proxy die Mails an andere Systeme weiterleiten, oder sie schlicht komplett ablehnt.
Die Milter, die an dieser Stelle schon tätig werden, überspringe ich.
Ist entschieden, die Mail eventuell zu akzeptieren, wird nun geprüft werden, ob die Mailadresse überhaupt gültig ist.

Und an dieser Stelle überschneiden sich der MTA- und der POP/IMAP- Server das erste Mal.
Denn sowohl MTA, wie auch POP/IMAP sollten die gleichen Userdaten kennen und verarbeiten. Woher auch immer die stammen.

Gültige Mailaccounts können in einer schlichten Textdatei definiert sein, oder in einer Datenbank, oder in allen anderen möglichen Authentifizierungsmöglichkeiten. Es gibt davon einige: Kerberos, LDAP, "normale" Datenbank, "Systemuser" und so weiter und so fort. Eine dieser unzähligen Möglichkeiten ist das Authentifizieren mittels Zertifikaten.
Das ist kaum verbreitet, weil es ein gewisses Mass von Wissen und Vorarbeit auf beiden Seiten verlangt.

Heute sollte jeder Webserver nur noch HTTPS anbieten. Dabei wird mit TLS (=TransportLayerSecurity: der moderne Nachfolger von SSL (=SecureSocketLayer) ) verwendet. Jeder Browser bringt eine ziemliche Masse an solchen Zertifikaten mit, weshalb der verschlüsselte Verbindungsaufbau problemlos und ohne Zutun klappt.
Manchmal stösst man auch auf HTTPS Verbindungen bei denen der Browser warnt, weil das Zertifikat selbst erstellt und beglaubigt ist. Das kann man dann akzeptieren oder ablehnen.
Selbstsignierte Zertifikate unterscheiden sich von den "allgemein gültigen" nur darin, dass die CA (CertificateAuthority) einmal bereits dem Browser bekannt und von ihm akzeptiert ist, das zweite Mal eben nicht.
Und es gibt bei den Zertifikaten noch ein Feld, das die Verwendung bestimmt. Das kann einfach die Verschlüsselung der Verbindung sein, oder -und jetzt sind wir endlich bei diesem TLS-Clientcertificate- eben die Verschlüsselung UNGD GLEICHZEITIG die Authentifizierung.
Dazu betreibt der Provider nun selbst eine CA (die wiederum durch bekannte CAs zertifiziert ist, oder importiert werden muss). Er erstellt dann für jeden Mailnutzer ein solches Zertifikat und konfiguriert seine Server so, dass die Userauthentifizierung damit ebenso erledigt wird, nicht nur die Transportverschlüsselung.
Wie das wirklich gemacht wird, sei dahin gestellt, und kann auch nicht gewußt werden. (Wie bei der Auflösung von mail.macbay.de zu einer oder vielen IPs.)
Egal, wie das nun wirklich implementiert ist, ist aber auf jeden Fall Voraussetzung, dass du von denen genau dieses Zertifikat erhalten hast UND importiert hast.
Da das nun wirklich kaum verwendet wird, habe ich das selbst noch nicht gemacht (und kann es nicht testen; dazu müsste ich bei denen einen Account haben). Ich weiß also nicht, ob das dann Kmail selbst speichert, oder, wie ich vermute, irgendwo in den Systemeinstellungen der '"persönlichen Informationen" systemweit vorhält.
Ist das so?
Musstest du je ein solches Zertifikat irgendwie reinpfrimmeln?

Wenn nicht, dann ist diese Aussage des Providers falsch: "WICHTIG: Die Identifizierung ist stets: Extern (TLS-Clientzertifikat)"
Oder meint damit etwas ganz anderes, was erst zu klären wäre.
Stelle also, wie oben geschrieben deinen IMAP- Zugang auf startTLS für Port 993 um,
und gucke, ob das dann geht.
Wenn das einfach geht UND du kein Providerzertifikat hinzugefügt hast, ist die Aussage Quatsch, aber IMAP tut wenigstens verschlüsselt.
Wenn das nicht geht, frage beim Provider nach, was dieses Zertifikat genau sein sollte.
Normal ist das nicht.
(Diese "persönlichen Zertifikate" zur Userauthentifizierung sind ziemlich umständlich zu handhaben, weshalb sie nur in Hochsicherheitsszenarien eingesetzt wurden. Aber auch da hat man mittlerweile "einfachere" Methoden.)

Ich mag jetzt nicht weiter beschreiben, wie das Zusammenspiel zwischen MTA und IMAP sein könnte.
Es ist einfach zu komplex.
Aber klar ist, dass unter mail.macbay.de mindestens zwei ziemlich verschiedene Teile werkeln.
Damit du Mails auch mit diesem TLS-Clientcertificate versende kannst, müsste dein lokaler MTA (ja, bei dir läuft auch mindestens ein MTA - vermutlich postfix) auch genau dieses Zertifikat verwenden,
ODER
(was sehr viel einfacher wäre) sie verlassen sich auf das POPbeforeSMTP.
Das heißt nichts anderes, als dass der Provider MTA eine Mail von dir nur zum Versand akzeptiert, wenn kurz vorher eine erfolgreiche Verbindung zum POP/IMAP aufgebaut worden ist.
Dazu wird einfach eine zeitlich limitierte Liste vom POP/IMAP- Server geführt, auf die der MTA dann im Bedarfsfall zugreift. Wieder eine Überschneidung zwischen MTA und POP/IMAP.
In Konsequenz heißt das, dass du vor dem Versandversuch auf jeden Fall erst nach neuen Emails gucken lassen sollst.

Jetzt bin ich mal gespannt, was da als Antwort kommt.