Webhosting akzeptiert beliebigen Absender

  • Hallo zusammen,

    mir ist gerade bei meinem Webhosting 8000 aufgefallen, dass ich im E-Mail Client einen beliebigen Absender ("From" Header) setzen kann. Die E-Mail-Adresse des Postfachs, von dem die Mail tatsächlich gesendet wurde, taucht in den Headern hingegen nirgendwo auf.

    Sollte der Mailserver nicht prüfen, ob ein Account zum Verwenden einer Absenderadresse berechtigt ist?

    Wenn jeder netcup-Webhosting-Kunde Mails von kundenservice@sparkasse.de oder steve.jobs@apple.com versenden kann, schadet das der Reputation der Mailserver und damit uns allen. Sehr ärgerlich. Kein Wunder, dass die immer wieder auf Blacklists landen

  • Der From-Header alleine ist technisch gesehen eigentlich irrelevant.


    Wichtiger ist, was als MAIL FROM im SMTP-Dialog übergeben wird. Das landet letzten Endes im Return-Path Header. Und genau diese Adresse würde Bounce-Nachrichten u.a. abbekommen. Ich gehe mal nicht davon aus, dass dieser Header ebenfalls verändert beim Ziel ankam?


    Wenn man Wert auf die Prüfung des From-Headers legt, egal ob als Absender oder Empfänger, kann ich als Stichwort für Leseempfehlungen nur DMARC empfehlen.

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

  • mir ist gerade bei meinem Webhosting 8000 aufgefallen, dass ich im E-Mail Client einen beliebigen Absender ("From" Header) setzen kann.

    Kann ich bestätigen. Habe gerade mal von einer EiWoMiSau eine Mail an meinen Mailserver auf einem VPS gesendet:

    Code: Mailheader
    Return-Path: steve.jobs@apple.com
    Received: from relay.yourmailgateway.de (relay.yourmailgateway.de [185.244.192.111])
     by server.XXXX.de with ESMTPS (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384
     bits=256) ; Fri, 28 Feb 2020 08:09:54 +0100
    From: Steve Jobs <steve.jobs@apple.com>

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


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

  • Das gleiche Problem gab es schonmal mit einem Netcup-Mailserver. Ich habe mich damals über mehrere Wochen mit dem Support herumgeärgert, der das Problem trotz zahlreicher Screenshots und sonstiger Nachweise nicht nachstellen konnte. Irgendwann wurde dann doch festgestellt, dass die Konfiguration für die Ports 465 und 587 unterschiedlich war, das wurde glattgezogen und es hat wieder gepasst. Das war eine ziemlich unbefriedigende Aktion, nichtmal für ein "Vielen Dank für Ihre hartnäckigkeit" hat es gegeben und das bei einem eigentlich doch recht kritischen Fehler - man könnte schließlich Mails von mail@netcup.de über einen netcup Mailserver versenden, die jeder somit als authentisch ansehen müsste.

  • Da Virinum und heavygale die gleichen Erfahrungen gemacht haben, gehe ich hier von einem generellen Problem aus.

    Ich sehe das als sehr kritische Lücke an, aus folgenden Gründen:


    1. Ich könnte E-Mails mit Absender bill.gates@microsoft.com an outlook.com oder hotmail.com Kunden senden. Diese Mails würden den SPF/DMARC/DKIM Check nicht bestehen, damit würde der Netcup Mailserver als Spammer/Betrüger eingestuft und wieder das ganze Netcup Netz auf der MS-Blacklist landen. Sehr mies!


    2. (in meinen Augen noch viel Schlimmer) Stellen wir uns folgendes Szenario vor: H6G ist selbstständiger netcup Kunde. Er nutzt ein Webhosting mit seiner Domain h6g.com. Er hat beim Einrichten der Domain den netcup-SPF Eintrag included (so wie es das CCP will) und hat brav den DKIM-Domainkey gesetzt. Jetz kann ich (und jeder andere netcup Kunde) fröhlich E-Mails mit Absender "buchhaltung@h6g.com" senden. Diese E-Mails sind absolut authentisch, bestehen jeden DKIM/SPF/DMARC Check. Sehr kritisch!


    3. Der netcup Support achtet ja akribisch auf die Absenderadresse bei Anfragen und nutzt den Absender als Authentifizierung (siehe https://forum.netcup.de/netcup…ight=Affentanz#post123901)

    Ich kann jetzt also in meinem Beispiel Szenario munter E-Mails an mail@netcup.de mit Absender "info@h6g.com" senden, die absolut authentisch sind und darin alle Server von H6G kündigen, Daten erfragen und bestimmt noch viele andere schlimme Dinge tun wofür mir gerade die Fantasie fehlt. Auch extrem kritisch!


    Ich finde das ist absolut inakzeptabel. [netcup] Felix P. ist das ein Fehler, generell falsch konfiguriert oder soll das so sein?


    Sorry Paul, dass du als Beispiel herhalten musstest ;)

  • Sorry Paul, dass du als Beispiel herhalten musstest

    Was hab ich denn jetzt damit zu tun? :saint:


    Technisch gesehen, ist es irrelevant - es gehört aber zum guten Ton den From Header zu prüfen.

    Ich handhabe das so: ein Nutzer kann nur E-Mails versenden von Adressen, die er im Mail Attribut hat oder die ihm als Alias zugeteilt wurden.


    Das von dir beschriebene Szenario wird interessant, wenn die beiden Nutzer auf dem gleichen E-Mail Server sind, oder gerade zufällig Netcup wieder ein Relay einschaltet.


    Lass uns das mal beim nächsten Webhosting Schnapper probieren (24€ sind mir dafür gerade zu schade).

    • Offizieller Beitrag

    Hallo marpri,



    danke für deinen Hinweis.


    Die von dir benannten Situationen treffen viele Mailanbieter und jeder Provider muss sich individuell entscheiden, wie er damit umgeht. Mir persönlich sind auch andere Mailprovider bekannt, die damit wie wir umgehen.


    Grundsätzlich ist es so, dass das SMTP-Protokoll ganz bewusst keine Kontrollen des Absenders vorsieht, ähnlich wie es möglich ist, eine beliebige Absenderadresse auf einen Brief zu schreiben. Wir sehen an vielen verschiedenen Stellen, wo das nötig ist und genutzt wird, z.B. bei Mailinglisten, Benachrichtigungen, Weiterleitungen, usw.


    Gerne möchte ich einmal auf deine einzelnen Punkte eingehen:


    Zu 1.) Es ist korrekt, dass das prinzipiell möglich ist. Der Empfänger ist dafür verantwortlich, mittels den zur Verfügung stehenden Techniken zu überprüfen, ob ein bestimmter Absender autorisiert ist, von einem Mailserver zu versenden. So würde im konkreten Beispiel, wie auch von dir erwähnt, der SPF-, DKIM- und DMARC-Check fehlschlagen. Das wird aber vom empfangenden Provider für das absendende System nicht negativ ausgelegt, eben da das SMTP-Protokoll eine solche Möglichkeit des Versendens von abweichenden Mailadressen explizit vorsieht. Es erhöht also nicht das Risiko auf Blacklists o.ä. zu landen. Auch den Blacklist-Betreibern ist bekannt, dass diese Schwierigkeiten im SMTP-Protokoll vorhanden sind, weswegen es ja überhaupt erst Techniken wie SPF / DKIM und DMARC gibt.


    Zu 2.) DKIM weist leider konzeptionelle Schwächen auf: Somit ist DKIM in erster Linie erhöhend für die Reputation des Mailservers, aber nicht der Authentizität der Absenderdomain, auch wenn es dafür ursprünglich vorgesehen war. Außerdem ist für den Endanwender in den meisten Fällen nicht sichtbar, ob eine Mail DKIM signiert wurde, oder nicht. So erhöht eine DKIM-Signatur zwar die Zustellbarkeit, Mails ohne DKIM werden aber dennoch (wenn keine anderen schwerwiegenden Fehler vorliegen) in der Regel zugestellt. Es muss den Empfängern also ohnehin vermittelt werden, dass der Absender einer E-Mail grundsätzlich nicht zweifelsfrei als korrekt angesehen werden sollte. Empfänger sollten immer die enthaltenen Links bei einer Nachricht auf Korrektheit prüfen. Bei einer Antwort würde außerdem ohnehin an die "FROM"-Adresse geantwortet werden.


    Zu 3.) Es ist richtig, dass der Absender bei uns teilweise zur Authentifizierung von Anfragen verwendet wird. Allerdings antworten wir ja auch stets an die Absenderadresse. Somit gehen persönliche Daten in keinem Fall an den Fälscher des Absenders. Wir würden in dem Fall ja an die korrekte E-Mail-Adresse des Kunden antworten. Bei kritischen Aktionen, wie z.B. Kündigungen, lassen wir uns diese immer zuvor über eine erneute Antwort an den Absender bestätigen. Dadurch ist ausgeschlossen, dass z.B. Löschungen von Daten durch einen gefälschten Absender initiiert werden.


    Zu guter Letzt schreiben wir die wahre Absenderdomain in die Message-ID und bei unseren Webhostingtarifen auch in einen weiteren Header, so dass auch für uns (z.B. bei späteren Abusemeldungen zu einer Nachricht) eindeutig erkennbar ist, von wem die E-Mail versendet wurde.


    Ich hoffe, dass das weiterhilft.

  • Hmm, damit erübrigt sich meine erste Antwort wohl… :(


    [netcup] Lars S. Heißt das, dass z.B. im Fall von Postfix smtpd_sender_login_maps gar nicht mehr zum Einsatz kommt beim Webhosting?


    Prinzipiell stimme ich zu, dass es genau dafür SPF & Co. gibt. Das ist meiner Ansicht nach bei Shared Webhosting (als Ausgangsserver) aber nicht ausreichend.

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

  • Die Bedingungen erfülle ich doch gar nicht.

    Außerdem ist NCLabs für den Normalsterblichen ja wohl eher ein Phantasieprodukt.

    Oder war in den letzten 5-10 Jahren irgendwann einmal die Registrierung dafür offen?

    Die "Testplätze" werdem ja wohl seit Jahr(zehnt)en von denselben Leuten besetzt.

  • Vielen Dank [netcup] Lars S. für die ausführliche Antwort. In einem Punkt muss ich dir aber widersprechen:

    Zu guter Letzt schreiben wir die wahre Absenderdomain in die Message-ID und bei unseren Webhostingtarifen auch in einen weiteren Header, so dass auch für uns (z.B. bei späteren Abusemeldungen zu einer Nachricht) eindeutig erkennbar ist, von wem die E-Mail versendet wurde.

    Denn wenn ich mit meinem netcup-Webhosting-Postfach, nennen wir es mail@gauner.de, eine E-Mail an mail@empfaenger.de sende und als Absender mail@unbeteiligter.de setze, dann hat die Message-ID, die beim Empfänger ankommt die Form "da6966a2ba635cadd64b792fcd11bf9b4a@unbeteiligter.de", meine wahre Absenderdomain gauner.de taucht in der Message-ID und in den (sichtbaren) Headern nirgendwo auf


    Ich bin sehr froh über deine ausführliche Erklärung, und kann viele deiner Argumente gut nachvollziehen (Ich betreibe seit Jahren selbst Mailserver), trotzdem ist es sehr unbefriedigend, dass ich es hinnehmen muss, dass jeder beliebige Mensch (zumindest jeder netcup Kunde) völlig Problemlos und ohne Aufwand Mails von meiner Domain senden kann, die nach SPF, DKIM und DMARC völlig authentisch sind.


    Um zu deinem Brief-Beispiel zurückzukommen: Natürlich kann jeder einen Brief in meinem Namen verschicken und meine Adresse als Absender angeben, aber wenn die Post dann auf jeden gefälschten Brief ein Siegel (DKIM) klebt mit der Aufschrift "Dieser Brief kommt tatsächlich von marpri, das haben wir geprüft" dann gibt mir das ein ungutes Gefühl. Das muss ja dazu führen, dass die Siegel (DKIM-Signaturen) der Postfiliale (netcup-Mailserver) völlig wertlos sind.

    Eine mit Hilfe von DomainKeys signierte E-Mail bietet also die Möglichkeit, sicher nachzuprüfen, ob die in der E-Mail-Absenderadresse enthaltene Domäne korrekt ist [...]


    Gibt es einen Plan, an der (Nicht-)Prüfung der Absender was zu ändern?


    Viele Grüße

    marpri

  • Um zu deinem Brief-Beispiel zurückzukommen: Natürlich kann jeder einen Brief in meinem Namen verschicken und meine Adresse als Absender angeben, aber wenn die Post dann auf jeden gefälschten Brief ein Siegel (DKIM) klebt mit der Aufschrift "Dieser Brief kommt tatsächlich von marpri, das haben wir geprüft" dann gibt mir das ein ungutes Gefühl. Das muss ja dazu führen, dass die Siegel (DKIM-Signaturen) der Postfiliale (netcup-Mailserver) völlig wertlos sind.

    Die Post klebt da aber nicht drauf "Dieser Brief kommt tatsächlich von marpri, das haben wir geprüft", sondern "Dieser Brief kommt tatsächlich von dem Server, den auch marpri benutzt, das haben wir geprüft".

    Wenn 100 (oder auch nur 2) Kunden diesen Server verwenden, ist die Aussage somit quasi wertlos.

    Wenn Du es eindeutiger willst, dann brauchst du einen eigenen Sendeserver.

    Da ein Empfänger aber auch hier nicht weiß, wieviele Leute den nutzen, ist das gesamte System im Grunde Nutzlos.

  • Lass uns das mal beim nächsten Webhosting Schnapper probieren (24€ sind mir dafür gerade zu schade).

    Ich meine mich zu erinnern, dass ich diesbezüglich vor 1-2 (oder mehr) Jahren mal was getestet habe, betraf glaube ich nur eigene Domains. Jedenfalls bin ich — so meine ich — zu dem Schluss gekommen, dass kein wirklicher Missbrauch möglich war. Nagelt mich hier bitte _nicht_ drauf fest...


    Außerdem ist NCLabs für den Normalsterblichen ja wohl eher ein Phantasieprodukt.

    Oder war in den letzten 5-10 Jahren irgendwann einmal die Registrierung dafür offen?

    Die "Testplätze" werdem ja wohl seit Jahr(zehnt)en von denselben Leuten besetzt.

    Einmal vor sehr sehr langer Zeit, vielleicht 2/3 Jahren waren die Testplätze mal offen, ich habe mich natürlich registriert und nur wenige Stunden später bekam ich eine Mail des Supports, dass das Angebot nur fälschlicherweise freigeschaltet war?