SMTP lässt jede Adresse als Absender zu (ACHTUNG SCHWACHSTELLE)

    Hallo liebe Netcup Community,


    leider habe ich gerade festgestellt, dass die Mailserver aus dem Webhosting jegliche Adresse als Absender akzeptieren. Wenn ich eine Absendeadresse nutze die auch bei Netcup bekannt (aber anderer MX Server) ist, dann wird diese nicht mal Spam markiert, aufgrund der korrekten DKIM und SPF Einträge. Nutze ich allerdings eine bei Netcup unbekannte Absenderadresse, wird diese immerhin bei Microsoft Exchange in den Spam sortiert, da die SPF und DKIM Einträge nicht passen. Ich kann jetzt als tcook@apple.com Mails versenden. Das ist sehr uncool.


    Wenn jemand aus der Community bereit ist mir seinen Domainnamen zu verraten, dann führen wir mal ein paar gemeinsame Tests durch. Nur wenn ihr möchtet.


    Warum prüft Netcup nicht ob der angemeldete SMTP User überhaupt diese Adresse nutzen darf (oder ob ein entsprechender Alias angelegt ist)?


    Das muss umgehend geändert werden!

    Quote from Geheftet09

    leider habe ich gerade festgestellt, dass die Mailserver aus dem Webhosting jegliche Adresse als Absender akzeptieren. Wenn ich eine Absendeadresse nutze die auch bei Netcup bekannt (aber anderer MX Server) ist, dann wird diese nicht mal Spam markiert, aufgrund der korrekten DKIM und SPF Einträge. Nutze ich allerdings eine bei Netcup unbekannte Absenderadresse, wird diese immerhin bei Microsoft Exchange in den Spam sortiert, da die SPF und DKIM Einträge nicht passen. Ich kann jetzt als tcook@apple.com Mails versenden. Das ist sehr uncool.

    So wie ich es beobachtet habe, muß man bevor man eine E-Mail über den SMTP-Server von Netcup versenden möchte, sich vorher am SMTP-Server authentifizieren. Von daher würde ich aus meiner Sicht dies nicht als Schwachstelle sehen.

    Tatsächlich, einmal authentifiziert kann man jede Absenderadresse verwenden. Das Verhalten war auf jeden Fall vor ein paar Monaten noch anders.


    Die E-Mail-Konten meines ISP 2&2 kann man aber auch problemlos als Relay-Konten verwenden, weil da auch jede Absenderadresse zulässig ist.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | VPS 500 ARM


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Quote from andreas.

    So wie ich es beobachtet habe, muß man bevor man eine E-Mail über den SMTP-Server von Netcup versenden möchte, sich vorher am SMTP-Server authentifizieren. Von daher würde ich aus meiner Sicht dies nicht als Schwachstelle sehen.

    Open Relay wär schneller aufgefallen und wenn SMTP Auth zB bei Microsoft nicht die Gültigkeit der Absenderadresse prüfen würde, gäbs noch mehr Phishing-Mails

    Quote from andreas.

    So wie ich es beobachtet habe, muß man bevor man eine E-Mail über den SMTP-Server von Netcup versenden möchte, sich vorher am SMTP-Server authentifizieren. Von daher würde ich aus meiner Sicht dies nicht als Schwachstelle sehen.

    Hi Andreas,

    ich habe ja auch nicht gesagt, dass Netcup ein offenes Relay betreibt, aber nach einmaligem SMTP Auth kann ich jede Absendeadresse eintragen die mir beliebt.

    Natürlich ist das keine schwerwiegende Schwachstelle, aber toll fände ich das nicht. Zumal, DKIM und SPF Einträge keine Wirkung zeigen, wenn die Domain auch bei Netcup in den Systemen hängt. Denn dann sind diese korrekt laut Definition. Da hilft nur die Prüfung beim Versand.


    Beim Versand muss geprüft werden, ob die Absendeadresse auch die ist die für die SMTP Anmeldung genutzt wurde oder ein entsprechender Alias aus dem korrekten SMTP Konto verwendet wird. Alle weiteren sollten nicht versendet werden. Möchte man jetzt nun die Send-on-Behalf Funktion nutzen, muss vorher geprüft werden, ob derjenige den Versand auch in Vertretung von einer bestimmten Adresse erlaubt - das ist bestens in Microsoft Exchange implementiert - bei Postfix weiß ich das nicht genau.


    Aber Netcup muss zusehen, dass nicht jeder jede Absendeadresse aus egal welchem SMTP Konto nutzen kann.


    Kein Wunder, dass Netcup immer so Probleme mit dem Empfang der Mails bei großen Anbietern und Spam hat.

    Kann ich aber bei anderen Providern auch.

    Ich habe gerade mal testweise über ein smtp-Relay von sträto eine email mit einer gmx-Absenderadresse verschickt.


    Aber dafür ist spf ja da ;)

    Code
    SPF: fail (xxxx: domain of gmx.de does not designate xxxxx as permitted sender



    und bei 3&3 scheint es ja auch zu gehen:

    Quote from Virinum

    Die E-Mail-Konten meines ISP 2&2 kann man aber auch problemlos als Relay-Konten verwenden, weil da auch jede Absenderadresse zulässig ist.



    Quote from Geheftet09

    ... dass Netcup immer so Probleme mit dem Empfang der Mails bei großen Anbietern und Spam hat.

    Kann ich so nicht mehr bestätigen

    Hi aRaphael,


    nur weil andere Provider es auch erlauben, heißt es nicht, dass es gut ist. ;) Und es sollte von uns als Kunden nicht akzeptiert werden, nur weil es immer schon so war. Netcup möchte sich ja nach den Worten von Lars verbessern, hier ist die nächste Möglichkeit sich auf dem Markt herauszustellen.


    Das Thema wurde bereits vor Jahren auch von anderen Usern angemerkt, wie ich gerade im Forum lese. Warten wir es ab.


    Der gmx SPF Record gibt in deinem Fall das einen Fail zurück - das ist auch korrekt. Aber was ist bei dem Fall, habe ich eben schon genannt, dass beide Domains die Netcup Server benutzen, dann habe ich wieder korrekte SPF und DKIM Einträge.


    Ich hab ja auch gesagt, für externe Domains ist es fast egal aufgrund von SPF und DKIM, aber eben nicht für den Anwendungsfall, wenn beide Domains bei Netcup sind.


    Welchen Anwendungsfall gibt es, dass es erlaubt sein sollte, anderweitige Domains als seine eigenen zu benutzen? Das ist hier so ein bisschen die Grundfrage.

    Quote from Geheftet09

    nur weil andere Provider es auch erlauben, heißt es nicht, dass es gut ist.

    Mich würde viel mehr interessieren, welche Provider es nicht erlauben.

    Und warum es die hier getesteten 2&2, sträto und netcup (und welche noch?) offenbar nicht für nötig halten.


    Wie ist denn hier so der allgemeine Standard?

    Du schreibst ja im Eingangsbeitrag:

    Quote from Geheftet09

    Das muss umgehend geändert werden!

    Man kann es ja nicht wirklich verhindern - im Zweifel setzt man seinen eigenen Server auf - dafür ist ja SPF da (was ja auch der Grund ist warum viele Provider jede mail ohen SPF anlehnen).

    Aber stimmt bei beiden Domains bei Netcup kann es problematisch sein

    Quote from aRaphael

    Mich würde viel mehr interessieren, welche Provider es nicht erlauben.

    Und warum es die hier getesteten 2&2, sträto und netcup (und welche noch?) offenbar nicht für nötig halten.


    Wie ist denn hier so der allgemeine Standard?

    Du schreibst ja im Eingangsbeitrag:

    Es gibt viel zu tun und darf man hier eigentlich Microsoft schreiben oder muß man dies auch verunstalten?


    If we choose to use SMTP Auth method to send email, we can’t use a different address in From field. The sending address must be consistent with the authenticated account.

    Quote from aRaphael

    Und warum es die hier getesteten 2&2, sträto und netcup (und welche noch?) offenbar nicht für nötig halten.

    Einer der Gründe könnte sein: Es gibt immer wieder Kunden, die ihren SMTP-Zugang gerne als Relay für diverse Dinge verwenden wollen. Um also auch mit Absender(domains) zu versenden, die nicht bei diesem Provider liegen. Das würde dann natürlich nicht (mehr) gehen. Auch mit Alias-Adressen usw. kann das schnell zu unerwarteten Problemen und somit Supportaufwand führen.


    Persönlich finde ich das aber nicht sehr sinnvoll und bin inhaltlich ganz bei Geheftet09 – wenn man so ein Relay braucht, gibt es spezialisierte Dienste dafür. Ich habe das mit anderen Anbietern auch schon mal ausführlich diskutiert. Mit dem Ergebnis, dass ich seitdem endgültig alle Mailserver selber betreibe. ^^

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited once, last by KB19 ().

    Like 6
    Quote from KB19

    Einer der Gründe könnte sein: Es gibt immer wieder Kunden, die ihren SMTP-Zugang gerne als Relay für diverse Dinge verwenden wollen. Um also auch mit Absender(domains) zu versenden, die nicht bei diesem Provider liegen. Das würde dann natürlich nicht (mehr) gehen. Auch mit Alias-Adressen usw. kann das schnell zu unerwarteten Problemen und somit Supportaufwand führen.

    Mich wundert es in diesem Zusammenhang auch, dass mein Test mit dem sträto-relay so ausgegangen ist. Ich hatte eigentlich das Gegenteil erwartet, denn ich war mir ziemlich sicher, dass das in der Vergangenheit nicht ging und ich in solchen Fällen immer die Meldungen bekommen habe (sinngemäß) "relay erlaubt den Versand mit dieser Absenderadresse nicht"

    Deshalb schreibe ich ja meine Systemmails, die ich über dieses relay versende, immer in postfix mit sender_canonical_maps um.

    Dass das jetzt auf einmal ging, überrascht mich ein wenig.

    Quote from Geheftet09

    Beim Versand muss geprüft werden, ob die Absendeadresse auch die ist die für die SMTP Anmeldung genutzt wurde oder ein entsprechender Alias aus dem korrekten SMTP Konto verwendet wird. Alle weiteren sollten nicht versendet werden. Möchte man jetzt nun die Send-on-Behalf Funktion nutzen, muss vorher geprüft werden, ob derjenige den Versand auch in Vertretung von einer bestimmten Adresse erlaubt - das ist bestens in Microsoft Exchange implementiert - bei Postfix weiß ich das nicht genau.

    Quote from Geheftet09

    - das ist bestens in Microsoft Exchange implementiert -

    Bei den von dir genannten Provider zahlt man aber dann auch für nur ein E-Mailkonto aus deren Tarif "Business Basic" schon ca. 6 Euro als Endkunde.

    Dass dann deswegen auch entsprechend Personal eingesetzt werden kann, versteht sich dann wohl von selbst.


    Derzeit zahle ich für mein Webhostigtarif bei Netcup, bei dem ich 100 E-Mailkonten erstellen kann, aufgerundet so ca. 12 Euro im Jahr.

    So weiter hab ich mich gerade mal bei Mailbox.org schlau gemacht:


    Quote

    Seit 29.09.2020:

    Mailversand nur noch mit angemeldeten E-Mail-Adressen bzw. Aliasen möglich

    Mit Wirkung zum 29.09.2020 werden unsere Mailserver von einem Account nur noch die Absender erlauben, die diesem Account auch als Mailadresse oder Alias zugeordnet sind. Damit beugen wir Absenderfälschungen vor. In Einzelfällen nutzen Privat-, aber auch einige Geschäftskunden jedoch mailbox.org-Accounts, um darüber auch E-Mails mit Absendern zu versenden, die sie bei anderen Providern haben. Dies wird dann nicht mehr so möglich sein - die jeweiligen Adressen müssen ausdrücklich angelegt oder zumindest als "catch-all" zugeordnet sein. Unsere FAQ beschreibt die Details

    [netcup] Lars S. schaut doch mal bei denen vorbei und lasst euch aus deren Doku inspirieren ;)


    Unter anderem wird dort

    Quote

    Um gezielte Manipulationen durch Dritte auszuschließen, haben wir als einer der ersten Provider unsere Domain mittels DNSSEC und DANE/TLSA gesichert.

    eingesetzt.

    Und ein weiteres Thema bereits aktiv praktiziert:

    Quote

    Zum Schutz Ihrer Privatsphäre entfernen wir bei allen ausgehenden E-Mails alle eventuell mitgesendeten Metadaten zum verwendeten Browser oder Mailclient, als auch die privaten und öffentlichen IP-Adressen des Nutzers ("IP-Stripping").

    Hmm, wenn das so ist und auch so bleiben soll, dann muss ich jetzt Mail nei meinen netcup-Webhosting-Domains deaktivieren oder nur noch über meinen Mailserver versenden, weil ich nur so gewährleisten kann, dass über diese Mailadressen nur ich Mails verschicke. Wenn alle anderen netcup Kunden Mails in meinem Namen (= von meiner Domain) verschicken können - mit korrektem SPF und DKIM - dann hört nämlich für mich der Spass auf. Es wundert mich sowieso, dass 2&2 so etwas bei sich zulässt, wo man sich doch dort ansonsten gern als der große Spam-Bekämpfer gibt. Bei dem Berliner Haufen wundert mich freilich gar nichts. Aber auch da habe ich irgendwo gelesen, dass sie das möglicherweise künftig einschränken wollen (oder müssen).

    Quote from tab

    Hmm, wenn das so ist und auch so bleiben soll, dann muss ich jetzt Mail nei meinen netcup-Webhosting-Domains deaktivieren oder nur noch über meinen Mailserver versenden, weil ich nur so gewährleisten kann, dass über diese Mailadressen nur ich Mails verschicke.

    Das hilft aber nur bedingt.

    Denn wenn du das machst und z.B. zu mailbox.org umziehst, dann kannst du dort deine emails nur unter deinem domainnamen verschicken.

    Jeder andere könnte aber, bei einem Provider, der das nicht prüft, durchaus weiterhin emails mit deiner maibox.org-Adresse verschicken.

    Was dkim und spf angeht, wärst du dann aber tatsächlich sicherer.

    Quote from aRaphael

    Denn wenn du das machst und z.B. zu mailbox.org umziehst, dann kannst du dort deine emails nur unter deinem domainnamen verschicken.

    Jeder andere könnte aber, bei einem Provider, der das nicht prüft, durchaus weiterhin emails mit deiner maibox.org-Adresse verschicken.

    Das wäre zumindest mal ein Anfang und wäre für mich schon mal ok, da ich so sicherstellen kann, dass keiner in meinem Namen mit korrekten SPF oder DKIM Mails versenden kann. Natürlich könnte er das machen, aber dann gibt es einen Fail bei SPF und DKIM, wenn die Mails nicht von den Mailbox.org Servern kommen.


    Jeder andere ist erstmal für sich selbst zuständig und muss für sich entscheiden, ob er dies "Risiko" eingehen möchte.


    Generell hat hier nach wie vor weiter ein Umdenken stattzufinden.


    Ich habe Netcup jetzt folgenden Vorschlag gemacht:

    Für diese Relay Optionen, dass der Absender nicht geprüft wird, muss es entweder einen eigenen Service geben oder man hat im Plesk die Möglichkeit das je nach Domain ein- oder auszuschalten (oder zumindest auf die eigenen Domain zu begrenzen, das nur das @domain.tld bei der Versenderadresse geprüft wird).

    --> es gibt ja intern einige Routing Möglichkeiten bei Netcup. Man könnte einen Teil der relay.yourmailgateway.de Server als secure-relay.yourmailgateway.de umbauen und hier die Prüfung als letzte Instanz durchführen die auf die Einstellung in Plesk prüft.


    Das wäre für mich ok. Was haltet ihr so in der Community davon?

    Quote from RAD750

    Das ist ja eigentlich super für Scammer... Einfach also elon@tesla.com Mails versenden und nach Geld betteln.. Das muss definitiv geändert werden!

    Das wäre natürlich schlecht. Würde aber bei einer strikten DMARC Richtlinie von tesla.com im Spam landen, da SPF und DKIM einen Fail ausgeben.


    Habe mal gerade bei einer von mir kontrollierten Domain, die nicht bei Netcup liegt, die DNS Records für DMARC SPF DKIM entfernt. Siehe da, wird einwandfrei ins Postfach zugestellt ohne alles Spam erkannt zu werden. Das ist mehr als schlecht, mit DMARC aber nicht so schlimm. Schlimmer finde ich, dass ich mich als ein anderer Betcup-Kunde ausgeben kann, sollte ich in das Wissen darüber kommen wie die Mail ist, könnte ja dadurch auch Supportanfragen ggf. mit der Legitimation der E-Mail Adresse stellen.


    Das könnt ihr mir nicht erzählen als ob dieses Verhalten von Netcup gewollt ist. ;( Das hört sich für mich eher wir nicht mitdenkende Administratoren an.


    Natürlich könnte man jetzt den Ursprung durch den Header "X-PPP-Vhost: xxxx.tld" herausfinden. Welche E-Mail Nutzer prüft das aber vorher, außer ein technisch versierter Mensch. —> Und nun zur Frage: Warum einzelne (teure) Nachsorge betreiben, wenn das Kind bereits in den Brunnen gefallen ist, anstatt generelle Vorsorge zu treffen, die den Kunden ein besseres Gefühl gibt?! Auf das Kostenthema bezogen zitiere ich mal den ehemaligen Felix P.:

    Quote from [netcup] Felix P.

    Es ist am Ende eine Kostenfrage. Individuelle Arbeitszeit eines netcup-Systemadministrators müssen wir mittlerweile mit 90 Euro / Stunde in Rechnung stellen.

    Und die Kosten dürften mittlerweile nochmal höher sein.


    Die Frage darf [netcup] Alexander W. und [netcup] Oli W. (hoffe das sind die Geschäftsführer) oder [netcup] Lars S. mal stellen und versuchen zu beantworten.


    Gerne kann die Community hier weiter pro und contra zu dem Thema aufführen und gerne eure Meinung teilen.

    Edited 2 times, last by Geheftet09: Korrektur des Headers und Rechtschreibfehler ().