Beiträge von Denny

  • MAIL FROM:<> blocken

    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

  • MAIL FROM:<> blocken

    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?

  • Feedback zu b1gMail 7.4.2 veröffentlicht

    Wenn eine E-Mail das interne Speicherlimit überschreitet, erscheint aktuell kein Hinweis oder Dialog.
    Die Nachricht wird zwar korrekt versendet, aber nicht im Ordner „Gesendet“ oder als Entwurf gespeichert.

    Das liegt daran, dass die Mailgröße intern nach der MIME-Kodierung deutlich zunimmt – z. B. kann aus einer 25 MB-Datei durch Kodierung eine effektive Größe von ca. 38 MB werden.
    Das überschreitet dann das interne Speicherlimit des Accounts, wodurch der Speichervorgang scheitert – allerdings ohne Fehlermeldung.

    hier mal im Debug eine 38MB wav: === StoreMail run at 2025-10-10 00:27:06 ===
    Mail size: 55292475 bytes
    Error: Mail too big konnte man nur intern nachvollziehen

    ---edit

    Das bedeutet, nicht nur die email.compose.php muss sicherstellen, dass die E-Mail nach der MIME64-Kodierung tatsächlich maximal 25 MB groß ist (und nicht 30 MB), sondern im Idealfall bereits vor dem Senden eine entsprechende Warnung oder Ablehnung ausgegeben werden sollte.

    Ich habe das Anlagen-Limit daher jetzt mit dem Faktor 1,33 angepasst.
    Das heißt: Die tatsächliche Größe, die beim Hinzufügen einer Anlage berechnet wird, ist jetzt Größe × 1,33.
    Der Kunde wundert sich zwar vielleicht, warum bei einer 20 MB-Anlage das 25 MB-Limit bereits erreicht ist – aber so gibt es keine Beschwerden mehr, dass die Mail anschließend nicht gespeichert oder zugestellt wird. Besser wäre die Ermittlung der tatsächlichen Größe aber so geht's erstmal

  • Feature-Request: SPF = none ablehnen

    Ja, die kommen meist von gehackten Servern mit SPF pass aber es gibt noch eine Menge an Spam die SPF none hat und wenn man das nur kurz einschaltet reciht das manchmal schon um abzuschrecken. Diese Mails mit Passwörtern kommen in Wellen, jetzt sind es sogar schon Morddrohungen mit BTC, wird immer verrückter

  • Feature-Request: SPF = none ablehnen

    Zitat von informant

    Fehlerhafte sind normalerweise lt. Norm auch nicht vorhandene. Jedoch wird dann der EIngang an eMail sum >= 90% schrumpfen, da soviele keinen SPF haben lt. Statisik.

    Ja, das ist genau das Problem. Viele nutzen überhaupt kein SPF, aber gerade bei Google und Outlook wird es mittlerweile immer stärker vorausgesetzt. Man könnte es daher zeitweise einschalten und mitlaufen lassen.

    DANE teste ich auch nicht, weil damit praktisch gar nichts mehr durchkommt. Den HELO-Check habe ich ebenfalls deaktiviert und beim DKIM-Check brauchen wir eigentlich gar nicht erst anfangen – das ist aktuell noch zu wenig zuverlässig umgesetzt.

  • Feature-Request: SPF = none ablehnen

    Moin,

    wäre es möglich, in einer künftigen Version des b1gMail-Servers eine Option einzubauen, mit der eingehende Mails abgelehnt werden können, wenn für die Absenderdomain kein gültiger SPF-Record (SPF = none) vorliegt?

    Hintergrund:

    • Immer mehr Phishing- und „Leak“-Mails kommen von Domains ohne SPF-Eintrag.
    • Diese Nachrichten enthalten häufig echte Passwörter und umgehen bisherige Filter.
    • Google & Co. lehnen solche Mails oft strikt ab, was für saubere Mailflows sorgt.

    Eine konfigurierbare Einstellung (z. B. reject_spf_none = true) wäre für die interne Verarbeitung und Spamprävention sehr hilfreich, um die Dienste sauber zu halten.

    Grüße

  • Speicherung ein Objekt pro User

    Moin, danke erstmal. Dann lasse ich es so – anders geht’s halt nicht. Dumm ist nur das Dateisystem mit so vielen kleinen Dateien und Ordnern, das macht mir etwas Sorge für die Zukunft, irgendwann in den nächsten Jahren sind die 100.000.000 Datein voll, ist schon bisschen naja

  • Feedback zu b1gMail 7.4.2 veröffentlicht

    Moin, nene die hatte ich nur beiläufig gesehen wo ich nach fehlern gesucht hatte. Es wird keine Fehlermeldung geworfen, hab das System nochmal neu aufgesetzt gleiches Problem bei den PHP Datein also email.php. organizer.php - hier mal an bsp email.php


    Code
    <-index.tpl-> 
{foreach from=$_jsFiles.li item=_file}	<script type="text/javascript" src="{$_file}"></script>
{/foreach}
    Code
    <-email.php-> 

$tpl->addJSFile('li', 'clientlib/selectable.js');
$tpl->addJSFile('li', $tpl->tplDir . 'js/email.js');

    $tpl->tplDir ist laut email.php das Standard-Template nicht das Premium-Template - also bekomme ich alle Scripte die clientseitig inkludiere /modern3/script.js aber /modern/script.js bei den serverseitig importierten.


    Kannst du das Problem reproduzieren oder ist da bei mir was falsch?


    Zudem sei gesagt, dass der Fehler auch schon bei der alten Version von b1gmail also vor open_source bestanden, konnte ich gerade sehen, ist scheinbar auch nie jemanden aufgefallen weil vermutlich immer alle die selben themes verwenden, wenn man aber jetzt ein Theme hat welches eine andere email.js benötigt macht das Theme nicht das was es soll

  • E-Mail Anlagen-Filter

    Moin,

    ja, das ist wirklich keine optimale Lösung. Besser als gar nichts, aber wenn man bedenkt, dass die Mails bei mir live reinkommen, ist das nicht wirklich sinnvoll. Mein lokaler Scanner nimmt die Sachen zwar beim POP3-Abruf raus, aber eigentlich dürften die Mails gar nicht erst bis zum Postfach durchkommen.

    Werde mir daher wohl über kurz oder lang Proxmox Mail Gateway anschauen – gefühlt wird das Problem nämlich immer schlimmer.

  • Speicherung ein Objekt pro User

    Zitat von patrick

    sshfs scheint kein Locking zu unterstützen, daher kann das gefährlich werden. Ich würde es nicht tun.

    Mein neues Setup

    • Mailserver + Storage → laufen auf einer Instanz
    • MariaDB + Apache2 (Webmail) → laufen auf einer separaten Instanz
    • Verbindung über internes 10G-Netz

    Nun meine Überlegung:
    War es nicht so, dass Apache/Webmail eigentlich nichts schreibt, sondern nur liest, und die gesamte Speicherarbeit (Mails ablegen, verschieben, löschen, Anhänge speichern usw.) sowieso vom Mailserver erledigt wird?
    Wenn das stimmt, dann wäre die Aufteilung ja eigentlich unproblematisch – oder habe ich hier etwas übersehen?

    Selbst wenn ein User im Webmail eine Mail verschickt, geht das doch direkt an den Mailserver, der sie dann abspeichert und verarbeitet, korrekt?

    Hintergrund:
    Ich überlege gerade, Maildaten im SQLite-BLOB-Format auf dem Storage zu halten, da die Speicherplatzeinsparung enorm ist. Wir reden hier über ca. 30 TB Maildaten, das wäre also ein echter Gamechanger.

    Frage:

    • Gibt es aus eurer Sicht eine Alternative, die ähnlich effizient wäre?
    • Oder spricht etwas dagegen, das so zu lassen, wie es ist?

  • Speicherung ein Objekt pro User

    Moin,

    ich erinnere mich, dass es bei b1gMail 7.4 den Hinweis gab, die Speichermethode „eine Datei pro Postfach“ (ein Objekt pro Nutzer) nicht auf externem Storage zu betreiben. Gilt das noch?
    Ich möchte das nun erstmals über SSHFS einsetzen. Testweise lief es früher bereits, ohne dass mir Probleme aufgefallen sind.

    Gern würde ich dennoch besprechen, ob ich das so weiterlaufen lassen sollte. Seit der Umstellung auf SSD sind die Suchzeiten deutlich gesunken, allerdings habe ich rund 50 Mio. E-Mails im Bestand.

  • Feedback zu b1gMail 7.4.2 veröffentlicht

    Frage: Das Premium Plugin sollte doch in Bezug auf die Pfade gefixt worden sein, leider bekomm ich immer noch nur /modern/email.js obwohl das Premium Theme /modern3 heißt :/ hab auch nur ne Warning die vermutlich damit nichts zu tun hat:


    [06-Aug-2025 11:22:05 Europe/Berlin] PHP Warning:  Undefined variable $maxORder in /var/www/web0/htdocs/plugins/premiumaccount.plugin.php on line 2729
    [06-Aug-2025 11:22:05 Europe/Berlin] PHP Warning:  Undefined variable $maxORder in /var/www/web0/htdocs/plugins/premiumaccount.plugin.php on line 2729
    [06-Aug-2025 11:22:05 Europe/Berlin] PHP Warning:  Undefined variable $maxORder in /var/www/web0/htdocs/plugins/premiumaccount.plugin.php on line 2729
    [06-Aug-2025 11:22:05 Europe/Berlin] PHP Warning:  Undefined variable $maxORder in /var/www/web0/htdocs/plugins/premiumaccount.plugin.php on line 2729

    edit:

    Hab das System jetzt sogar nochmal komplett neu gemacht und immer noch der falsche template Pfad, auch bei Organizer

  • SPF none zulassen/ablehnen

    Moin,

    mal ganz ehrlich – ich wäre echt dafür, dass der b1gMailServer eine Funktion bekommt, mit der man solche Sachen wie „SPF none“ oder auch gefälschte Absender konsequent blocken kann.
    Gerade jetzt, wo so viele Fake-Mails und Erpresser-Müll unterwegs sind, wäre das wirklich ein Segen.

    Mir würde schon ein Schalter reichen wie:
    „E-Mails ohne SPF-Eintrag ablehnen“
    … oder dass man zumindest eine eigene Policy setzen kann, was mit solchen Mails passieren soll.

    Wer sieht das noch so?
    Vielleicht liest ja jemand vom Entwicklerteam mit, oder gibt’s schon einen Trick, wie man das halbwegs sauber in b1gMailServer abbilden kann?

    Fände das echt hilfreich, bevor ich weiter an irgendwelchen Workarounds schraube oder wieder alles per Hand filtern muss…

    Grüße

    Norbert


    ich bekomme aktuell viele X-Mozilla-Status: 0001
    X-Mozilla-Status2: 00000000
    Return-Path: <> ?
    Received: from [10.88.0.3] (115.193.32.34.bc.googleusercontent.com [34.32.193.115])
    by mail.domain.de (b1gMailServer) with ESMTP id 237E83A8
    for <domain@domain.de>; Tue, 24 Jun 2025 18:47:30 +0200 (CEST)
    Received-SPF: None ?
    identity=; client-ip=34.32.193.115;
    helo=[10.88.0.3]
    Content-Type: multipart/related; boundary="===============3329146821057136785=="
    MIME-Version: 1.0
    From: "emailn.de" <no-reply@domain.de>
    To: emailn@emailn.de
    Subject: =?utf-8?q?Failure_Delivery_Messages_domain=40domain=2Ede?=
    X-Priority: 2
    X-Antivirus: Avast (VPS 250625-2, 25.6.2025), Inbound message
    X-Antivirus-Status: Clean

    --===============3329146821057136785==
    Content-Type: text/html; charset="utf-8"
    MIME-Version: 1.0
    Content-Transfer-Encoding: base64


    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

  • Admin-CP Sessionübernahme

    Zitat von ManDal

    Betreibe einige Eigenentwicklungen und da prüfe ich beim Login immer ob es von der IP bereits ein Login gab und falls nicht informiere ich die Admin E-Mail-Adresse darüber, wäre eine nette Zusatz Funktion bei der man wenigstens informiert wird wenn doch ein Login stattgefunden hat von einer IP die man nicht kennt (wäre evtl. auch etwas für den LI bereich). Weiter müsste man weg von den SIDs kommen die immer in der URL auftauchen, gibt da elegantere varianten und immer mit dem Backend gegenprüfen anhand einer id / public ip etc... ob der User immer noch der User ist der sich Angemeldet hat.

    An so etwas arbeite ich auch allerdings ist das mit IP schwierig, da braucht man viele Daten und die IP ändern sich ständig, man könnte das nach Netz machen aber das wars dann schon. Geräte-Fingerprinting und Cookie-Sessions ist so mein Ansatz auch nochmal eine Überprüfung über 2FA oder Mailbestätigung machen wenns abweicht