Beiträge von kai

    Ich habe mich beim Schreiben noch auf die Suche gemacht, ob es ein passendes qmail-spp plugin gibt.


    Und ja, das gibt es: qmail-spp-filter


    https://www.caputo.com/foss/qm…ail-spp-filter-20081106.c oder
    https://notes.sagredo.eu/files…atches/qmail-spp/plugins/


    Blocklist erstellen

    Code: /var/qmail/control/blocklist_regex_rcpts
    # input for qmail-spp-filter plugin (see greylist)
    old-email@domain.org

    Zu greylist hinzufügen

    Hinzufügen der nötigen ENV Vars "SPP_FILTER_1_DEF" + "SPP_FILTER_1_CMD"

    Code: /etc/tcp.smtp
    127.0.0.1:allow,RELAYCLIENT=""
    :allow,QMAILQUEUE="/usr/local/pd-admin2/qmail/bin/simscan",SPPCONFFILE="/var/qmail/control/greylist",SPP_FILTER_1_DEF="regexrcpt:/var/qmail/control/blocklist_regex_rcpts",SPP_FILTER_1_CMD="E550 no mailbox"

    Via tcprules die cdb neu erstellen

    tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp


    Im Log taucht das auf so auf:

    Code
    May  5 17:07:39 srv smtpd: 1714921659.676212 qmail-spp-filter:209.85.208.180: match: def #1 ('regexrcpt:/var/qmail/control/blocklist_regex_rcpts').  mailfrom='user@gmail.com', rcptto='spamtrap-45@domain.org'
    May  5 17:07:42 s1 smtpd: 1714921662.078137 qmail-spp-filter:209.85.167.47: nomatch: mailfrom='user@gmail.com', rcptto='mail@example.org'


    Einfacher wäre die Variante per badrcptto Patch (s.o.) aber passt so für mich 8)

    Aus historischen Gründen habe ich auf einer mainer Domains ein E-Mail Catch-All laufen.


    Nun möchte ich möglichst effektiv bei einzelnen Adressen so tun, als gäbe es keine Mailbox dafür und die Annahme bereits im SMTP Dialog beenden, um keine Bounce Message zu erzeugen.


    - in .qmail ist es zu spät -> erzeugt eine bounce message

    - in spamassassin habe ich nur die E-Mail uns kann damit nur die TO/CC nicht aber die BCC Fälle abdecken

    -- X-Originally-To wird scheinbar erst später durch qmail-local gesetzt und somit steht der "RCPT TO" nicht zur Verfügung

    - gibt es in pd-admin einen qmail path für /control/badrcptto (http://patch.be/qmail/) ?


    Die einzige Variante ist momentan ein "black hole" in der Form einer dot qmail Datei

    Code: .qmail-domain::org-old-email
    |/bin/true

    Damit bekommt der Sender aber nicht mit, dass die Adresse alt ist und die ganze Spam-Verarbeitung findet trotzdem statt.

    Zu 3. - In spamassassin kann man einen Score für DKIM und SPF festlegen. Mit der SE 0.426 wurde

    DKIM: roberto-netqmail-1.06.patch-2023.07.05

    mit ausgeliefert. Die Signierung und Validierung der DKIM Signatur erfolgt somit in qmail. Es gibt aber keine weitere Aktion, außer eben der Signierung oder Validierung.

    Ich hänge mich hier auch nochmal ran.

    Gibt es irgendwo eine Übersicht, welche Patches qmail genau mitbringt?


    Nach meinen Kenntnisstand sind es
    - netqmail-1.06 (http://netqmail.org/)

    - roberto-netqmail-1.06.patch-2023.07.05 (https://notes.sagredo.eu/en/qm…tching-qmail-82.html#dkim ?)

    -- Daniel Bradler verträgt das dann nicht mal ein Upate?



    Wird wirklich die DKIM Signatur beim Eingang validiert und wie äussert sich das dann?
    Ich sehe nur die DKIM Scores innerhalb von SpamAssassin.


    Um die DMARC Policies bei eingehenden Mails zu beachten finde ich derzeit nur eine Lösung per SpamAssassin:

    Setting up the DMARC filter in Spamassassin

    oder https://metacpan.org/pod/Mail::Qmail::Filter::DMARC

    Sumeragi danke für die ausführliche Antwort.


    Die o.g. Konstellation kam zustande, durch ein volles Postfach.
    Dies scheint eine der Konstellationen zu sein, die nicht bereits im SMTP Dialog geprüft werden.


    D.h. mein Server generiert die erste Mail.
    Diese Mail wird NICHT per DKIM signiert.

    Code
    Return-Path: <"<>"@sub.example.org>
    From: Mail Delivery Subsystem <postmaster@sub.example.org>
    To: <user@external-domain.org>

    Weil ich zu dem Zeitpounkt für sub.example.org noch eine strikte DMARC Policy aktiv hatte, wurde die Mail vom externen Sever nicht entgegengenommen und landete wg. unbekanntem "<>"@sub.example.org schließlich beim Postmaster.


    Was möchte ich erreichen?

    - DKIM Signatur auch für (Mailer Daemon) Mails von der sub.example.org um hier auch eine DMARC Policy zu aktivieren

    - Ablehnung bei vollem Postfach bereits im SMTP Dialog


    Unabhängig davon interessiert mich, wie man selbst am besten die DMARC Policies der eingehenden Mails prüfen kann (das aber lieber in einem extra Thread).

    Moin,


    ich habe pd-admin auf einer Subdomain laufen: sub.example.org

    example.org ist dabei eine normale von pd-admin verwaltete Domain.

    Für example.org habe ich seit kurzem SPF/DKIM und DMARC aktiviert.


    /var/qmail/control/me enthält sub.example.org


    Was mich primär irritiert ist der "leere" Return-Path der Reject Nachricht: Return-Path: <"<>"@sub.example.org>.

    Wie kann ich hier einen sinnvollen Return-Path setzen?


    Und wie handhabt ihr das mit DMARC bei Nutzung der Subdomain?

    Kann ich die Subdomain (sub.example.org), die ich für die pd-admin Installation nutze ("Hostname für pd-admin") selbst regulär in pd-admin anlegen und verwalten?

    Falls JA würde ich einen separaten DKIM Eintrag für sub.example.org erzeugen und nutzen (sofern die Mail Daemon Mails signiert auch werden!?).

    Falls NEIN kann ich ja nur die Subdomain bei DMARC ignorieren, also alles erlauben.

    Nach einer frischen Installation sieht es bei mir so (s.u.) aus.

    Und das ist auch gut so und benötigt keinen Hotfix :)


    In den FAQ muss es also eigentlich heissen:

    svc -d /service/apache24

    svc -u /service/apache24

    OK, kein Bug. Ich dachte das wäre der Sinn des Parameters, dass das im Content direkt ersetzt wird. Komisches Format.

    Wenn pd-admin hier serverseitig den username ermitteln und da ausgibt, dann wäre das wohl auch eine Sicherheitslücke.


    Solange dann https://bugzilla.mozilla.org/show_bug.cgi?id=564043 nicht gefixed wird, damit explizit ein Username abgefragt werden kann wäre doch im Falle von pd-admin aber der Platzhalter %EMAILLOCALPART% die bessere Wahl oder?


    Dann könnte ich die Einrichtung erfolgreich abschließen, wenn ich bei Thunderbird username@example.org angebe anstatt der echten Adresse.

    Ruft man für eine Domain diese URL auf, dann soll das wohl eigentlich die Thunderbird Autoconfig Werte liefern:


    https://domain.de/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=adresse@domain.de


    Bei mir werden aber die Platzhalter nicht ersetzt:


    Non TLS Hosts sollten sich ja eigentlich langsam erledigt haben, so dass man praktisch per HSTS nur einen Durchlauf pro Domain erzwingen kann .


    Zudem habe ich noch herausgefunden, dass es eine ggf. nützliche Umgebungsvariable gibt: PDA_VHOST_USER


    Ich habe es nun doch nicht gebraucht, aber ggf. nützt das Jemandem.
    Ein recht unschönes Script, um noch fast am Ende (oder an einer bestimmten Position) der httpd.conf etwas hinzuzufügen, indem man die restlichen nötigen Zeilen im VirtaulHost selbst schreibt, diesen schließt und dann seine Einträge macht und dann einen fake Virtualhost öffnet.


    #!/bin/bash

    if [ "$1" == "letztedomain.example.org" ]

    then

    echo "#httpd_vhost_module: incremental"

    echo "ErrorLog /home/errorlogs/$PDA_VHOST_USER/error_log"

    echo "Header set Strict-Transport-Security \"max-age=15768000\""

    echo "</VirtualHost>"


    cat /root/vhost-add.txt


    echo "<VirtualHost xxx.xxx.xxx.xxx:443>"

    echo "ServerName fake.example.org"

    fi

    Hatte noch Probleme beim Erneuern des Zertifikates mit dem automatisch erzeugtem non tls ipv6 Eintrag.

    Dieser hatte zu einer Endlosschleife geführt


    <VirtualHost xxxx:xxxx:xxxx:xxxx::xxxx:80>

    ServerName meinserver.example.org

    Redirect 301 / http://meinserver.example.org/

    </VirtualHost>



    Das habe ich durch einen "führenden" Eintrag in httpd24.conf-template verhindern können (und oben ergänzt).

    Code
    <VirtualHost xxxx:xxxx:xxxx:xxxx::xxxx:80>
      ServerName $$SERVERNAME
      RedirectMatch 301 ^(?!/.well-known/acme-challenge).* https://$$SERVERNAME$0
      Alias /.well-known/acme-challenge/ /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/
    </VirtualHost>

    Wem die offiziellen Signaturen nicht reichen, dern kann mit fangfrisch noch weitere Signaturen nutzen.


    Im Prinzip komplett nach Anleitung https://rseichter.github.io/fangfrisch/#_installation nur "simscan" statt "clamav" user und anpassen der Verzeichnisse


    Bash: install fangfrisch
    mkdir -m 0770 -p /var/lib/fangfrisch
    chgrp simscan /var/lib/fangfrisch
    cd /var/lib/fangfrisch
    python3 -m venv venv
    source venv/bin/activate
    pip install fangfrisch
    deactivate


    Config /etc/fangfrisch.conf anlegen


    Initialisieren

    Bash
     sudo -u simscan -- /var/lib/fangfrisch/venv/bin/fangfrisch --conf /etc/fangfrisch.conf initdb

    Cron einrichten

    Bash: /etc/cron.d/fangfrisch
    HOME=/var/lib/fangfrisch
    LOG_LEVEL=WARNING
    # minute hour day-of-month month day-of-week user command
    */15 * * * * simscan venv/bin/fangfrisch --conf /etc/fangfrisch.conf refresh

    Schön, dass man auch nach Jahren wieder über seine eigenen Kommentare stolpert :)

    Der Schalter scheint immer noch nicht standardmäßig gesetzt zu sein. DIe Datei fehlt also weiterhin nach einer Neuinstallation.


    echo 1 > /var/qmail/control/ignorewronganswer


    Weil ich aber nirgends etwas zu solch einem Patch finden kann, wäre es schön zu wissen, welche Patches die ausgelieferte qmail version erhalten hat.

    Man siehrt nur, _dass_ gepatched wurde

    # strings /var/qmail/bin/qmail-remote | fgrep ignorewronganswer

    control/ignorewronganswer


    Gibt es eine Übersicht der Patches bzw. den Sourcecode irgendwo zum Download?

    Auch wenn der Thread schon recht alt ist die Frage:


    Was ist denn der Sinn, dass die SE /usr/local/bin/perl und /usr/bin/perl auf /usr/local/pd-admin2/bin/perl umbiegt?

    Und kann man _beide_ links wieder bedenkenlos auf das System Perl umbiegen?

    Konkret geht es bei mir hier um Munin, was diverse Module braucht, die im SE Perld nicht enthalten sind.

    Und weiter geht es mit...


    Eigenen Spamhaus DQS Account nutzen



    Weiter geht es mit Spamassasin...


    Eigenen Caching DNS installiere via apt install unbound (bei Bedarf auch für alle Resolves nutzen via /etc/resolv.conf)


    iXhash2 unofficial benutzen

    Bash
    cd /usr/local/src/
    wget https://mailfud.org/iXhash2/iXhash2-2.05.tar.gz
    tar xfz iXhash2-2.05.tar.gz
    cd iXhash2-2.05/
    cp -a iXhash2.* /usr/local/pd-admin2/etc/mail/spamassassin
    cd /usr/local/pd-admin2/etc/mail/spamassassin
    chown root:root iXhash2.*
    vi iXhash2.cf (nur ix.dnsbl.manitu.net drin lassen)

    DCC installieren / nutzen

    Bash
    cd /usr/local/src/
    wget https://www.dcc-servers.net/dcc/source/dcc.tar.Z
    uncompress dcc.tar.Z
    tar xf dcc.tar
    cd dcc-2.3.168/
    CFLAGS="-O2 -fstack-protector" DCC_CFLAGS="-O2 -fstack-protector" ./configure && make && make install
    useradd -m -U -d /var/dcc -s /bin/sh dcc
    chown -hR dcc:dcc /var/dcc
    su - -c '/var/dcc/libexec/dccifd' dcc
    vi /usr/local/pd-admin2/etc/mail/spamassassin/v310.pre (DCC einkommentieren)


    Install Pyzor

    Bash
    apt install python3-venv python3-pip
    pip install pyzor
    vi /usr/local/pd-admin2/etc/mail/spamassassin/v310.pre (Pyzor einkommentieren)


    Weitere Änderungen an Spamassasin

    Mhh, dann scheinst du aber in der /etc/gai.conf IPv4 zu bevorzugen!?


    Klappen tut es jetzt mit einem ReverseProxy auf die STANDARD_IP mit beibehaltung des Hostnames per ProxyPreserveHost On :)

    Zitat

    Lösen sich die betroffenen Domains DNS-mäßig noch auf die alte Domain auf?

    Ich kann nicht sagen woran es gelegen hat, aber die alten IPs sind nun verschwunden.
    Die Hauptdomain hat einen Catchall DNS Eintrag auf die alte IP.
    Also irgendwas.hauptdomain.tld löst auf die alte IP auf.

    Auf dem Server haben die einzelnen Domains ganz normal auf die neue IP aufgelöst.
    Wären das Queries der Art kunde.tld.hauptdomain.tld gewesen, dannh hätte ich mir das erklären können...


    Update:

    Ich hatte doch was geändert. Ich hatte einen Catch-All Eintrag unterhalb der Subdomain des Servers im DNS hinterlegt, der dann auf die Server IP auflöst.

    D.h. beim Schreiben der http.conf wird noch irgendwas unterhalb des Servernamens aufgelöst und die IP hinzugefügt.
    Ich tippe auf http://www.sub.domain.tld



    Zum Thema IPv6 für die Hauptdomain

    Sumeragi ich weiß nicht wie das mit dem Proxy funktionieren soll.
    Request IP6:443 --Proxy auf--> domain:443 ist doch im Zweifel eine Endlosschleife, weil domain:443 auch präferiert IP6 nutzt und wieder bei sich selbst landet.
    Die config ballert bei mir demnach auch alle Worker voll :(


    Ein Proxy direkt auf die IP würde theoretisch funktionieren, wenn man nicht die OWASP WAF Regel aktiv hat um Zugriff direkt auf die IP zu blockieren

    Code
    SSLProxyCheckPeerCN off
    ProxyPass "/" "https://$$STANDARD_IP/" connectiontimeout=5 tmmeout=30
    ProxyPassReverse "/" "https://$$STANDARD_IP/"

    Ich habe jetzt _erstmal_ den Apache für IP6 deaktiviert Listen $$STANDARD_IP:80, was aber den großen Nachteil hat, dass die initialen Zugriffe per Browser schnarch langsam sind, weil der erst merken muss, dass auf IP6 nix reagiert.


    Den AAAA IP6 Eintrag für die Domain benötige ich zwingend, weil IP6 auch für ausgehende SMTP Verbindungen genutzt wird und somit auch der Reverse PTR gesetzt ist und der AAAA nötig wird.


    Gibt es ggf. eine offiziell "richtige" Lösung dafür Daniel Bradler ?

    Ich "kämpfe" grad mit httpd_vhosts.pl (Reihe 6 alles aktuell)


    1.) Bei den Kunden, die ich importiert habe, findet sich in der auch noch die IP vom alten Server in der VirtualHost Config.

    Ich finde nicht heraus, wo die alten IP noch herkommt.

    Im vadmin Schema ist die weder bei ip_old noch bei ip gesetzt. Und es ist auch nicht die Standard IP.

    Eine grep Suche in /opt/pdadmin/ unde /usr/local/pd-admin2 findet die alte IP auch nicht.

    -> Wo kann die noch herkommen!?


    Code
    <VirtualHost 85.neu.neu.neu:80 2a01:neu:neu:neu::neu:80 78.alt.alt.alt:80>
    ...
    </VirtualHost>


    2.) Wie kann ich den SSL VirtualHost Eintrag für den Host beeinflussen?
    Der Eintrag für Port 80 befindet sich im Template.
    Der Eintrag für Port 443 wird aber erzeugt.
    Konkret möchte ich die IP6 Adresse des Hosts in der 443 Config haben.

    -> Wie geht das? Gibt es einen "Standard ipv6" conf-Key?


    Mein jetziger Workaround ist, den erzeugten Eintrag für die ip4 Standard IP zu kopieren und in das Template mit der ip6 einzutragen.
    Das funktioniert, ist aber nicht besonders schön...

    OK, eine externe Lösung kommt nicht in Frage.

    Daher habe ich meine alte Lösung wieder reaktiviert. Aufzufinden aber nur noch auf archive.org: https://web.archive.org/web/20…t:80/tomislavr/qmail.html


    Und dann die Plugins einbinden: