Das längste Thema

  • a paar Verneinungen zuviel; :D


    darum sagte ich ja, wenn die IP des Endanwenders beim Mailserver zum Tragen kommt, hat jemand vorher schon was falsch gemacht;

    wobei bei Endanwendern die nichts ahnend Teil eines Botnetzes sind, hast hier beim SPAMfilter sehr wohl die IPs des Endanwenders;

    oh ja :saint:, aber ihr wisst was ich meine

  • aber wer mir ne Mail schickt muss damit rechnen dass die IP dabei verarbeitet wird

    Der Spamfilter verarbeitet doch nur die IP des Mailservers, nicht die IP des Mailservers und nich die IP des Endanwenders.


    Immer langsam mit den Pferden. Meine Konfiguration verarbeitet eingehende Mails als auch ausgehende Mails.

    Mein Mailserver soll ja keine Spamschleuder werden und auch ein Ratelimiting durchführen.

    Die IPs im Header werden natürlich vor dem Milter ersetzt, die Header des IP-Paketes werden aber zwecks Überprüfung an den Milter gegeben.

    Und dieser logt außerhalb des FS Logs noch in eine Redis Datenbank.


    Die muss dann natürlich bereinigt werden, weil da einfach nachzuvollziehen ist: welcher authentifizierte Nutzer schickt wann an wen eine Mail von welcher IP.

  • Laßt Euch nicht verrückt machen. Als Betreiber des MailEingangs habt Ihr ein berechtigtes Interesse daran zu sehen, wer wann was zu schicken versuchte. Möglicherweise ist das sogar eine gesetzliche Anforderung.

    Erst wenn Ihr anfangt, die Daten zu analysieren, und Euer Terabyte großes data warehouse damit füttert und nachseht, wofür sich Eure Kommunikationspartner sonst noch interessieren, und ihnen dann entsprechende Angebote in die von Euch zugespielten Werbungen zuschneidert, wird es aus datenschutzrechtlicher, moralischer und politischer Sicht interessant.


    Ach so, Ihr betreibt kein f*book, a*zon, g*e?


    Dennoch sprechen viele Gründe dafür, nach gewisser Schamfrist (Tage?) Logs zu eliminieren.

  • Dann hat sein SMTP Server die IP-Adresse rausgegeben, obwohl er sie hätte rausfiltern können.

    genau das passiert auch bei manchen Mailanbietern, daß diese die Client-IP wegfiltern; ABER: getrackt wird das sehr wohl in den Logs ...

    das glaubt wohl niemand, daß hier Google nichts speichert, nur weil beim Empfänger es unmöglich ist, auf die Client-IP rückzuschließen;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Das ist auch ein berechtigtes Interesse von jedem Mailanbieter, zu wissen, wer (User + IP) vorhin z.B. strafrechtlich relevante Inhalte versendet hat.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • genau das passiert auch bei manchen Mailanbietern, daß diese die Client-IP wegfiltern; ABER: getrackt wird das sehr wohl in den Logs ...

    das glaubt wohl niemand, daß hier Google nichts speichert, nur weil beim Empfänger es unmöglich ist, auf die Client-IP rückzuschließen;

    In Logfiles darfst Du IPs ja unter gewissen Umständen und für eine gewisse Zeit speichern. Und ggf. musst Du solche Verkehrsdaten auch speichern. Wobei ich gerade nicht mehr weiß, wie es um die TKÜV bestellt ist.

  • ich ersetze per header_checks-Regel die Received bei meinem Mailserver durch das

    Code
    Received: from home.mail (localhost [IPv6:::1])
    	by FQDN (Postfix) with ESMTPSA id E9BEE41410
    	for <#EMAIL#>; Tue, 21 Aug 2018 19:03:43 +0200 (CEST)

    würde jemand meinen Mail-server infiltrieren, dann braucht er schon viel Energie:

    - Port 25 ist nur Incoming

    - Port 587 ist nur von meiner IPv6 zu Hause möglich (IP6tables-Regel)

    (wie schon beim SSH, auch hier einfach was 'sinnvolles' f. die IPv6 einfallen lassen)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • In Logfiles darfst Du IPs ja unter gewissen Umständen und für eine gewisse Zeit speichern. Und ggf. musst Du solche Verkehrsdaten auch speichern. Wobei ich gerade nicht mehr weiß, wie es um die TKÜV bestellt ist.

    ich liebe Abkürzungen: was soll der/die/das TKÜV sein?

    ... und falls es rejected wird per cronjob am Folgetag ins Web gestellt ...

    da läuft etwa sowas ab:

    cat /var/log/maillog | grep NOQ | ... > /var/www/html/file.log

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • geekmonkey was du natürlich bei einem MySQL / MariaDB Server tun kannst: die InnoDB Variablen optimieren. Nebst den offenen Dateien sollte InnoDB die meisten Queries auch aus dem RAM beantworten können.


    https://www.woltlab.com/article/26-innodb-optimieren/

    Das Transaction Log würde ich bei leselastigen Applikationen (bis zu 80%/20% R/W) nicht anfassen.

    Ohnehin nur interessant, wenn Schreibverluste hinnehmbar sind.

  • Ich würde das vorgehen für sinnvoll halten. Die DB mit den kleinen Daten auf der SSD und die großen Daten auf der SAS.

    Da es verschiedene Server sind würde ich nicht sagen dass der Server mit der SSD die Daten holt, nee, er gibt einfach dem Client direkt die IP des SAS Servers und der holt sie sich da ab.


    Heißt:

    Website kommt von der IP des SSD Servers

    Bilder auf der Website kommen von der IP des SAS Servers

  • Das ist eigentlich nicht typisch Debian, so wie ich Debian vor paar Jahren kannte.

    Seitdem die Meltdown/Spectre Sicherheitslücken bekannt wurden, bin ich mit Debian nur am Patchen und rebooten.

    So habe ich das Gefühl, kann auch sein, dass es mir eingebildet habe.

  • Das ist eigentlich nicht typisch Debian, so wie ich Debian vor paar Jahren kannte.

    Seitdem die Meltdown/Spectre Sicherheitslücken bekannt wurden, bin ich mit Debian nur am Patchen und rebooten.

    So habe ich das Gefühl, kann auch sein, dass es mir eingebildet habe.

    Naja… man kann einer Linux-Distribution eigentlich nicht anlasten, dass sie sich aktiv um die Bereinigung von Fehlern kümmert; Pech, wenn es wiederholt den Kernel selbst betrifft. Niemand ist gezwungen, den Rechner neu zu booten.

    Wenn die aktuelle Problematik dazu führt, dass die "Livepatch"-Funkionalität in allen Distributionen (stark) aufgewertet wird – diese schützt bei Ubuntu auch nicht immer vor Reboots –, mag das langfristig(!) sogar vorteilhaft sein. (Man-wird-ja-wohl-noch-träumen-dürfen…)

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • bei der von mir verwendeten Linux-Distri (CentOS 6) mache ich Updates nur nach Ankündigung in der Mailing-Liste;

    und wenn mehr als 1 Woche vergangen ist, seitdem ich Updates eingespielt habe ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)