MAIL FROM:<> blocken

Nein, das ist absolut valide und von den entsprechenden RFCs vorgesehen für Bounces, Auto-Replies etc, u.a. um Endlos-Loops zu verhindern.

Ich verstehe leider nicht, was du damit bezwecken willst.

Zitat von patrick

Ich verstehe leider nicht, was du damit bezwecken willst.

Er möchte gefälschte Mails blockieren, da der b1gMailServer aktuell keine vollwertige DMARC-Prüfung durchführen kann. Zusätzlich gibt es einige Punkte, die mir im Bereich SPF noch fehlen und die ich bereits angesprochen hatte.

SPF

Aktuell kommt es dazu, dass SPF auch dann abgelehnt wird, wenn große, legitime Absender sehr umfangreiche include:-Ketten verwenden und die SPF-Prüfung aufgrund von DNS-Lookup-Limits oder Timeouts fehlschlägt. In diesen Fällen wird der Versand fälschlich blockiert, obwohl der Absender korrekt konfiguriert ist.

Gleichzeitig wäre es sinnvoll, SPF none nicht mehr vollständig zu akzeptieren, sondern dieses Ergebnis zumindest als zusätzlichen Negativ- oder Ablehnungsfaktor zu berücksichtigen – insbesondere in Kombination mit weiteren Auffälligkeiten wie leerem Return-Path <> oder einem ungültigen bzw. auffälligen HELO/EHLO.

Das ließe sich gut kombinieren, etwa über Regeln wie:

• SPF-Status
• Return-Path
• HELO/EHLO
  Wenn mehrere dieser Kriterien gleichzeitig negativ sind, sollte eine Ablehnung erfolgen.

Schutz von IMAP, SMTP und POP (aus meiner Sicht noch wichtiger)

Noch wichtiger finde ich aktuell jedoch den Schutz der externen Schnittstellen (IMAP, SMTP, POP). Das BSI arbeitet derzeit an einem Maßnahmenplan zur weiteren Absicherung von Webmail und Schnittstellen. Im Forum gab es dazu bereits einen Vorschlag, den ich für äußerst wertvoll halte:

Externe Schnittstellen sollten nur noch per Token erreichbar sein.

Konkret zum Beispiel so:

1. Jeder Kunde erhält einen individuellen Token, der im Webmail einsehbar ist
2. Wenn diese Option aktiviert ist, können externe Schnittstellen ausschließlich mit diesem Token genutzt werden
3. Eine Anmeldung mit dem normalen Passwort wird dann abgelehnt

Warum ich das für wichtig halte:

1. Passwörter sind faktisch kaum noch sicher. Wird ein Passwort kompromittiert, kann ein Angreifer innerhalb von Sekunden auf den Account zugreifen und zumindest alle Mails lesen
2. Externe Schnittstellen lassen sich nicht sinnvoll mit Passkeys oder klassischem 2FA absichern – das funktioniert nur im Webmail

Aus meiner Sicht ist diese Token-Lösung daher ein „Must-Have“. Technisch müsste der Mailserver dann statt auf die Passworttabelle auf eine Token-Tabelle prüfen. Oder übersehe ich hier einen grundsätzlichen Denkfehler?

Du kaperst hier leider nur den Thread für deine eigenen Themen. Vermutlich wäre ein eigener Thread sinnvoller. (Oder gleich ein Patch/PR auf GitHub.)

Das Akzeptieren leerer Return-Paths ist ein wichtiger Aspekt, um standardkonform E-Mail-Server zu betreiben. Ein leerer Return-Path kann schon deshalb keine Fälschung sein, da er leer ist. Verstehe also nicht, inwiefern das irgendwem helfen soll.

Klingt für mich eher nach einem anderen Problem, wenn die nicht zugestellt werden können. Sind das vllt. Autoresponder oder Weiterleitungen deiner User? Die werden nämlich auch mit leerem Return-Path versendet.

Zitat von informant

ps: Denny warum baust du dir das nicht so wie du willst oder machst nen extra Thread dazu im Thema: gewünnschte Features oder so...?

Weil ich dachte, dass es auch mein Problem zielt mit dem fehlenden return-path....Diese Betrüger mit den angeblich echten Passwörtern verwenden noreply@domain.de (gefälschte E-Mail Adresse) und der Return-Path ist dann leer, das sowas überhaupt durchkommt ohne gültigen return-path, das Problem ist bei mir sehr aktuell und da kam dein Thread ohne weitere Informationen dazu, passte halt