Jump to content

https Website für Media Server?


pib751

Recommended Posts

Ich habe jetzt mehr als die Hälfte der OpenSSL-Konfigurationsdatei-Inhalte rausgeworfen, die Anzahl Dateien von vier auf zwei reduziert, und es funktioniert immer  noch! Der größte Teil der Vorlagen war wohl für meine Zwecke überflüssig. Damit ist die Angelegenheit schon wesentlich übersichtlicher. Bei einigen der verbliebenen Angaben verstehe ich inzwischen sogar, wofür sie gut sind.

 

Zudem habe ich die Konfiguration etwas umstrukturiert, so dass sich die Datei nun wie eine Windows-INI-Datei lesen und schreiben lässt. Damit kann dann auch ein Installer oder der DMS selbst dort mit vertretbarem Aufwand eingreifen.

 

vor 5 Stunden schrieb MaM:

Mach, was Du willst, aber "beglücke" uns auf keinen Fall automatisch mit dem Mist!

Nicht bei Installation oder Update ein Zertifikat generieren und auch noch direkt auf die Welt loslassen!

 

Manchmal muss man Anwender zu ihrem Glück zwingen. Ich habe mir doch nicht so viel Mühe gegeben, nur damit Leute es am Ende nicht benutzen! So einen aufgesetzten Kram wie Reverse Proxies brauchst du ab der nächsten Version nicht mehr :)

 

Link to comment
vor 37 Minuten schrieb Griga:

Manchmal muss man Anwender zu ihrem Glück zwingen. Ich habe mir doch nicht so viel Mühe gegeben, nur damit Leute es am Ende nicht benutzen! So einen aufgesetzten Kram wie Reverse Proxies brauchst du ab der nächsten Version nicht mehr :)

 

Hauptsache, der Dreck ist abschaltbar. Mein Vertrauen in Dein Verständnis der Materie ist sehr beschränkt bzw. nicht vorhanden.

(wobei der Reverse Proxie eh nur ne billige Ausweichmaßnahme war, ich steh da auch nicht so drauf, aber er ist halt da und umsonst)

Edited by MaM
Link to comment
vor 6 Stunden schrieb MaM:

Hauptsache, der Dreck ist abschaltbar. Mein Vertrauen in Dein Verständnis der Materie ist sehr beschränkt bzw. nicht vorhanden.

 

Da weiß mal jemand meine Arbeit wirklich zu schätzen :D

 

Aber gut, weil du es bist: Ich werde für dich einen Button einbauen, beschriftet mit "MaM". Der schaltet dann alles ab. Ich möchte ja nicht daran schuld sein, wenn du unter cholerischer Hypertonie leidest.

 

Spaß beiseite und @alle anderen HTTPS-Interessierten: Mit der Installer-Skriptsprache eine benutzerdefinierte OpenSSL-Konfiguration zu bewerkstelligen ist mir zu anstrengend. Mir schwebt eher eine neue HTTPS-Konfigurationsseite in den DMS  Optionen vor, wo man die relevanten Domain-Namen / IP-Adressen eingeben und optional mittels Button die Erzeugung der entsprechenden Zertifikate anstoßen kann.

 

Link to comment
vor 39 Minuten schrieb Griga:

Mir schwebt eher eine neue HTTPS-Konfigurationsseite in den DMS  Optionen vor, wo man die relevanten Domain-Namen / IP-Adressen eingeben und optional mittels Button die Erzeugung der entsprechenden Zertifikate anstoßen kann.

Jo, DAS klingt gut! Den muss man dann ja nicht drücken.

Nur sorg dafür, dass man auf jeden Fall Zerts OHNE Key und OHNE Passwort einspielen kann, denn nur diese gibt es in freier Wildbahn.

Edited by MaM
Link to comment
vor 12 Stunden schrieb Griga:

 

@alle anderen HTTPS-Interessierten:  [..]

 

 

... und wofuer braucht das ernsthaft die Hauptzielgruppe der DVBViewer-Anwender?

 

/Ironie On

 

Vielleicht um im Privatkino auf dem Kreuzfahrtschiff mit verschlüsselt übertragenen und auf 16 kbit runter transkodierten Schmuddelfilmchen aus den 70ern angeben zu können?

 

/Ironie Off

 

Https ist mir schon einigermassen klar. Aber noch nicht wirklich als grosser Mehrwert für die Zielgruppe der DVBViewer, bei denen sich das meiste im eigenen Haushalt abspielt.

 

SCNR, Goggo

Edited by Goggo16
Link to comment
vor 2 Minuten schrieb Goggo16:

... und wofuer braucht das ernsthaft die Hauptzielgruppe der DVBViewer-Anwender?

 

Soweit ich weiß, ist es insbesondere für Leute wichtig, die über das Internet auf das Webinterface zugreifen, um z.B. Timer zu programmieren oder zu kontrollieren. Es gibt Anwender, die beruflich oder aus anderen Gründen viel unterwegs sind oder einen zweiten Wohnsitz haben.

 

Dass der DMS HTTPS beherrscht, erspart in solchen Fällen die Einrichtung eines Reverse Proxy, was viele überfordert.

 

Link to comment

Danke fuer die Antwort.

 

VPN tut es für solch vereinzelte Anwendungen ja auch. Ist ja inzwischen nix mehr besonderes auf mobilen Geraeten wie auch auf dem Router daheim. Braucht halt ein paar mehr Klicks.

 

LG, Goggo

Link to comment
vor 8 Minuten schrieb Goggo16:

VPN tut es für solch vereinzelte Anwendungen ja auch.

Jojo, auch IPSec alleine wäre schon sein Freund. Aber, er befindet sich im Moment in einem Zustand der geistigen Verblendung und will alles selber verschlüsseln, egal, wie unsinnig und doppelt-gemoppelt es auch sein mag.

Niemand wird es verwenden, ich hoffe nur inständig, er macht es so, dass es die normalen Wege nicht be- oder gar verhindert...

 

Edited by MaM
Link to comment
vor 4 Stunden schrieb Goggo16:

VPN tut es für solch vereinzelte Anwendungen ja auch.

 

Wieso vereinzelt? Hast du Zahlenmaterial? Hast du mittels Forumsuche ermittelt, wieviele Posts es zu dem Thema in den letzten Jahren gegeben hat? Oder vermutest du nur?

 

Es gab jedenfalls schon öfters Anlass, VPN im Forum zu empfehlen (Tjod hat das früher mehrfach gepostet , aber auch ich), ebenso wie die Verwendung von Reverse Proxies, gerade weil der DMS bislang kein HTTPS konnte. Ziel war nun, dass er in der Hinsicht auf eigenen Füßen steht und keine externen (d.h. zusätzlich zu installierenden und zu konfigurierenden) Ergänzungen braucht, von denen man ja erst mal wissen muss, dass es sie gibt und wo es sie gibt, wie sie funktionieren und wie sie zu handhaben sind. Ich habe z.B. noch nie mit VPN zu tun gehabt und müsste das Thema erst mal recherchieren bzw. andere um Rat fragen.

 

Außerdem kommt die hiesige Software nicht nur im privaten, sondern auch im semi-professionellen und professionellen Bereich zur Anwendung. Wenn eine Firma sagt, wir wollen Lizenzen für 50 Arbeitsplätze erwerben, brauchen aus Datenschutzgründen aber zwingend HTTPS, dann landet das letztendlich bei mir ;)

 

Davon abgesehen lag es nahe, HTTPS im DMS jetzt anzugehen, weil ich mich für den DMS und DVBViewer als HTTPS-Client ohnehin mit mit dem Thema (und insbesondere OpenSSL) auseinandersetzen mussste. Eine ganze Anzahl Internet-TV/Radio-URLs gibt es nur noch als HTTPS. Die hier angesprochenen Arbeiten sind inzwischen erledigt, und HTTPS im Webserver zu ergänzen war danach im Prinzip eine Kleinigkeit - nicht mehr als ein paar Zeilen Code. Der Teufel steckt aber wie so oft in Details, die viel Zeit verschlingen.

 

Dazu hat man, wenn man ein solches Thema öffentlich im Forum zur Diskussion stellt, leicht einen der überaus beliebten Besserwisser am Hals, die sich gerne danebenstellen, wenn andere arbeiten, penetrant ihren Geltungsdrang inszenieren, indem sie alles als falsch und sinnlos bezeichnen, man müsse das nicht so, sondern ganz anders machen... falls es noch mal zu einem öffentlichen "Arbeitsthema" kommt, werde ich Desinformations-Störmanöver in dieser Häufung konsequent ausschließen, notfalls mit magischer Moderatorenpower. Soweit meine guten Vorsätze :)

 

Link to comment

Ich kann Deinen Frust irgendwie verstehen, but heck, it's funny as hell, euch zwei argumentieren zu sehen.B)

 

Edit:

Und, glaub es oder nicht, wir lernen echt was dabei.

Edited by spachti
Link to comment
vor 12 Stunden schrieb spachti:

Ich kann Deinen Frust irgendwie verstehen, but heck, it's funny as hell, euch zwei argumentieren zu sehen.

 

Freut mich ja, dass es Unterhaltungswert hat :)

 

Frust ist zuviel gesagt - so sehr beeinträchtigt mich das persönlich nicht. Für mich steht das Thema im Mittelpunkt. Ich erhoffe mir von solchen Diskussionen, dass sie für die Arbeit und den Media Server etwas bringen. Deshalb hätte ich mir mehr konstruktive Mitwirkung von Anwendern gewünscht, die schon Erfahrungen in dem Bereich gesammelt haben - anfangs gab es das von @VinoRosso und @waldi801. Auch eine kritische Nachfrage "und wofür braucht man das?" kann hilfreich sein, weil die Formulierung der Antwort einen dazu zwingt, selbst darüber Klarheit zu erlangen.

 

Wenn jedoch Beiträge nur destruktiv pauschale Ablehnung ausdrücken oder gar in einem "ich habe die Ahnung und du keine"-Stil Hinweise geben, die sich beim Ausprobieren oder bei eigenen Recherchen größtenteils als Fake herausstellen, behindert das die Arbeit und ist - abgesehen vom Unterhaltungswert - für meine Zwecke schlichtweg überflüssig.

 

Link to comment
vor 17 Stunden schrieb Griga:

 

Wieso vereinzelt?

[..]

Außerdem kommt die hiesige Software nicht nur im privaten, sondern auch im semi-professionellen und professionellen Bereich zur Anwendung. Wenn eine Firma sagt, wir wollen Lizenzen für 50 Arbeitsplätze erwerben, brauchen aus Datenschutzgründen aber zwingend HTTPS, dann landet das letztendlich bei mir ;)

 

 

Interessant. Hatte bislang gedacht, dass der Hauptteil der Anwender im privaten Umfeld angesiedelt sind.

 

@Spachti ... ging mir auch so ... 

Link to comment
vor 2 Minuten schrieb Goggo16:

Hatte bislang gedacht, dass der Hauptteil der Anwender im privaten Umfeld angesiedelt sind.

 

Das ist womöglich auch richtig - ich kenne in der Hinsicht keine Statistik. Müsste man bei Bernd Hackbart erfragen. Ich weiß nur aus dem Forum, dass schon relativ oft Anwender das Thema "Webserver-Zugriff aus dem Internet" angesprochen haben. Das gibt es also nicht so selten.

 

Link to comment

Das hatte ich auch so mitbekommen. Daher wurde ja auch die Methode "Mindestens nur mit Passwort, aber besser mit VPN"  häufiger empfohlen. Dabei war ja dann wohl auch die funktionale Trennung von Admin und Gast-User entstanden.

 

Ich nutze das selbst gelegentlich mal von unterwegs. Dann aber mit dem Smartphone per VPN zum heimischen Router. Sind ein paar "Touchs" und schon ist man "geschützt" auf dem heimischen DMS - und noch mehr.

Link to comment

Warum es mich interessiert?

Mein Mediaserver steht in Deutschland, mein Popo sitzt in den Staaten:rolleyes:

So, jede Moeglichkeit, das Streamen besser,  und vor Allem, sicherer zu machen, ist hoechst willkommen.

Andererseits habe ich kein IT-Diplom, deshalb sollte es auch fuer Dummies ( ok, technisch interessierten Laien mit PC Erfahrung :D )  machbar bleiben.

Edited by spachti
Link to comment

So soll die Konfiguration in Zukunft aussehen:

 

Zwischenablage01.png

 

Die Zertifikatserzeugung hat jetzt ein richtiges UI, so dass man nicht mehr OpenSSL-Konfigurationsdateien editieren muss. Nur für das Installieren des Stammzertifikats auf Client PCs muss man noch zusätzlich hantieren. Ich hoffe, die Sache ist so einigermaßen selbsterklärend.

 

Link to comment
Am 8.9.2019 um 13:44 schrieb MaM:

Na ja, das ist a) 1&1 und b) Port 587. Das hat nix mit "richtigem" SMTP zu tun, 587 ist für "interne Kommunikation" vorgesehen, da kochen die Mailer ihr eigenes Süppchen und lassen normalerweise alle Hüllen und Checks fallen (587 soll nur im LAN verwendet werden, bzw. "im eigenen Netz").

 

Naja, so ganz stimmt das nicht. Port 587 wird von allen neueren (seit 1998) SMTP-Servern als Standardport bei STARTTLS-Verschlüsselung verwendet. Und auch für die unverschlüsselte Verbindung wird empfohlen, Port 587 anstelle von Port 25 zu verwenden - letzterer wird sogar immer häufiger aus Sicherheitsgründen von vielen Anbietern gesperrt. Standardport bei SSL/TLS ist 465. Deswegen verstehe ich den Sinn der Aussage "587 soll nur im eigenen Netz verwendet werden" nicht.

Link to comment
vor 11 Stunden schrieb SnoopyDog:

Deswegen verstehe ich den Sinn der Aussage "587 soll nur im eigenen Netz verwendet werden" nicht

Hmm, ok, ihr habt alle die Gnade der späten Geburt, ich muss deshalb wohl etwas weiter ausholen. Und ich geb zu, die Bezeichnung "lokal" ist verwirrend. "lokal" bezieht sich bei mir auf die Verbindung "Postfach <> Server", also wo die Daten gespeichert sind.

 

Wir müssen hier strikt trennen zwischen "Server <> Server" Zustellung (Mailverteilung / ggf Relaying) und den Abruf durch Klienten.

 

Als alter Serverbetreiber interessiert mich immer nur der erste Punkt, Server<>Server. Und das geht weiterhin nur über Port 25 (465 wird vorgeschlagen, aber der Verbreitungsgrad ist doch arg überschaubar, kaum vorhanden). Da macht man brav "EHlo" (Aktivere ESMTP Protokoll) und passt auf, ob der Gegenpart STARTTLS offeriert. Das kann man dann benutzen, oder auch nicht. Auf jeden Fall bleiben wir immer auf Port 25.

 

"Abruf/Einlieferung durch Klients" hingeben wurde ausgelagert auf 587. Die Idee dahinter war, dass "lokale" Klienten um den Spam und Relay Check auf Port 25 rumkommen können. Denn die Blacklists enthalten so ziemlich alle dynamischen IP Adressen, die User würden also abgewiesen auf dem Standardport.

 

Mailserver, die das implementieren, wie z.B. Microsoft Exchange generieren bei der Installation schon gleich entsprechende Regeln und sorgen dafür, dass Server von 587 abgehalten werden. Ich mach mal ein paar Screenshots von einer unveränderten Installtion (leider sind die Einstellungen auf mehrer Tabs, ... ach quatsch, ich nehm mal Photoshop und pack alles in ein Bild zusammen... mompls)P587.thumb.jpg.ea441ff67b1f563bfda7b411bb186e3f.jpg

Also hier sehen wir den Empfänger für Port 587. Er gilt für ALLE Adressen, AAAABER... guck auf die rechte Seite.... den dürfen nur VERSCHLÜSSELTE Exchange Benutzer verwenden.

Du musst also eine Verbindung entweder direkt mit TLS oder STARTTLS verwenden, danach dich als Benutzer an dem Server anmelden, erst dann kommst Du auf das Postfach.

Andere Server (Exchange-Server wären Replikanten irgendwo) oder gar "anonyme Benutzer" (Server<>Server ist immer anonym, geht ja gar nicht anders) sind verboten und werden auf dieser Verbindung nicht akzeptiert.

Andere Mailserver haben eine ähnliche Konfiguration.

Deshalb die Aussage "nur lokale Klienten", sie mag heute etwas unglücklich sein, weil ein "lokaler Klient" auch irgendwo im Internet sein kann, aber auf jeden Fall dient sie nicht dazu Mail zuzustellen, sondern nur zum Abrufen oder Einliefern direkt beim Heimatserver.

Aber ich geb zu, wer die Historie nicht kennt, versteht es nicht so einfach.

Ich spar mir jetzt die Screenshots für Port 25. Glaub mir einfach, es ist dort genau UMGEKEHRT. Da sind alle erlaubt, auch die anonymen, AUSSER "Exchange-Benutzer". Man kann damit also Mails von anderen Servern einliefern, aber nicht auf lokale Postfächer zugreifen.

 

PS: NIEMALS 587 ohne diese Einschränkungen offenlassen! Du wärst in kürzester Zeit die größte Spamschleuder der Republik!

PPS: 465 hat im Prinzip dieselben Einschränkungen, allerdings erlaubt Exchange hier noch den Zugang für andere Exchange Server, die in derselben Domäne sind. Hierüber läuft dann die interne (auch diesmal kanns wieder übers Internet gehen, aber eben so als "Filiale einer Hauptstelle") Replikation der Server und der Austausch der Datenbanken). Aber sonst ist das Klientenzugriff wie 587 nur mit Zwangs TLS.

PPS: (für den ungläubigen Griga): "lustig" ist der Punkt "extern gesichert (z.B. mit IPSec)". Aktiviert man den, wird TLS komplett DEAKTIVIERT. Der Server geht dann davon aus, dass schon jemand Anderes für die Verschlüsselung zuständig ist und kümmert sich nicht mehr selber darum!

 

Bei der Server<>Server Kommunikation kommen inzwischen ganz andere Methoden zum Einsatz, z.B DKIM, das über DNS Einträge abgesichert wird.

Das sieht dann so aus (Mail von Google User an mich):

Oct 14 10:49:39 MaMster sm-mta[18484]: STARTTLS=server, relay=mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20:0:0:0:330], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Oct 14 10:49:40 MaMster sm-mta[18484]: x9E8ndx0018484: from=<XXX@gmail.com>, size=2283, class=0, nrcpts=1, msgid=<CABQeJxFQgHXPy0Cb9kf1fze1n8ge0V-tV-JPs89QL4msBzVQZw@mail.gmail.com>, proto=ESMTPS, daemon=IPv6, relay=mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20:0:0:0:330]
Oct 14 10:49:40 MaMster opendkim[747]: x9E8ndx0018484: DKIM verification successful
Oct 14 10:49:40 MaMster opendkim[747]: x9E8ndx0018484: s=20161025 d=gmail.com SSL
Oct 14 10:49:40 MaMster sm-mta[18484]: x9E8ndx0018484: Milter insert (1): header: Authentication-Results:  MaMster.Werries.De;\n\tdkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=AR754rAW
Oct 14 10:49:40 MaMster mimedefang.pl[11728]: x9E8ndx0018484: MDLOG,x9E8ndx0018484,mail_in,,,<XXXXh@gmail.com>,<michael@meiszl.de>,asasdas

(und wieder kann Griga was lernen: guck mal, das Zertifikat von Google konnte nicht bestätigt werden! TLS Kram wird nicht gegengeprüft, man kann da reinpacken, was man will)

 

Edited by MaM
Link to comment
  1. Ist es nicht nötig, wegen solcher Kleinigkeiten ellenlange, teils in herablassendem Schreibstil verfasste Antworten zu verfassen.
  2. Widersprichst Du Dir jetzt irgendwie selbst.

Mir ging es nur um Deine beiden Falschaussagen "587 soll nur nur im LAN verwendet werden, "bzw. im eigenen Netz"" und "da kocht jeder sein eigenes Süppchen". Diese hast Du verfasst, weil Du einen Screenshot von Grigas Setup mit der Anbindung an einen 1&1 SMTP-Server gesehen hast. Beide Aussagen von Dir sind falsch, weil Port 587 (sowie 465) durch die Bank bei allen Anbietern für SMTP verwendet wird und das auch nicht in deren eigenen Netz, sondern öffentlich. Wären diese Ports anbieterseitig blockiert, könnte man keine Mails per SMTP versenden. So ist das nun mal mit Ports...

Und dass 587 nur "verschlüsselte Exchange Benutzer" verwenden können (warum eigentlich immer Exchange) hab ich doch geschrieben - STARTTLS ist verschlüsselt. Weiterhin wird 587 auch seit einiger Zeit anstelle von Port 25 für unverschlüsselten Zugriff von sehr vielen Anbietern verwendet und Port 25 blockiert. Das ist aber auch wieder kein eigenes Süppchen wie Du schriebst, sondern standardisiert.

 

Und insgesamt ging es in diesem Thread nicht um Grundsätze des E-Mail-Versands, welche man im Selbststudium z.B. bei Wikipedia nachlesen kann, sondern darum, dass der vom Media-Server bereitgestellte Webserver nun auch https können soll.

 

Edited by SnoopyDog
  • Like 1
Link to comment
vor einer Stunde schrieb SnoopyDog:

Ist es nicht nötig, wegen solcher Kleinigkeiten ellenlange, teils in herablassendem Schreibstil verfasste Antworten zu verfassen.

Tscha, das war meiner Hoffnung geschuldet, dass mit einer ordentlichen Erklärung Du Dein fehlerhaftes Wissen erkennen und ergänzen kannst. Manches ist halt historisch gewachsen und kann nur sequentiell verstanden werden, da bestimmte Wege sich als Irrtum rausgestellt hatten und korrigiert wurden.

 

Aber, wenn Du noch nichtmals bereit bist, es durchzuarbeiten, dann ist Hopfen und Malz verloren.

 

Was Dir fehlt ist das Verständnis des Unterschiedes zwischen MAILSERVER (MTA) und KUNDENSERVER(MSA)

Dann les die kurze Wiki dazu  https://de.wikipedia.org/wiki/Mail_Submission_Agent

 

Ich verstehe ja, dass man heute als Kunde erzogen groß wird und den Firmen gnadenlos ausgeliefert ist. 1&1 bietet einen KUNDENSERVER, das hat nichts mit dem wirklichen Mailserver zu tun.

Man kann heute nur noch Postfächer "mieten", Du bist also immer irgendwo bei einer Firma untergebracht und muss das nehmen, was sie Dir vorwerfen. Ich verstehe deshalb, wie man zu solch verqueren Ansichten kommen kann.

 

Aber das heißt noch lange nicht, dass das die Realität ist, es ist nur der Teil, den sie dir gönnen, weil ihnen danach ist.

 

Manche bieten nur Webzugang, manche POP3 (wohl nicht mehr viele) oder IMAP4. Dass bei 1&1 SMTP "gesprochen" wird, ist reiner Zufall. Bald sollen auch die Mailserver in Firmen verschwinden und "in die Cloud" abwandern (gegen Kohle natürlich). Dann wird noch mehr Basiswissen verschwinden.

vor 1 Stunde schrieb SnoopyDog:

warum eigentlich immer Exchange

Wenn ich hier einen Auszug der sendmail.cf quoten würde, würden alle nur schreiend rauslaufen. Exchange ist halt "übersichtlich" für sowas. Und, es ist ein "all in one" Paket, also Mailserver + Postfachserver. Man sieht also beide Seiten gleichzeitig (Sendmail, Exim, Postfix usw sind reine Mailserver, sie bedienden keine Postfächer (und bevor Du wieder meckerst, ja, auf Linux Kisten kann man damit trotzdem Mail senden und empfangen, aber guck genau hin, das sind EXTRA Pakete, die nicht zum Mailserver gehören). Also dachte ich, ein Exchange Screenshot wäre anschaulich.

 

vor einer Stunde schrieb SnoopyDog:

Und insgesamt ging es in diesem Thread nicht um Grundsätze des E-Mail-Versands, welche man im Selbststudium z.B. bei Wikipedia nachlesen kann, sondern darum, dass der vom Media-Server bereitgestellte Webserver nun auch https können soll.

Right, und da scheint Griga nun doch endlich auf meine Linie eingeschwenkt zu sein und sich auf den Webserver konzentriert zu haben. Meine ganzen Warnung gingen ja nur dahin, ihn davon abzuhalten, den Kram auf Streaming usw ausdehnen zu wollen.

 

Link to comment

Schon wieder so eine längliche Antwort. Ich mach es kurz: der einzige, der hier falsches Wissen verbreitet und sich dabei auch noch ständig im Winde dreht bist Du. Deine beiden von mir zitierten Punkte sind falsch. Es ging nicht um MTA und MSA, das kenne ich alles (und noch mehr). Es ging nur darum, dass Du auf Seite 1 dieses Threads zwei Dinge geschrieben hast, die beide falsch sind.

Link to comment
vor 24 Minuten schrieb SnoopyDog:

Schon wieder so eine längliche Antwort

So langsam solltest Du Dich entscheiden, was Du denn gerne willst:

 

a) kurze Antworten, die mißverstanden werden können (vor allen Dingen wenn die zugrundeliegenden Begrifflichkeiten nicht auf beiden Seiten identisch definiert sind)  ?

b) lange Antworten, die zwar klarer sind, auch mit Verweisen auf andere Dokumente, aber mehr Zeit erfordern und bei ADHS Kindern zu erhöhtem Ritalinbedarf führen könnten ?

c) oder gar nichts von den beiden, da Du eh nur rummosern willst und es somit egal ist, was  da steht ? (diesen Punkt wollen wir mal nicht unterstellen)

 

vor 17 Stunden schrieb SnoopyDog:

Port 587 wird von allen neueren (seit 1998) SMTP-Servern als Standardport bei STARTTLS-Verschlüsselung verwendet

DAS ist dann wohl DEINE falsche Aussage? Oder was meinst Du mit "SMTP-Server" ? MTA oder MSA?

 

Les die Wiki  https://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol (keine Angst, ist nicht lang, steht schon oben im zweiten Abschnitt)

 

Spoiler

 

Der entscheidende Quote extra für die Nichtlesenwollenden: " Neuere Server benutzen auch Port 587, um ausschließlich von authentifizierten Benutzern/Servern Mails entgegenzunehmen („Mail Submission Agent“), wobei gewöhnlich... " (wobei ich persönlich keinen "Server" kenne, der dort einliefern darf, da müsste man ja extra einen Account für anlegen...) Das hat also kausal gar nix mit STARTTLS oder MAILSERVER zu tun, kapier es doch endlich. (wobei STARTTLS für 587 EMPFOHLEN ist, aber keine zwingende Vorraussetzung. Username/Passwort hingegen sind Zwang bei 587, womit das Port für den normalen Mailtransfer eben nicht benutzbar wird).


 

 

Und, ich "winde" mich hier nicht rum, ich versuche nur mit unterschiedlichen Ansätzen Dich näher an das Verständnis zu bringen.

 

Also, zurück zu Seite 1... Was sollte da nochmal falsch sein ???

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...