Beiträge von tbc233

    Mir würde da jetzt nur eine vielleicht etwas blöde Rückfrage einfallen: Hast Du die Zeile wo das Verzeichnis eingetragen wird auch auskommentiert?

    Vielleicht darf ich nochmal zusammenfassen


    1) Das ganze hat auch mit dem Namen zu tun, mit dem sich der Server im SMTP Dialog meldet. Das steht in /var/qmail/control/me

    Nehmen wir hier mal s1.stefanb341.de an. Achtung, wenn Du den Namen da drin änderst, musste Du qmail neu starten (oder halt den ganzen Server rebooten wenn Du Dir damit leichter tust).


    2) In der Folge sollte s1.stefanb341.de auch auf die IP des Servers zeigen (normaler A Record bei Deinem Domain / DNS Anbieter). Das dürfte schon der Fall sein.


    3) für die IP 85.25.93.254 sollte ein PTR (also der rdns) Eintrag auf s1.stefanb341.de existieren. Das ist momentan hier nicht der Fall und wird wohl auch das ausschlaggebende Problem sein. Hier ist der Ansprechpartner der "Besitzer" der IP, also Dein Serverhoster. Wenn Du der Meinung bist, dass Du das in dessen Kundenbereich richtig eingetragen hast, würde ich den Support da mal bemühen.


    Ich persönlich finde es immer am einfachsten die PTR Einträge mit dig zu prüfen sofern Du das installiert hast.


    Code
    dig -x 85.25.93.254

    Oder eben mit Webtools wie mxtoolbox etc.

    Schau in den "Überblick" Startscreen vom /administrator. Dort steht dann zb. bei "Installierte Version d. Serverumgebung:" ein "4-0.348". Die Reihe ist dann die erste Ziffer.

    Die pd-admin Umgebung wird ohne Mail-Limit ausgeliefert. Wenn Du keins gesetzt hast, ist es daher am wahrscheinlichsten dass das Problem beim Empfänger Deines Kunden liegt oder der Mailversand aus einem anderen Grund abbricht (was bei 30MB zzgl 30% base64 Overhead schonmal vorkommen kann).


    Wenn Du ein Limit setzen möchtest, geht das über die Datei /var/qmail/control/databytes in Bytes.


    Code
    echo "10485760" > /var/qmail/control/databytes

    Würde somit das Limit auf 10MB setzen.

    Ich verwende eine eigene letsencrypt Implementierung mithilfe von dehydrated https://dehydrated.io/ (kann ich sehr empfehlen, ein acme client in purem bash). Der Grund dafür ist dass ich diese bereits gebaut habe bevor pd-admin letsencrypt an Board hatte und ich meinen eigene Lösung hier einfach liebgewonnen habe.


    Ich übermittle hier mit dehydrated beim generieren von Zertifikaten meine eigene E-Mail Adresse und habe für keine einzige Domain eine Warnung bekommen (andere Warnungen bekam ich in der Vergangenheit aber durchaus mal, zb. als mein cronjob mal länger nicht lief wegen eines Fehlers von mir).


    Daher (und aufgrund von dem was ich so gelesen habe) gehe ich derzeit auch davon aus dass nur Domains mit einem CAA Record betroffen sind. Meine heikelsten Kunden habe ich mit dem Testtool https://checkhost.unboundtest.com/ getestet, endgültig wissen werden wir es dann wohl erst morgen.

    Um welche Lizenz geht es? Wenn es jetzt nicht unbedingt die ganz große Lizenz ist, würde ich die Zeit und den Aufwand sparen und das Geld für eine neue Lizenz einwerfen. Hab ich auch schonmal gemacht in einem ähnlich gelagerten Fall. Die Preisgestaltung von pd-admin ist meiner Meinung nach so fair (nicht zu sprechen von den jahrelangen kostenlosen Updates), dass so etwas schon mal drin ist.

    Vielleicht könnte man diese Änderung in den Standard übernehmen? Ich hatte auch grad ziemliche Probleme eine sehr umfangreiche Website aus dem backup zu restoren, wegen einem Verzeichnis das leider "logs" hieß (aber nicht nur logs enthält, sondern halt auch diverse logging klassen etc.)

    qmail verwendet jedoch nur die beiden Dateien. Eine Datei mit dh2048.pem würde nicht beachtet. Als workaround kann man jedoch in der dh1204.pem einfach ein Schlüssel mit 2048 Bit hinterlegen. Dazu muss in der Datei /var/qmail/bin/update_tmprsadh der Schlüssel statt mit 1024 mit 2048 erzeugt werden. Der Dateiname bleibt gleich.

    Hab da grad aus Neugier in das update_tmprsadh auf einem Server geschaut. Ich glaub dass hier eigentlich genau das bereits gemacht wird (letzten paar Zeilen), oder? Haben jene die von dem Problem betroffen sind vielleicht eine veraltete Version des Scripts?


    Code
    openssl dhparam -2 -out /var/qmail/control/dh1024.new 4096 &&
    chmod 600 /var/qmail/control/dh1024.new &&
    chown qmaild:qmail /var/qmail/control/dh1024.new &&
    mv -f /var/qmail/control/dh1024.new /var/qmail/control/dh1024.pem

    Ich denk jetzt nur laut, aber ich könnte schwören dass es mal die Möglichkeit eines quasi "Hook Scripts" für die httpd_vhosts.pl gab, das beim Erzeugen der vhost Schnippsel herangezogen wird. So konnte man eigene Zeilen für die vhosts Definitionen heranziehen. Kann das sein dass ich mich da richtig erinnere?

    Mir stellt sich auch die Frage warum an dieser Stelle vom Update Skript überhaupt in /etc/my.cnf nachgeschaut wird wenn das eigentliche Skript ja in /usr/local/pd-admin2/etc/my.cnf liegt?

    Das hat durchaus seinen Grund. Das Problem ist, dass der mysqld einer cnf Datei in /etc stets den Vorrang gibt wenn eine existiert und dann diese einliest. Früher, als es diesen Check noch nicht gab, ist der mysqld der Standardumgebung dann auf einmal mit den Settings aus der Distri-my.cnf gestartet und daher kam natürlich Quatsch raus. Aufgefallen ist das dann meist nach einem Update oder Neustart und dann wurde es schnell mal hektisch.

    Daher wurde AFAIR dann mal dieser Check eingebaut. Wenn auf dem Server keine andere mysql Instanz läuft (was im Normalfall mehr als unwahrscheinlich ist) kann die Datei bzw. der Symlink unter /etc problemlos gelöscht werden meiner Erfahrung nach.

    Ich weiß nicht, wann dieses letzte Mal war. Aber ich würde behaupten, dass seit einiger Zeit reine Blacklist Lösungen nicht mehr viel bringen. Irgendwann hatte ich genug von dem ganzen ständigen Blacklisten und Spamassassin Feintuning das nie ein Ende nimmt. Da war mir dann klar dass ich das jetzt an Profis outsourcen möchte. Hab mir dann einige solcher Lösungen, die man via MX Record einbindet, angesehen und Spamexperts fand ich am besten und von Preis/Leistung am fairsten.

    Das ist in der Tat oft ein Problem bei Weiterleitungen an einen der großen Mailanbieter. Dadurch dass der ganze Spam ebenfalls weitergeleitet wird, beginnt hotmail,apple,etc. dann irgendwann damit den eigenen Server als Spamquelle zu identifizieren (vereinfacht gesagt) glaube ich.


    Wenn Du hier was machen willst und mehrere Domains hast die Du schützen möchtest, kann ich Dir spamexperts.com empfehlen. Macht aber erst ab zumindest 10 Domains Sinn von den Kosten her.

    Wenns nur eine oder weniger Domains sind, findest Du sicher jemand der Dir einen Domainslot günstig re-sellt. Wir machen das auch, aber ich will hier nicht einen auf Verkäufer machen.

    Ich würd jetzt nicht mehr rumspielen wenns schon funktioniert hat ;-)


    Ich glaube MAD M!NDWORX natürlich wenn er sagt dass es bei ihm so läuft. Fakt ist aber dass bei all meinen Installationen (also auch bei jenen wo es immer funktioniert hat) die Dateien popuser:popuser gehören, ohne mein Zutun. Ob das Berechtigen auf den popuser damals bei meinem Problem ein entscheidender Schritt war oder nicht, trau ich mir heute nicht mehr sagen. Aber ich würds auf jeden Fall auf popuser lassen, insbesondere weil mir das der Default zu sein scheint (und nochmal insbesondere wenn es damit funktioniert hat ;-) )

    Wunderbar. Interessant ist übrigens, dass diese falschen Berechtigungen, bei Servern die ich später aufgesetzt hab, nicht mehr aufgetreten sind bei mir. Ich ging daher davon aus dass es ursprünglich ein Fehler im tar Paket bzw. in der Installationsroutine war, der mittlerweile behoben ist. Möglicherweise entsteht dieser Fehler eher diffus.

    Sehr fein, vielleicht haben wir es damit ja bald vom Tisch. So sieht das Ganze btw bei mir aus:


    Code
    # ls -l /opt/pdadmin/bin/forward*
    -rwsr-xr-x. 1 popuser popuser 9547 Jun 29 2016 /opt/pdadmin/bin/forward_filter
    -rwxr-x---. 1 popuser popuser 212 Jul 1 2016 /opt/pdadmin/bin/forward_filter.pl

    Es ist zwar ein Strohhalm und eine blöde Frage, aber vielleicht kannst Du trotzdem mal zur Sicherheit die Ausgabe von


    Code
    ls -l /opt/pdadmin/bin/forward*


    posten? Ich, der ja diesen Thread damals ins Leben gerufen hat, hab mir das eben nochmal alles angesehen und es bleibt trotzdem als Ursache fast nur eine Berechtigungsgeschichte. Ich würde Mindworx auch tendentiell eher widersprechen dass der Besitzer root:root bleiben darf, wenn ich mich richtig entsinne hat es erst funktioniert als popuser:popuser Besitzer der beiden Dateien war.

    Sowas ist echt Mist...

    Ich hab hier ein paar Jungs (Thread ist zwar alt aber das ist der qmail Kern letztendlich ja auch) gefunden, die ein sehr ähnliches Problem hatten. Der Thread führt zwar nicht zu einer Lösung, aber hier wird das Tool "recordio" erwähnt, das zumindest mir bisher nicht bekannt war und mit dem man anscheinend in den smtp Dialog rein schauen kann:

    https://groups.google.com/foru…mp.mail.qmail/TaEDf-voEgc


    Du müsstest dieses recordio in das qmail-smtp run script inkludieren. https://qmailrocks.thibs.com/maybe-recordio.php

    Sehr allgemein formuliert kümmert sich pd-admin recht wenig um Software die ansonsten am Server installiert ist. Ausnahme natürlich Dienste, die zum Beispiel bezüglich benututzter Ports oder so mit dem pd-admin Diensten konkurrieren.


    Habe mal kurz quergelesen worum es bei tesseract geht, das sieht mir nicht danach aus dass es Probleme geben sollte.