Beiträge von tbc233

    Da monderka eine eigene IP erwähnt, sollte es grundsätzlich schon gehen. Man müsste pd-admin fix auf die eine ip binden (sollte via httpd.conf-template möglich sein) und den Webservice von jitsi (das ist ein nginx im docker) auf die andere.


    Machen würde ich es trotzdem nicht.

    Ich hab einen jitsi Container auf dem günstigsten vServer den ich auf die Schnelle gefunden habe (4 EUR im Monat oder so) laufen, das verptutzt der problemlos mit mehreren Teilnehmern (mehr wie fünf konnte ich bisher nicht testen). Angesichts dieser geringen Kosten, würde ich es mir nicht antun das auf einem pd-admin Server zu verheiraten.

    Ich hab das mal genau so umgesetzt, einzig mit der Einschränkung dass ich angenommen habe dass Du Dich hier vertan hast:


    Angelegt wird der Filter unter


    /home/popuser/popboxen/lieferant.com/loginid/sieve/default.sieve


    Weil "lieferant.com" ist ja die Domain des externen Absenders. Hier hab ich jeweils immer die Kundendomain (bzw. Empfängerdomain) im Pfad eingesetzt.


    Leider tut es nicht, weder die Weiterleitung wird ausgeführt, noch erscheint irgendwas im maillog... Das Mail wird so wie vorher einfach nur dem Empfänger zugestellt.

    Es gibt doch im pd-admin eMail-Menü die Möglichkeit eine eMail an eine eMail-Adresse und eine alternative eMail-Adresse senden zu lassen.


    Kundenmenü->E-Mail->Mailboxen->Kopie-An

    Ist mir natürlich klar. Aber wie gesagt, es geht um eine bedingte Weiterleitung. Nur Mails von einem bestimmten Absender sollen zusätzlich weitergeleitet werden.

    Stell mir folgende Frage:

    Angenommen ich hab die Domain example.com und die Mailbox alice@example.com. Ich möchte nun dass wenn ein eingehendes mail von office@lieferant.com an alice daher kommt, dieses auch *zusätzlich* an bob@example.com (ebenfalls Mailbox auf dem selben pd-admin Server) weitergeleitet wird. Da müsste man doch was mit einem .qmail File zaubern können, oder?

    Ich bild mir ein ich hab sowas mal hinbekommen, allerdings schon viele Jahre her.


    Danke für einen Schubs in die richtige Richtung.

    Ich habe jetzt gerade mal pd-admin der Reihe 4 installiert mit SE 0.348 und dann das Update auf die SE 0.351 gemacht

    und PHP 5.2 und 5.3 laufen ohne Probleme weiter. Es muss also irgendwas bei der Umstellung von Reihe 3 auf Reihe 4

    passieren, was zu diesem Problem führt.

    Ich frag mich grad ob es schlicht daran liegt, dass vielleicht bei der Variante wo die PHP Meldungen auftauchen, aus irgendeinem (vielleicht historisch entstandenen) Grund die Warnings/Notices in der relevanten php.ini aufgedreht waren. Und bei einem "frischen" Setup halt nicht.


    Wie gesagt, meine Einschätzung ist hier nach wie vor dass die durchschnittlichen CMS und Website Scripte aus der Zeit (also jene die halt noch so eine alte PHP Version brauchen) äußerst selten openssl relevante PHP Funktionen nutzen.

    Also bei mir waren es hauptsächliche alte Installation von dem Redaxo CMS und auch einige "Legacy Projekte", die mal von Leuten programmiert worden sind, die nicht mehr erreichbar sind oder das nicht mehr fortführen.

    Der Klassiker halt ;-)


    Wie gesagt, wenn es für Dich mal zeitlich leicht geht wäre es für meine Vorbereitung auf dieses Thema sehr freundlich von Dir wenn Du da die Fehlermeldungen aufzeigen könntest.

    Will Dir keine Umstände bereiten, aber es wäre interessant. Insbesondere auch ob es handfeste Errors oder Warnings sind. Wir haben ja alle so unsere Leichen im Keller (man nennt das "Legacy Projekte" hab ich mir sagen lassen), wenn da ein paar der geworfenen Fehler bekannt sind, hilft das vielleicht dem einen oder anderen.

    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.