Willkommen im User-Forum von mailbox.org
 

SPF-Record setzen, warum kein -all?

7051719 hat dies geteilt, 5 Jahren her
unbeantwortet

Unter https://kb.mailbox.org/display/BMBOKB/E-Mail-Adressen+der+eigenen+Domain+nutzen heißt es, dass kein -all SPF Record gesetzt werden soll? Warum nicht? Minus all (-all) bsagt doch, dass keine weiteren Server außer die eingetragenen senden dürfen, das ist doch so gewollt, oder?

Antworten (4)

Foto
1

Das kann z.B. bei Weiterleitungen Probleme machen.

Foto
1

Gibt es da noch weitere Probleme? es hat natürlich den Nebeneffekt, dass auch jeder von meiner Adresse aus senden kann. Entweder keine Weiterleitungen dafür kann auch nur ich von der Adresse senden oder jeder kann von meiner Adresse senden.

Foto
1

Es gibt bei Videos von Vorträgen zu dem Thema im Netz zu finden, einfach Heinlein und spf im Netz suchen.

Foto
1

der empfangende Mailserver ist jedoch nicht gezwungen, deine Policys zu befolgen. Insofern ist die ganze Gaudi nur mittels DKIM und DMARC sinnvoll

Foto
1

Es kann bei MBO onehin jeder von deiner Email Adresse aus mails versenden. Wenn du einen DKIM Schlüssel hinterlegt hast, dann wird dieser sogar verwendet, wenn ein anderer MBO User deine Adresse als Absender benutzt.


Ein -all würde dich also nur davor schützen, dass kein anderer Server Mails in deinem Namen versendet.

Foto
1

Das wollte ich mal ausprobieren. Hätte ich jetzt nicht erwartet, dass das geht. Warum ist das nicht geschützt und wird per SMTP Auth abgeklopft, ob der User die Adresse oder die Aliase hinterlegt hat, über den gesendet wird?

Foto
1

Aber nicht den Envelope Sender!? [1] Du hast wahrscheinlich nur den From:-Header verfälscht? Hast du dir den Header von der empfangen E-Mail genauer angeschaut? Da taucht sicher die richtige E-Mail Adresse auf!?

[1] http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps

Foto
1

Doch auch der Envelope Sender ist dann falsch. Die Mail ist nicht von einer legitimen zu unterscheiden, selbst die DKIM Signatur ist gültig, selbst wenn ich eine Mailadresse fälsche die nicht die mailbox.org Domain nutzt, aber über die mailbox.org Server läuft.

Das ganze Thema habe ich auch schonmal hier -> https://userforum.mailbox.org/topic/mailbox-org-smtp-server-stellt-mails-mit-gefakten-absender-zu diskutiert, auch Peer hat sich dazu schon zu Wort gemeldet, so wirklich befriedigend war das Ergebnis aber leider nicht.

Hier eine heute abgeschickte Beispiel-Mail mit p.heinlein@mailbox.org (verzeihe es mir Peer) als Absender an eine Gmail Adresse von mir, gesendet über meinen normalen mailbox.org Account. Ich kann keinen Hinweis darauf finden, dass die mail nicht wirklich von p.heinlein@mailbox.org verschickt wurde.


  1. Delivered-To: [redacted]@gmail.com
  2. Received: by 2002:a02:19c4:0:0:0:0:0 with SMTP id b187csp1130012jab;
  3. Tue, 20 Nov 2018 13:04:03 -0800 (PST)
  4. X-Google-Smtp-Source: AJdET5fyxQhPkvI/gtyU/F2Cekl/SAjf11VujEfX85/0y/ZgcA5bEQUF0PTb8mYvWjxOdgLTVJuc
  5. X-Received: by 2002:a17:906:c5a:: with SMTP id t26-v6mr3133841ejf.140.1542747843883;
  6. Tue, 20 Nov 2018 13:04:03 -0800 (PST)
  7. ARC-Seal: i=1; a=rsa-sha256; t=1542747843; cv=none;
  8. d=google.com; s=arc-20160816;
  9. b=UnDI2xDK8kePhFvlL1yEha9jC8v/DqcBh4ofjnn+pPyaBTFCB38WW9/vDSBJjTahoJ
  10. dJhR5Wznp6VUtWcL4GE8j0PLimOrmo59NVgQOlqVIUM385rIOwvApSsSVS4tbDNBkyMc
  11. 039FwC+mHtFd/EuEXQqkbvJngdOV2F8Jjd+6MKRlwUeCOA2RgPjgqfqsLEdyQIDXFQf9
  12. kzjab+sFxicsCflycaqTMtwTUGf04J3Gp31GelGqJyvRKPVD8PiyYk0w9jBRJDSLlihw
  13. 8pp7eIF2OkZkkTayABc1ezcisRojcKuKt6et0GKU4W/XWLbtptn2Z7mKB4cgF8OdJi35
  14. /CPQ==
  15. ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
  16. h=content-transfer-encoding:mime-version:date:message-id:subject:from
  17. :to:dkim-signature;
  18. bh=z/994Tdmf5f0KwPWF8mUfo3MOE5jKhmHSlp7TcM0SKU=;
  19. b=dhQaKWPHZkWKbVBNk7m5XnPcuI/AoIq0ykjxEDOQMlN20o+8Dih62FZJpCy2ZVTJ5E
  20. WiTKWIDAFnfGMXUZ/vWjvrH6LaQgteZjN46OuK2cjHkaQQ85BQ75Su6xt6ViGbfSMVDI
  21. hxVukTXiLAgf0pE8yCw/wUBBo+l0YeNkBAFZbSUFXCalVebhTGa4850zBixr3oMP2T3w
  22. wFQbQZNaOqnKk9mqJvcqSDPX9WyRpl1SNbtik7AR2IddMohP1GnaKr1G4H9wgSq6aKT3
  23. qKgmeGeyFbcUwROLgBV0ePvRful5uOPR8ez36RVoM5WXdbjwg1ZbMXtWpEbUjHXB5smK
  24. zpYA==
  25. ARC-Authentication-Results: i=1; mx.google.com;
  26. dkim=pass header.i=@mailbox.org header.s=mail20150812 header.b=iskjKvnx;
  27. spf=pass (google.com: domain of p.heinlein@mailbox.org designates 80.241.60.215 as permitted sender) smtp.mailfrom=p.heinlein@mailbox.org;
  28. dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mailbox.org
  29. Return-Path: <p.heinlein@mailbox.org>
  30. Received: from mx2.mailbox.org (mx2.mailbox.org. [80.241.60.215])
  31. by mx.google.com with ESMTPS id p21-v6si4090971ejz.262.2018.11.20.13.04.03
  32. for <[redacted]@gmail.com>
  33. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
  34. Tue, 20 Nov 2018 13:04:03 -0800 (PST)
  35. Received-SPF: pass (google.com: domain of p.heinlein@mailbox.org designates 80.241.60.215 as permitted sender) client-ip=80.241.60.215;
  36. Authentication-Results: mx.google.com;
  37. dkim=pass header.i=@mailbox.org header.s=mail20150812 header.b=iskjKvnx;
  38. spf=pass (google.com: domain of p.heinlein@mailbox.org designates 80.241.60.215 as permitted sender) smtp.mailfrom=p.heinlein@mailbox.org;
  39. dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mailbox.org
  40. Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 74313A116B for <[redacted]@gmail.com>; Tue, 20 Nov 2018 22:04:03 +0100 (CET)
  41. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-transfer-encoding:content-type:content-type:mime-version :date:date:message-id:subject:subject:from:from:received; s= mail20150812; t=1542747842; bh=z/994Tdmf5f0KwPWF8mUfo3MOE5jKhmHS lp7TcM0SKU=; b=iskjKvnxIlqYPwBsrQeFcTmC6zXIQbo8u6FO2hft3zyT31Eww +6mK4RbCJK9udxi3U1oHFI1FTjMI29B7oPLoEPUHiWCZd6A6y9cdnh/VFC8WKshi 1IGRD50BGH9hJwESumwgRwt9f+Wg0iS3kw4qlfEt9mJ5S6V9LB0g4C9g7rF5LLNe FhlQYKIxalK1DbJjK+hEB456MYBfGD2P8feW26m+3isK1sgoDvnYw1tflDTFGAWw x0B9d+vxRIHL0FIXqxCahcnXd8yI2xKGZjACbSEvdU3FCGXEdhmyHy3tpQKTKvQw Yn7n280dFD+20S24EF0zH7EoZXtqYx1z0uqrg==
  42. X-Virus-Scanned: amavisd-new at heinlein-support.de
  43. Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id xSgnadwTTEuM for <[redacted]@gmail.com>; Tue, 20 Nov 2018 22:04:02 +0100 (CET)
  44. To: [redacted]@gmail.com
  45. From: falscher Peer <p.heinlein@mailbox.org>
  46. Subject: gefakter Absender
  47. Message-ID: <03151815-5715-4ecc-4eb6-b40cceec5828@mailbox.org>
  48. Date: Tue, 20 Nov 2018 22:04:02 +0100
  49. MIME-Version: 1.0
  50. Content-Type: text/plain; charset=utf-8
  51. Content-Transfer-Encoding: 7bit
  52. Testinhalt

Foto
1

Wäre es nicht korrekt, sowas hier nicht zu posten, sondern dazu direkt Kontakt mit mailbox.org aufzunehmen? Das hier ist nicht der Helpdesk, sondern das Userforum.

Foto
2

Es gibt dazu nichts zu sagen, was nicht auch schon x-mal gesagt wurde und man auch in jedem meiner 15 Jahre alten Vorträge nachlesen kann:


*) Mail-Absender sind "fälschbar". Das ist keine Security-Lücke, sondern "by Design". Das ist Absicht. So funktioniert Mail. Das hat man absichtlich damals so gemacht.


*) SPF ist "broken by design", kann nicht funktionieren macht mehr Stress, als dass es nützt. Quasi jeder, der was von Mail versteht, verflucht das Zeug. Dass SPF eingesetzt wird hat was mit der Marktmacht von Google & Co zu tun, die das aus verschiedenen Gründen haben wollen und nach deren Pfeife getanzt wird, auch wenn die Admins es selber zum k***tzen finden.


*) Authentifzität wird durch PGP- oder S/MIME-Signaturen erzeugt. Nicht durch SPF-Records.


*) Würde man Absenderadressen beschränken würde man Stress mit catch-alls kriegen *UND* es wäre total sinnlos, weil auf X-anderen Wegen trotzdem dieser Absender über Drittsysteme eingeschleust werden kann (übrigens, ja auch mit validen DKIM-Signaturen und SPF-IPs, was soll der ganze Quatsch also?).


Es tut mir wirklich leid, aber ich kann dazu nichts anderes sagen:


Mail ist Mail.

Mail funktioniert so, wie Mail konzipiert wurde.

Hier ist gerade alles richtig und zutreffend

Wer Mail anders haben will kann RFCs schreiben und Mail neu erfinden.

Ich sehe hier keinerlei Problem.

Hier ist alles schicke und korrekt. Weil Mail eben wie Mail funktioniert.


Sorry. Aber ich kann dazu echt nix anderes sagen. Jede andere Antwort ist fachlicher Unfug.

Foto
1

(Ich bin ab morgen früh für fünf Tage offline und werde bis nächste Woche nicht wirklich weiterdiskutieren können.)

Foto
1

Danke für die Information.

Foto
1

Was mit noch nicht ganz klar ist, wenn eine Mail mit gefälschten Absender auf anderem Wege eingeschleust wird, ist dies doch über die Mailheader zu erkennen? Somit wäre nicht mehr der als "richtig" in SPF angegebene Mail Server aufgeführt. Wie soll das den gehen, mit validen DKIM Signaturen, von einem Drittsystem den richtigen Absender vorgaukeln?

Wäre es nicht einfach möglich über die smtpd_sender_restrictions in Postfix die Alias Adressen mit dem authentifizierenden SMTP User abzufragen? Von den Catch all Adressen kann im Webmailer auch nicht gesandt werden, sondern nur von den explizit angelegten, warum soll das dann im Mailclient möglich sein?

Foto
1

Hallo,


ich bin hier, weil ich mich für E-Mail Sicherheit interessiere, aber weniger hinsichtlich Anonymität oder Abhörsicherheit sondern hinsichtlich Authentizität mit jedermann im Geschäftsleben. Den Beitrag oben von Markus91 habe ich nachvollzogen.

Da brechen Welten zusammen und Träume platzen wie Seifenblasen!

Auch ich (Nicht-Administrator, gefährliches Halbwissen) hatte gehofft, dass sich E-Mail Absender mittels SPF (mit restriktiver Serverauswahl und "-all"), DKIM Signaturen, restriktiver _dmarc policy und einem E-Mail Host, der ein entsprechendes Angebot hätte authentifizieren lassen. Das scheint mir etwa die kollektive Hoffnung widerzuspiegeln.


Und das scheint bei einem Multi-Domain Multi-Entity Multi-User E-Mail Provider nicht zu gehen.

Ich darf ich mich ganz herzlich für die Interessanten Beiträge bedanken und ziehe meine entsprechenden Schlüsse.

Der ganze SPF, DKIM, DMARC Aufwand scheint also nur bei einem entsprechend aufgesetzten proprietären Server für eigene Domains und Accounts zu einem sinnigen Konzept zu geraten. Der einzelne Account, die einzelne Adresse auf einem shared Host sind offenbar ganz einfachdie falsche Skala für die Server- und Domainbasierten Mechanismen.


Hier also (s.o.): "*) Authentifzität wird durch PGP- oder S/MIME-Signaturen erzeugt. Nicht durch SPF-Records."

Vielen Dank für die Klarstellungen.

Foto
Foto
1

Aber ganz andere Frage: Mailbox.org hat seine spf-Einstellung von neutral auf softfail geändert. Weiß jemand warum?

Foto
1

Ich würde mal schätzen, weil der softfail ja genau aussagt, dass eigentlich niemand von einem anderen Server aus versenden sollte, es aber mal vorkommen kann. Also eigentlich die treffenere Aussage als das neutrale ?all.

Foto
1

Weil es große Provider gibt (pardon: Eigentlich nur den einen mit G) der das gut findet und dessen Spamschutz latent besser ausfällt, wenn man softfail gesetzt hat. Darum und nur darum.

Foto
1

Es gibt ja Provider, die direkt -all (fail) eintragen. Würde der Spamschutz bei einem Provider mit G dann auch noch besser ausfallen? Warum dieser Eintrag in der Knowlege Base als kritisch bis fachlich falsch angesehen wird, ist der oben genannte mit den Weiterleitungen?

Foto
1

@Peer Heinlein: Darf ich das so verstehen, dass Sie unter den gegebenen Umständen auch für die eigene - über mailbox.org laufende - Domain ~all empfehlen?!?

Foto
1

@Mesmerizing: ich würde sagen, ja - so steht es zumindest in der offziellen Anleitung zur Einbindung der eigenen Domain (SPF, DKIM und DMARC: Spam-Reputation verbessern und Bounces vermeiden (mailbox.org). Ich habe es jedenfalls mit ~all genau so für meine Domain mit Mailbox.org gemacht.

Foto
Foto
2

@Thomas91

Ich habe gerade mal kurz nachgelesen wegen SPF, u.a. hier: https://de.wikipedia.org/wiki/Sender_Policy_Framework

Ich fände es gut, wenn du deine Aussagen - die irgendwie auf scheinbar schlimme Unterlassungen bei mailbox.org hindeuten - in Bezug auf die recht heftigen Unzulänglichkeiten von SPF konkretisierst.

Ich hatte dein Posting gestern Abend zum Anlass genommen, direkt bei Peer Heinlein nachzufragen, der dann ja auch - wie so oft - ganz fix geantwortet hat.

Ich finde es nicht in Ordnung, hier im offenen Userforum Dinge so darzustellen, dass im Ergebnis wegen der unvollständigen Darstellung des Sachverhaltes der scheinbare Eindruck von echten Problemen entsteht, die es so nicht gibt. So zumindest meine Meinung.

Foto
3

Die Ausführungen von Herrn Heinlein klingen nachvollziehbar, mailbox.org verhält sich absolut RFC-konform und die Unzulänglichkeiten von Mail, SPF, DKIM, etc. sind halt mal so. Gleiches gilt im Übrigen auch für den SIP-Standard, über welchen sich die Caller-ID problemlos spoofen (fälschen) lässt. So gesehen kann die SIP-Caller-ID durchaus mit dem Mail-Absender verglichen werden. Leider führt dieser "Makel" im Standard nun dazu, dass es mittlerweile kaum zu kontrollierende Kriminalitätsphänomene gibt, welche diese Schwachstellen ausnutzen. Ich nenne nur mal die Enkeltrick-Masche oder Legendenbetrügereien mit falschen Polizeibeamten etc. Hier trifft es halt wie immer die Schwächsten in unserer Gesellschaft, die älteren und nicht technikaffinen Menschen und diese werden mitunter um ihre Existenz und Alterssicherung gebracht.

Die Möglichkeit, den E-Mail-Absender zu fälschen, kann natürlich ebenso für kriminelle Machenschaften missbraucht werden. Ich nenne hier nur mal Spam-Mails, Mails mit Schadsoftware, Phishing-Mails, etc. Hier trifft es zumeist auch die weniger technikaffinen Mail-User. Da werden dann Mail-Postfächer durch erbeutete Zugangsdaten benutzt um wiederum Schadsoftware zu verteilen, was leicht zu einer Hydra werden kann und es geht immer so weiter und weiter.

Die Frage, die sich ein Mailprovider wie mailbox.org an diesem Punkt stellen muss ist nun folgende? Will ich mich auf biegen und brechen RFC-konform verhalten und sehenden Auges diese Missstände akzeptieren oder will ich hier Flagge zeigen, Verantwortung ergreifen und Mittel und Wege finden, dass zumindest über meinen E-Mail-Dienst diese Dinge (Absender-Spoofing mit validen DKIM-Signaturen) nicht mehr so leicht möglich sind? Möglicherweise ist dies eine enorme technische Herausforderung um auch künftig alle Funktionalitäten, wie z.B. Catchall, sicherstellen zu können. Ich denke jedoch, dass es die Sache wert wäre...

Hinterlassen Sie einen Kommentar
 
Dateianlage anfügen