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

Ich muss das hier nochmal aufgreifen, der B1gmailserver hat aktuell keine Usererkennung. Proxmoxx stellt dann einfach alles gültige an b1gmailserver zu und b1gmailserver wird dann zum Backscatter und versucht den Ballast loszuwerden , ich kämpfe die ganze Zeit mit Outlook, jemand ne Idee muss ich proxmox wirklich auch zum Versand nutzen?

	 	ID / Typ:	339283280 (14390D50) (Ausgehende E-Mail)
 	Datum:	Heute, 09:16:06
 	Größe:	34,64 KB
	Von:	< - >
	An:	<bounces@bounce.wahrse.com>
 	Zustell-Versuch(e):	1
 	Letzter Zustell-Versuch:	Heute, 09:17:06 (2; imap.com: Timeout while connecting socket (1))
	Eingeliefert für:	System
	SMTP-User:	Unbekannt

Zitat von Denny

Ich muss das hier nochmal aufgreifen, der B1gmailserver hat aktuell keine Usererkennung. Proxmoxx stellt dann einfach alles gültige an b1gmailserver zu und b1gmailserver wird dann zum Backscatter und versucht den Ballast loszuwerden , ich kämpfe die ganze Zeit mit Outlook, jemand ne Idee muss ich proxmox wirklich auch zum Versand nutzen?

Code

	 	ID / Typ:	339283280 (14390D50) (Ausgehende E-Mail)
 	Datum:	Heute, 09:16:06
 	Größe:	34,64 KB
	Von:	< - >
	An:	<bounces@bounce.wahrse.com>
 	Zustell-Versuch(e):	1
 	Letzter Zustell-Versuch:	Heute, 09:17:06 (2; imap.com: Timeout while connecting socket (1))
	Eingeliefert für:	System
	SMTP-User:	Unbekannt

Wie sieht denn deine Proxmox-Config aus?

Ich hoffe, du hast den nicht einfach als vertrauenswürdig in b1gMailServer klassifiziert und lässt den alles annehmen; dann kann der nämlich tatsächlich alles einkippen und Backscatter und jede Menge andere Probleme sind vorprogrammiert.

Zitat von patrick

Wie sieht denn deine Proxmox-Config aus?

Ich hoffe, du hast den nicht einfach als vertrauenswürdig in b1gMailServer klassifiziert und lässt den alles annehmen; dann kann der nämlich tatsächlich alles einkippen und Backscatter und jede Menge andere Probleme sind vorprogrammiert.

Fehler gefunden:

Habe gerade in der Doku gesehen, dass ich eventuell den PMG nicht als vertrauenwürdig klassifizieren sollte, jetzt klappts mit der Empfängerverifizierung.

Grey Listing und IP Ban deaktivieren als Vertrauensstufe?

Zitat von Denny

Fehler gefunden:

Habe gerade in der Doku gesehen, dass ich eventuell den PMG nicht als vertrauenwürdig klassifizieren sollte, jetzt klappts mit der Empfängerverifizierung.

Grey Listing und IP Ban deaktivieren als Vertrauensstufe?

Das ergibt m.E. mehr Sinn, ja. Greylisting usw sollte ja schon Proxmox machen.

Zitat von patrick

Das ergibt m.E. mehr Sinn, ja. Greylisting usw sollte ja schon Proxmox machen.

Ich hatte jetzt die Doku gefunden, wenn PMG als Vertrauenwürdig eingestellt ist, dann macht er gar keine Userprüfung (immer 250) und lässt alles durch. Ich wusste nicht, dass die Userprüfung mit einer Einschränkung der Verbindung kommt. Jetzt klappt alles und die gelöschten User weden direkt in PMG abgelehnt, somit keine Nullsender mehr. Auch der Hinweis mit der Gruppensignatur in der Doku war super wichtig, seitdem keine DKIM Probleme mehr.