KeyHelp Community

In Bezug auf den OffTopic Beitrag von mir: viewtopic.php?f=14&t=10334

Würde ich das doch gerne als Funktionswunsch äußern.

Vorstellen könnte ich mir einen Einstellmöglichkeit, SMTPS in den Mailservereinstellungen zusätzlich/optional zu aktivieren.

Leider ist der Port doch noch beliebter als ich mir das wünschen würde und alle Provider bieten den auch immer noch an. Auch wenn ich mir mehr Druck durch die "großen" Provider wünschen würde, damit gewisse Mailclienten endlich eine Anpassung bekommen.

Vielen Dank

Gruß Arne

ShortSnow wrote: ↑Thu 24. Jun 2021, 18:10 Leider ist der Port doch noch beliebter als ich mir das wünschen würde und alle Provider bieten den auch immer noch an. Auch wenn ich mir mehr Druck durch die "großen" Provider wünschen würde, damit gewisse Mailclienten endlich eine Anpassung bekommen.

Naja du gehst mit deinem Wunsch aber auch in die falsche Richtung.
Vieles ändert sich erst dann, wenn andere, kleine, damit anfangen.
Einer muss den Stein ins rollen bringen.
**huiiiii**

Mit deinem Wunsch passt du dich jediglich an und bewirkst nichts.

Ich verstehe eure Probleme eh nicht
Keins meiner Mailprogramme hat je Probleme gemacht, mag aber vieleicht auch dran liegen das ich kein Outlook, GMail und Co Werkskram nutze.

Gruß Olli

+ 1 (Erläuterung von mir habe ich ja im anderen Thread geschrieben)

OlliTheDarkness wrote: ↑Thu 24. Jun 2021, 18:19 Ich verstehe eure Probleme eh nicht
Keins meiner Mailprogramme hat je Probleme gemacht, mag aber vieleicht auch dran liegen das ich kein Outlook, GMail und Co Werkskram nutze.

Geht hier und im anderen Thread auch hauptsächlich um Endkunden und deren unterschiedlichsten Setups. Wenn es nur ein Kunde wäre, drauf gesch****, aber das Thema kommt immer wieder auf und wird zum Zeitfresser. Gerade beim Thema E-Mail haben Kunden manchmal eine sehr kurze Zündschnur, wenn irgendwas nicht klappt (auch wenn die Ursachen in den allermeisten Fällen auf deren Seite liegen)

Zunächst vorweg, ich schwanke noch, ob ich die "Faulheit (?)" der großen Mailprovider / Mailapps mit der Öffnung des Ports unterstützen möchte oder nicht .

Ich würde euch zunächst erstmal raten, die entsprechenden Änderungen - sofern ihr sie benötigt - in der master.cf selbst vorzunehmen + den Port in der Firewall freizugeben.
Die master.cf wurde in der Geschichte der KeyHelp-Updates vll. 1-2 mal im Zuge eines Updates angerührt und wenn dann nur punktuell, die ist also ziemlich Updatesicher.

Ggf. möchte einmal jemand die notwendigen Änderungen ein wenig ausführlicher in der Bastelecke für die Nachwelt festhalten .

Alexander wrote: ↑Fri 25. Jun 2021, 09:22 Zunächst vorweg, ich schwanke noch, ob ich die "Faulheit (?)" der großen Mailprovider / Mailapps mit der Öffnung des Ports unterstützen möchte oder nicht .

So Lob ichb mir das

Info: Der Title ist falsch


Moin zusammen,
da mir die Geschichte hier keine Ruhe lässt und ich gern das Problem verstehen würde, mich jedoch weigere Outlook und Co. zu installieren, möchte ich das mal aus meiner Sicht durchgehen wie es laufen soll aber scheinbar bei euch nicht tut.

Korrekturen meiner Ansicht bzw. erklärung der tatsächlichen Verhaltensweise würden mich freuen und ev. mir helfen euch zu verstehen.

Szenario Start

Vorgehen des Users:
Ich erstelle mir im KeyHelp eine Emailadresse, z.B abc@ihateoutlook.de.

Nun starte ich Outlook / Gmail oder sonst einen eurer Problemkinder Clients.

Dort wähle ich "Neue Emailadressse hinzufügen" oder wie es auch heißen mag.

Es öffnet sich die Eingabemaske auf welcher ich die Adresse eingebe. (abc@ihateoutlook.de)

SOLL Vorgehen des Mailclients:
Der Client verbindet zum zuständigen Server und testet die Mailports durch (995, 993, 465, 143, 25 & 587).

Der erste antwortende wird genutzt bzw. dem User die Wahl gegeben.

Der Client fordert vom User das Kennwort an, sendet es zum Server, verbunden, FERTIG.

SOLL Vorgehen des Users:
Nach der Kennworteingabe , glücklich sein und Happy Mailing.

----------------------------------------------------------------------------------------------------------

Scheinbares IST Vorgehen des Mailclients:
Der Client verbindet zum zuständigen Server und testet nur den Mailport 465.

Dieser antwortet nicht und der Client meldet "Keine Verbindung möglich" oder sonst was.

Szenario Ende

Meiner Meinung nach sollte der User jetzt die Möglichkeit haben die V erbindungseinstellungen von Hand anpassen zu können.

Die nötigen Verbindungsdaten liefert Keyhelp hinter jeder eingerichtetetn EMail Adresse
Damit ist alles was man brauch geklärt und lässt keine Fragen offen.

Von meiner Seite aus ist das 0%ig ein KeyHelp Problem, sondern eines eurer verwendeten Clients die 2021 noch so dumm sind und veraltete Ports nutzen.

Somit komme ich nur auf 1 Ergebnis, egal wie ich es drehe und wende.

Entweder sind eure "Kunden" nicht in der Lage lesen zu können (den von Port 465 steht nichts in den Verbindungsdaten bei KH) oder aber , falls der Kunde kein KeyHelp Zugang hat und Ihr die Einrichtung macht, seid nicht in der Lage euren Kunden die Verbindungsdaten richtig zu Kommunizieren.

Wenn sich jetzt jemand auf die Krawatte getretten fühlt, shit happens, thats reallife und kein Wünsch dir was Bälleparadies.

Hier sind eindeutig die Client Entwickler in der Pflicht, kein anderer !
Gruß Olli

Das betrifft ja wohl nur die mobilen Clients. Die Desktop-Version von Outlook kann sehr wohl Port 587 und STARTTLS nutzen. Die Android App kann es wohl nicht (k.A., warum sollte ich so ein Zeug auf meinem Handy nutzen?) Die Gmail App probiere ich jetzt gleich mal aus, die ist ja als Standard-Mail App in Android vorinstalliert . (%&%§&-Android = Google Daten-Sammeltool Nr. 1)

tab-kh wrote: ↑Fri 25. Jun 2021, 14:15 Das betrifft ja wohl nur die mobilen Clients. Die Desktop-Version von Outlook kann sehr wohl Port 587 und STARTTLS nutzen. Die Android App kann es wohl nicht (k.A., warum sollte ich so ein Zeug auf meinem Handy nutzen?) Die Gmail App probiere ich jetzt gleich mal aus, die ist ja als Standard-Mail App in Android vorinstalliert . (%&%§&-Android = Google Daten-Sammeltool Nr. 1)

Moin, ich hab es extra allgemein gehalten.
Meine Aussage bezieht sich genau so auf die Mobilen Clients

Es mag sein, dass Port 465 schon seit Jahren deprecated ist.
Fakt ist aber auch, dass Port 465 immer noch quasi Industriestandard ist.

Weder liegt die Schuld bei KeyHelp, noch beim Admin oder irgendwelchen Softwareentwicklern.
Solange dieser Port bei den Major-Providern noch in Betrieb sind, so lange wird der Standard-Kunde (ich will doch nur, dass es funktioniert) diesen Port auch verwenden.

Ich habe das "E-Mail-Einrichtungsproblem" sogar bei internetaffinen Kunden. Das geht schon los mit STARTTLS (was ist das?) und warum gibt es kein SSL? Warum kann der Postausgangsserver keine Verschlüsselung? Uns so weiter und so fort.

Viele Kunden verwenden einfach die vorinstallierte Standardsoftware. Und ja, Kunden verwenden auch die Outlook App. Und nein, diese Kunden wollen kein Vorschlag welche App denn wohl besser sei, die wollen einfach dass es geht.

Hmm, die Gmail Android App kann mit der E-Mail-Adresse von meinem Keyhelp-Server eingerichtet werden, senden von Mail und Zugriff per IMAP funktioniert. Aber jetzt kommt das (mehr oder minder) Lustige: Ich habe den einen Keyhelpserver, auf dem das Postfach liegt als Server angegeben und die App behauptet beim Einrichten, dass das Zertifikat des Servers auf meinen anderen Keyhelpserver ausgestellt sei. Was ist da los? Die Server gehören zur selben Domain, ist das ein Problem, was nur Gmail merkt? Oder macht die App da was falsch? Immerhin hat sie den Namen meines anderen Servers ausgespuckt, der erst nach dem "richtigen" Server installiert wurde. Ich habe dann eingegeben, dass die Einrichtung trotzdem durchgeführt werden soll und die App hat mir dann wieder die Maildomain als Servernamen eingetragen. Das nochmal korrigiert und danach funktioniert es erst mal. Das Zertifikat des Servers ist auch auf korrekt auf den Servernamen ausgestellt. Hätte mich auch gewundert, nach all den Tests mit verschiedenen Tools, dass da nie was aufgefallen wäre.

Tobi wrote: ↑Fri 25. Jun 2021, 14:29 ...
Viele Kunden verwenden einfach die vorinstallierte Standardsoftware. Und ja, Kunden verwenden auch die Outlook App. Und nein, diese Kunden wollen kein Vorschlag welche App denn wohl besser sei, die wollen einfach dass es geht.

Aber auch

vorinstallierte Standardsoftware

hat sich dem zahn der Zeit anzupassen.
Da stur nur einen Port zu prüfen und dann rumzuheulen weil keiner antwortet ist , beim heutigen Stand der Möglichkeiten, nen K.O Punkt.

Wenn man seinen Usern dann noch ordentlich erklärt , warum es so ist, dass es der Sicherheit dient bla bla bla wird kein User sagen "is mir scheiß egal das hat gefälligst zu laufen", sondern aktzeptieren weil man sein bestes will.

Als Betreiber, dem Sicherheit einen höheren STellenwert hat als Bedienungskomfort, kann es nicht sein das ich mir von Apps etc. diktieren lassen wie ich was zu konfigurieren habe.

Im übrigen, den 465er einfach auf nen offenen anderen Mailport Forwarden tuts auch.

Naja, die Outlook-App macht eben auch noch andere Dinge außer als miserabler Mail-Client zu fungieren. Das hat MS mal wieder geschickt eingefädelt, alles integriert, wie sie es eben seit den seligen IE-Zeiten schon immer gemacht haben. Da kann ich die Kunden schon verstehen, die in ihrem Unternehmen Outlook verwenden, dass sie dann eben auch diese (mailmäßig unfähige) Outlook-App verwenden wollen. "Normale" Email-Konten sind da sowieso bestenfalls nur noch geduldet, aber nicht (mehr) wirklich voll unterstützt in der schönen, neuen, in sich mehr oder minder abgeschlossenen Microsoft 365 Welt.

Als erstes möchte ich gerne folgendes Zitieren aus https://www.privacy-handbuch.de/handbuch_31c.htm:

Das STARTTLS wurde als Erweiterung für bestehende Protokolle entwickelt, um TLS Verschlüsselung für unterschiedliche Domains mit unterschiedlichen Zertifikaten auf einem Server anbieten zu können. Es wurde nicht mit der Zielstellung entwickelt, die Sicherheit von SSL/TLS zu erhöhen. Man sollte sich nicht irritieren lassen und evtl. schlussfolgern, dass "old-style TLS" veraltet sein könnte.
Auch die IETF empfiehlt in RFC 8314 "SSL/TLS" gegenüber "STARTTLS" zu bevorzugen.

Damit sind wir meiner Meinung nach mit SMTPS nicht bei eine alten und grundsätzlich verabscheuungswürdigen Technik, wie es hier bei einigen Kommentaren dargestellt wird. Es mag nicht "State of the Art" sein, aber auch nicht veraltet wie BTX.

OlliTheDarkness wrote: ↑Fri 25. Jun 2021, 14:49 ...
Wenn man seinen Usern dann noch ordentlich erklärt , warum es so ist, dass es der Sicherheit dient bla bla bla wird kein User sagen "is mir scheiß egal das hat gefälligst zu laufen", sondern aktzeptieren weil man sein bestes will.
...

Doch, das ist so. Da kannst Du Deine Meinung auch sooft wiederholen wie Du möchtest. Sie ja auch nicht falsch. Es macht, wenn man Kunden hat die genauso "stur" in Ihrer Meinung sind wie Du, einfach nur unnötigen Ärger und kostet Zeit, die man sinnvoller investieren kann. Und das STARTTLS sicherer ist als SSL, ist nicht erwiesen. Es ist ja nun wirklich nicht so, das man damit direkt ein openRelay erzeugt oder schlimmeres . Wenn man Deine Kommentare liest, könnte man ja glauben damit geht die Welt unter

Alexander wrote: ↑Fri 25. Jun 2021, 09:22 Zunächst vorweg, ich schwanke noch, ob ich die "Faulheit (?)" der großen Mailprovider / Mailapps mit der Öffnung des Ports unterstützen möchte oder nicht .

Ich würde euch zunächst erstmal raten, die entsprechenden Änderungen - sofern ihr sie benötigt - in der master.cf selbst vorzunehmen + den Port in der Firewall freizugeben.
Die master.cf wurde in der Geschichte der KeyHelp-Updates vll. 1-2 mal im Zuge eines Updates angerührt und wenn dann nur punktuell, die ist also ziemlich Updatesicher.

Ggf. möchte einmal jemand die notwendigen Änderungen ein wenig ausführlicher in der Bastelecke für die Nachwelt festhalten .

@Alexander: Gebe ich Dir grundsätzlich recht. In Bezug darauf, das Keyhelp auch noch Reseller tauglich werden soll und damit dann noch mehr Endkunden anzieht, ist es evtl. wirklich sinnvoll darüber nachzudenken. Weil es nunmal irgendwie doch alle Mailanbieter noch anbieten und es hier auch wieder empfohlen wird: https://datatracker.ietf.org/doc/html/rfc8314

Man kann es leider nicht wirklich jedem User erklären, warum das quasi überall noch Standard ist, nur bei den "kleineren" nicht.

Gruß Arne

Ich schmeiße mal https://www.golem.de/news/verschluessel ... 58714.html in den Raum

Wenn ich mir den dort verlinkten https://datatracker.ietf.org/doc/html/rfc8314 so anschaue, ist SSL/TLS auf 465 durchaus empfohlen

Jupp,

für Submisison-SMTP mit TLS wurde der Port 465 inzwischen offiziell abgesegnet, siehe RFC 8314 und IANA-Liste.

Gruß Arne