1. Foren
  2. Kommentare
  3. Internet-Forum
  4. Alle Kommentare zum Artikel
  5. › E-Mail-Spoofing: Das Problem…

besser keine Mailinglistenanpassungen / Sender vs From

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. besser keine Mailinglistenanpassungen / Sender vs From

    Autor: slowthoughts 10.08.20 - 11:30

    Ein grundlegendes Problem hier ist auch, dass der From-Header für den menschlichen Autor oder zumindest den Ersteller der Email gedacht ist (RFC5322: 'The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message.').

    Wenn eine Mailingliste sich RFC-konform verhalten möchte und sich selbst als Absender eintragen will darf sie also nicht den From:-Header umschreiben, sondern muss den "Sender"-Header anpassen. Damit wäre DMARC aber nicht geholfen.

    Da auch alle wesentlichen Mailclienten den From-Header in der Darstellung mit dem Autor der Email gleichstellen (Mail von: Irena Beispiel), würde ein Umschreiben dieses Headers auch die Verständlichkeit der Emails für den Empfänger verschlechtern. Wie sich das urhebrrechtlich in Deutschland verhält wenn ich die Kennzeichnung des Autors einer Email verändere wäre auch spannend.

    Quintessenz --> DMARC müsste so angepasst werden, dass es sich an die anderen Mailstandards hält und sich im Wesentlichen auf den Sender bezieht, die Mailclienten müssten besser zwischen "From:" und "Sender:" trennen. Beides ist ein zu dickes Brett, deswegen wird DMARC hoffentlich langsam verkümmern und etwas brauchbareres entstehen.

  2. Re: besser keine Mailinglistenanpassungen / Sender vs From

    Autor: capricious 10.08.20 - 15:17

    Es ist doch genau das Problem, dass Mailinglisten die E-Mail verändern und daher diese nicht mehr der vom Absender entspricht.
    Deswegen schlägt die DKIM Prüfung bei verändertem Header oder Body (z.B. unsubscribe-Signatur) bzw. auch die SPF Prüfung bei beibehaltener Absender-Email-Adresse fehl.
    Mit SPF sagt man, die Mails von Domain xyz dürfen nur von den hinterlegten Mailservern versendet werden.
    Server von Mailinglisten sind nicht hinterlegt und somit keine validen Sendeserver (MTA) für x-beliebige Domains.

    Ähnliches gilt aber auch für diverse Relay-Proxies in/von Firmen.
    Das dürfte das schwierigere Kompatibilitätsproblem sein. Da kommen die Mails dann vom MTA in der DMZ und der gibt vor Absender einer gmail.com-Adresse zu sein.
    Dafür müsste man Sender/Recipient-Rewriting im Ein- und Ausgang einführen.

  3. Re: besser keine Mailinglistenanpassungen / Sender vs From

    Autor: slowthoughts 10.08.20 - 19:01

    1) SPF geht auf die Envelope-Felder, also MAIL FROM: (nicht "From:") und EHLO. Das sollte normalerweise kein Problem für Mailinglisten sein, da der der Envelope-Header auf die ML gesetzt werden kann und sollte um sinnvoll SPF zu unterstützen.

    2) DKIM bzw. dessen oft weitgehende Konfiguration ist manchmal ein Problem, normalerweise aber auch nicht, wenn die Mailingliste so konfiguriert ist, dass sie keinen Footer setzt, oder die Mail anderweistig verändert.

    3) DMARC verlangt nun aber dass die Domain im "From" der Mail der Domain des im SPF hinterlegtem Envelope-From entspricht. Das ist wegen 1) im Falle von Mailinglisten ein Fail.

    --> so entsteht das Problem mit DMARC und Mailinglisten. Es gibt im Wesentlichen aufgrund dieses Konflikts keine mögliche Konfiguration von Mailinglisten die alle Probleme mit den drei Techniken RFC-konform behebt.



    1 mal bearbeitet, zuletzt am 10.08.20 19:02 durch slowthoughts.

  4. Re: besser keine Mailinglistenanpassungen / Sender vs From

    Autor: capricious 10.08.20 - 20:18

    Das setzen des From auf den Mailinglisten-Absender ist doch RFC-konform.
    Die Mailingliste generiert neue Mails aus den empfangenen.
    Es werden ja auch die Empfänger nicht vorhersehbar neu gesetzt. Somit ist die ML "responsible for writing of the message".
    Eigentlich ist das Beibehalten falsch. Die Mailingliste könnte spinnen und 1000x die gleiche Mail an jeden Empfänger schicken. Das ist nicht in der Verantwortung des ursprünglichen Absenders.

  5. Re: besser keine Mailinglistenanpassungen / Sender vs From

    Autor: slowthoughts 11.08.20 - 09:10

    Nein, ist es nicht. Die Mailingliste ist eben nicht der Autor der Nachricht. Das würde nebenbei auch alle smime oder gpg-Signaturen brechen.

  6. Re: besser keine Mailinglistenanpassungen / Sender vs From

    Autor: My1 11.08.20 - 09:48

    "responsible for writing of the message" vs responsible for SENDING the message"

    Asperger inside(tm)

  7. Re: besser keine Mailinglistenanpassungen / Sender vs From

    Autor: PHPGangsta 11.08.20 - 16:51

    slowthoughts schrieb:
    --------------------------------------------------------------------------------
    > Nein, ist es nicht. Die Mailingliste ist eben nicht der Autor der
    > Nachricht. Das würde nebenbei auch alle smime oder gpg-Signaturen brechen.

    Wenn die Mailingliste den Inhalt NICHT verändert, dann bleibt die DKIM-Signatur intakt, und DMARC=pass. Dann gibt es kein Problem (vorausgesetzt die Absenderdomain arbeitet nicht nur mit SPF und DMARC, sondern SPF+DKIM+DMARC).

    Ein Problem existiert vor allem, wenn Mailinglisten den Betreff ändern ("[Listname]" vor den Betreff schreiben) oder einen Footer einfügen. Dann wird die DKIM-Signatur ungültig, und DMARC=fail. Wenn eine Mailingliste aber den Inhalt der E-Mail oder den Betreff ändert, finde ich es nicht falsch, den "Autor" auch ändern zu müssen, denn es ist nicht mehr die Original-E-Mail des Autors. Dann einen From:-Header zu setzen wie z.B.

    "Original-Name (autor@domain.de via Mailinglist A)" <list@mailinglist.de>

    und eine DKIM-Signatur von mailinglist.de hinzuzufügen (und ARC von mir aus auch noch) finde ich richtig. Und als Reply-To entweder den Autor oder die Mailingliste setzen (je nach Wunsch), finde ich kein Beinbruch, und so bieten es auch die meisten Mailinglisten-Softwares an.

    Das Grundproblem bleibt: Die Mailinglistenbetreiber updaten nicht, musst mal gucken wie viele uralte Mailmans da draußen noch betrieben werden... Ich habe mal vor 4 Jahren (als Google die Pläne für p=reject announced hat) 30 davon angeschrieben (via Administrator-E-Mail-Adresse im Mailman, oder E-Mail-Adresse auf der Webseite etc.). Rate mal wie viele Bounces es gab, und wie viele geantwortet haben, geschweigedenn in den Folgemonaten upgedated haben? Es waren 2 ,die sich gemeldet haben, die restlichen 28 haben weder geantwortet noch ihren Mailman upgedated, habe es nach 3 Monaten nochmal geprüft...

    Theoretisch ist es deren Fehler, Absenderfälschung zu betreiben. Aber erklär das mal einem Durchschnitts-Nutzer an der Hotline, der sieht nur dass E-Mails nicht ankommen, und will, dass es behoben wird. Dass der Mailinglisten-Betreiber Schuld ist, bzw. derjenige mit der defekten Weiterleitung, ist egal, man droht mit Kündigung und Beschwerden im Internet, "wenn es nicht sofort behoben wird". Deshalb aktuell leider DMARC p=none :-(

    Es bräuchte einen großen Tag X, ähnlich dem "DNS Flag Day" oder dem "World IPv6 Day" oder dem "Jabber TLS Manifest". Einen Tag im Jahr 2021, ab dem DMARC p=reject gesetzt wird, und zwar von vielen großen, mittleren und kleinen Mailprovidern gleichzeitig, um >90% der Postfächer abzudecken. Wenn das 1 Jahr vorher angekündigt wird, haben alle Mailinglistbetreiber 1 Jahr Zeit, ihr Problem zu beheben. Wenn sich danach Kunden beschweren, verweist man auf www.mail-security-day.com mit dem Hinweis, dass jemand in der Mitte (Mailingliste oder Weiterleitung) für den Fehler zuständig ist, nicht Empfänger- oder Absenderprovider.

    Und solch einen "Mail-Security-Day" bitte auch für "TLS-Zwang" beim SMTP-Protokoll, sprich keinen Fallback mehr auf Plaintext beim Transport zwischen Mailservern. Das wäre großartig.

    Sowas müsste doch zu machen sein, man müsste "nur" die großen Mailanbieter dazu bringen mitzumachen...

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Chief Information Security Officer / CISO (m/f/d
    J.M. Voith SE & Co. KG, Heidenheim
  2. Softwareentwickler C# / .NET (m/w/d)
    IS Software GmbH, Regensburg
  3. (Senior) Android Software Engineer*
    IAV GmbH, Berlin, Gifhorn
  4. Mitarbeiter (m/w/d) Strategischer Einkauf IT Dienstleistungen
    W&W Service GmbH, Ludwigsburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. Hades PS5 für 15,99€, Doom Eternal PC inkl. Metal Plate für 14,99€,)
  2. 1.000€ MMOGA-Gutschein gewinnen
  3. (u. a. Tom Clancy's Rainbow Six Siege - Deluxe Edition für 9,50€, Tom Clancy's Rainbow Six...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Discovery Staffel 4: Star Trek mit viel zu viel Pathos
Discovery Staffel 4
Star Trek mit viel zu viel Pathos

Die ersten beiden Folgen der neuen Staffel von Star Trek Discovery bieten zwar interessante Story-Ansätze, gehen aber in teils unerträglichen Gefühlsduseleien unter. Achtung, Spoiler!
Eine Rezension von Tobias Költzsch

  1. Pluto TV Star Trek Discovery kommt doch schon nach Deutschland
  2. Star Trek Discovery kommt nicht mehr auf Netflix

Merck: Von der Apotheke zum zweitbesten IT-Arbeitgeber
Merck
Von der Apotheke zum zweitbesten IT-Arbeitgeber

Das Pharmaunternehmen Merck ist auf Platz 2 der Top-IT-Arbeitgeber Deutschlands gelandet - wir wollten von den Mitarbeitern wissen, wieso.
Von Tobias Költzsch


    Koalitionsvertrag: Was bedeuten die Ampel-Pläne für die Elektromobilität?
    Koalitionsvertrag
    Was bedeuten die Ampel-Pläne für die Elektromobilität?

    Nach dem Willen der Ampelkoalition sollen 15 Millionen Elektroautos bis 2030 auf deutschen Straßen unterwegs sein. Wir haben uns angeschaut, wie das genau umgesetzt werden soll.
    Eine Analyse von Friedhelm Greis

    1. Ranger XP Kinetic Polaris bringt Elektro-Buggy mit 82 kW
    2. Elektroauto Mercedes EQS 350 als Basisversion mit 90-kWh-Akku bestellbar
    3. Elektro-Kombi Mercedes-Benz startet Verkauf von Siebensitzer EQB