SPF-Record setzen, warum kein -all?

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.

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

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

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.

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?

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

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

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.

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.

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

Danke für die Information.

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?

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.

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.

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.

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?

@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?!?

@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.