Beiträge von MacLemon

    Über IPv6 ist es, für den Mailaustausch mit Google gehosteten Domains, schon lange Pflicht SPF und DKIM zu unterstützten. Nut bei Legacy-IPv4 wurde das noch eine zeitlang gedulded. Jetzt isses auch bei Legacy-IPv4 Pflicht. Das ist auch nicht nur bei Google so, sondern generell bei sehr vielen Mailservern. Das ist also weder neu, noch kommt es überraschend, sondern gehört zum Betrieb eines modernen Mailsystems schlicht und ergreifend dazu. Grundsätzlich gehören eine vollständige DMARC Policy sowie geroutete RFC2142 Adressen ebenso zu den Minimalanforderungen.


    An sich sollten, meiner Ansicht nach, Domains die kein sinnvolles* SPF setzen und DKIM unterstützen, generell einen Null MX Record setzen und keine Emails mehr senden.


    ---


    *) Ein sinnvoller SPF Record muß -all enthalten.

    †) A "Null MX" No Service Resource Record for Domains That Accept No Mail

    - MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS

    Sorry für die Wall-of-Text, ich erkenne da ein paar Missverständnisse wie Email funktioniert und ein paar unscharfe Formulierungen die für Verwirrungen sorgen.


    Referenzlinks zu allem am Ende des Postings!



    Üblich ist heutzutage eher Port 587 statt 465.

    Das ist inkorrekt. Alles was nicht *implizites* TLS macht gilt grundsätzich als deprecated, weil es unsicher ist und derartige Verbindungen vom Konzept her nicht sicher gemacht werden können. STARTTLS ist opportunistisch.

    Port 465 ist Submission over (implicit) TLS.


    Und nein, Port 465 war *nie* SMTP mit SSL, mit TLS oder STARTLS, das gab' es nie.

    Port 465 wurde, von Microsoft Exchange eine zeitlang für SMTP Verbindungen zweckentfremdet. (Ausschließlich zwischen zwei MS-Exchange Servern.)

    Die IANA listet seit 2017-12-12 den Port 465/tcp als submissions.


    Ich bestreite jedoch nicht, daß es noch viel zu viele Legacy-Clients gibt die nur Plaintext Submission unterstützen. Bestenfalls dann noch ein opportunistischs Upgrade per STARTTLS versuchen und dann an korrekter Fehlerbehandlung scheitern und dann eine Authentifizierung im Plaintext zu machen.
    Ebenso gibt es viel zu viele Mailserver die nur Submission auf Port 587 unterstützen, aber noch kein Submission/S auf 465.

    Das stimmt so nicht. Port 587 unterstützt auch TLS

    Nein, Port 587 unterstützt STARTTLS, aber kein implizites TLS. Das sind zwei grundverschiedene Dinge.


    Bei STARTTLS wird eine Plaintextverbindung geöffnet, dann mal HELO gesagt und mit Capabilities geantwortet und dann optional versucht mittels STARTTLS Verbs ein Upgrade auf eine Verschlüsselte Verbindung zu machen. Es gibt hinreichend viele Provider die genau diese STARTTLS Message unterbinden, oder auf Netzwerk Ebene rausfiltern. (Die Ausreden dazu reichen von absurd bis zum Haareraufen.)


    Bei implizitem TLS, wird zuerst eine Verschlüsselter, und authentifizierter, Kanal erstellt und erst wenn das funktioniert hat, wird dadurch normales Submission gesprochen. Jegliche Protokoll-Konversation zwischen Client und Server erfolgt also erst, wenn es einen erfolgreich verschlüsselten Kanal gibt.



    Das ist korrekt, SMTP per SSL ist 465 meistens Standard

    Nein, denn es gibt kein SMTP per SSL, gab es noch nie, und auch kein SMTP mit TLS. Es gibt nur SMTP und das ist immer Plaintext auf Port 25.


    Es ist manchmal möglich auf Port 25 ein optionales, und immer opportunistisches Upgrade per STARTTLS auf eine Verschlüsselte Verbindung zu machen. Wenn das fehlschlägt ist aber ein Fallback auf Plaintext vorgeschrieben.
    SMTP wird ausschließlich zwischen Mail-Transfer-Agents (MTAs, also Mailservern) gesprochen.


    Clients (Mail-User-Agents, MUA) die Mail versenden wollen, verwenden das Protokoll Submission, *nicht* SMTP. Submission unterscheidet sich nur in wenigen, aber relevanten Belangen von SMTP. Es ist aber ein eigenes Protokoll.


    Ein MUA hat auf Port 25 nichts verloren und sollte korrekterweise von einem Mail Exchanger auch explizit abgewiesen werden.


    Sehr viele Texte, Tutorials und auch Benutzer:innen-Oberflächen bezeichnen Dinge immer noch fürchterlich falsch.


    - Korreke Bezeichnung: STARTTLS (Plaintext Verbindung mit Anschließedem Versuch auf eine verschlüsselte Verbindung upzugraden.)

    Das wird leider oft falsch als TLS bezeichnet. (Den sehr relevanten Unterschied habe ich oben erläutert.)

    - Korrekte Bezeichnung: TLS (implizite Verschlüsselung mit einer TLS Version (1.0, 1.1, 1.2, 1.3))

    Das wird oft falsch als SSL bezeichnet.

    - Korrekte Bezeichnung: SSL (implizite Verschlüsselung mit einer SSL Version (2.0 oder 3.0)) Diese Methode der Verschlüsselung ist veraltet, in jeder Version unsicher und auf jeden Fall sollte SSL nirgends mehr verwendet werden. Nicht als Bezeichnung, und schon garnicht als Protokoll.




    E-Mail Versandanbieter: Anderer SMTP-Server

    SMTP-Server: mxe93b.netcup.net


    mxe93b.netcup.net antwortet korrekt auf Port 465 mit TLS 1.2 und TLS 1.3. Ältere TLS Versionen sowie SSL werden hier, ebenfalls korrekterweise, nicht unterstützt.


    Wenn Deine Maildomain nicht bei Netcup gehostet ist, halte ich es für unwahrscheinlich, daß Du über deren Server so senden darfst.

    Du müsstest den ausgehenden Mailserver (MSA) für Deine Domain verwenden. (Der den Du auch in Deinem sonstigen Emailprogramm verwendest.)


    Referenzen:

    - IANA: Service Name and Transport Protocol Port Number Registry Port 465/tcp

    - RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access

    - RFC 8997: Deprecation of TLS 1.1 for Email Submission and Access

    - RFC 2822: Simple Mail Transfer Protocol (SMTP)

    - RFC 6409: Message Submission for Mail (Submission)

    - RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)

    Schamlose Eigenwerbung:

    Meine Vorträge zu Email in deutscher Sprache auf Media-CCC.

    - MRMCD2018: Email, wie funktioniert das eigentlich wirklich? (Technischere Version)

    - PrivacyWeek 2018: Email, wie funktioniert das eigentlich wirklich? (Sehr viel *weniger* technische Version)

    - Vortrag gemeinsam mit leyrer von der Easterhegg 2016: E-Mail. Hässlich, aber es funktioniert

    Vortrag zu Email in englischer Sprache auf YouTube:

    - Talk at BalCCon2k18: Email how does it even work?

    Danke für das gemütliche Event in Karlsruhe!


    Bei mir hat UPS auch Geschenke gebracht. Im Vergleich zum Puzzle von cltrmx habe ich jedoch ein Modell mit höherem Schwierigkeitsgrad bekommen. Das hohe, wiederverschließbare Getränkegebinde hat den Transportweg problemlos überstanden und das ist sehr erfreulich.


    Fühle mich vom „Coffee Loading“ Sticker auf der Karte jedenfalls sehr verstanden!