d00p

Das sind soweit ich weiss die Parameter die zusätzlich an das Script übergeben werden?!

Naja, das kann das kann dein Script doch dann machen...glaub ich...machen ja andere Filter nicht anders, wenn Spam schmeiss weg....dein Script kann ja auch das mit der Mail machen was es soll und dann sagen: weg mit

Also, vermutlich nicht via Webinterface, eher direkt in der DB ?

In froxlor kannst du als Weiterleitung /dev/null angeben, glaube das müsste gehen.

Take a look at the server logs to check what the problem is

Da ich nur für dich gegoogelt habe, kann ich dir da nicht viel helfen, aber ich würde schätzen das der Syntax der Zeile vllt so ist und der Parameter nach dem Doppelpunkt einfach nicht nötig ist in dem Fall

schau mal hier: https://thecodingmachine.io/triggering-a-php-script-when-your-postfix-server-receives-a-mail

Gibt es da keine Doku von mailcow wie man deren Service einbindet?

achja, falls du entsprechende Einträge in der "panel_tasks" Tabelle geändert hast dann wird das mit dem Löschen schon ma garnix....wie gesagt, manuelles rumspielen in der DB ist halt einfach alles andere als sinnvoll

Na warte doch einfach mal ~5 Min bis der "tasks" cronjob lief und die entsprechenden Aufgaben auf dateisystem-ebene erledigt wurden. Spiel halt nicht manuell in der DB rum, du kannst es damit nur schlimmer machen So schade ist das nicht...und wie gesagt, der Tasks-Cronjob läuft doch (default) alle 5 min...d.h. in der zeit in der du deinen text hier geschrieben hast hat sich dein Problem doch schon erledigt. Die Fehlermeldung dazu ist doch wirklich recht eindeutig...warum so ungeduldig? Willst du es schneller haben, sag froxlor es soll die Dateien NICHT löschen und mach es manuell auf der shell (rm -rf /var/customers/mail/[korrektes maildir aussuchen])

Dear Froxlor-Community, as some of you might have already noticed, there is a lot of changes going on regarding the new API based version of froxlor: 0.10.0. A complete new structure of the classes has already been done - but wait, there's more This was just the first step towards a brand-new composer-based froxlor, which means, all the external requirements are managed by composer now. The next step, that is currently in progress, is a complete refactoring of all the functions (all in namespaced classes) and a Twig-template engine and bootstrap4 based theme. As I first want to set the basis of all this correctly the first look at this (in a separate branch) will have to wait a few weeks. If you are interested in participating in the new layout or help with convert and design templates you are more than welcome. Join us on IRC (irc.freenode.net/#froxlor). I wish you all a great start into the new year Regards d00p

Hab ich gesehen ja, erst böse IP, dann hast du gewechselt und warst ungeduldig: *** Forbidden. You submitted too quickly. You may try again in a few seconds. *** Habs aber schon als false.negative markiert. Bekamst du diese nachricht zu sehen?

Dear community, in the last weeks or even months, the forum gets spammed on a regular basis so I decided to add a new anti-spam mechanism which should reduce the amount of advertisment- and spam/scam posts on this forum. If you have any troubles posting threads/answers or even with the registration, please let us know and write us to team@froxlor.org. Sorry for the inconvenience and let's hope this works as expected Thank you, d00p

that's not the "CREATE USER" part, it's the SET PASSWORD: $stmt = Database::prepare("SET PASSWORD FOR :username@:host = PASSWORD(:password)"); So it seems mysql uses another recommended way for setting passwords since 5.7.6 $stmt = Database::prepare("ALTER USER :username@:host IDENTIFIED BY :password"); Could you try that quickly?

oh stupid me, didnt see the obvious...thanks mate

no, this is the way, see https://dev.mysql.com/doc/refman/8.0/en/create-user.html Can you debug what username the query uses? Any special characters in it?

Is the file 1:1 the same as currently in git?

I've committed the changes and the unit tests run perfectly fine. So, maybe a typo or similar from your side?

The best try to manually enter the changes to the file

Are you on latest git-version?

Can you try this patch in lib/classes/database/manager/class.DbManangerMySQL.php: diff --git a/lib/classes/database/manager/class.DbManagerMySQL.php b/lib/classes/database/manager/class.DbManagerMySQL.php index b9a8d3ec..d4b9fed3 100644 --- a/lib/classes/database/manager/class.DbManagerMySQL.php +++ b/lib/classes/database/manager/class.DbManagerMySQL.php @@ -66,12 +66,25 @@ class DbManagerMySQL { * @param bool $p_encrypted optional, whether the password is encrypted or not, default false */ public function grantPrivilegesTo($username = null, $password = null, $access_host = null, $p_encrypted = false) { - // grant privileges - $stmt = Database::prepare(" + if (Database::getAttribute(PDO::ATTR_SERVER_VERSION) >= '8.0.0') { + // create user + $stmt = Database::prepare(" + CREATE USER `" . $username . "`.`" . $access_host . "` IDENTIFIED BY 'password' + "); + Database::pexecute($stmt); + // grant privileges + $stmt = Database::prepare(" + GRANT ALL ON `" . $username . "`.* TO :username@:host + "); + Database::pexecute($stmt, array("username" => $username, "host" => $access_host)); + } else { + // grant privileges + $stmt = Database::prepare(" GRANT ALL PRIVILEGES ON `" . $username . "`.* TO :username@:host IDENTIFIED BY 'password' - "); - Database::pexecute($stmt, array("username" => $username, "host" => $access_host)); + "); + Database::pexecute($stmt, array("username" => $username, "host" => $access_host)); + } // set passoword if ($p_encrypted) { $stmt = Database::prepare("SET PASSWORD FOR :username@:host = :password");

additional info: NO_AUTO_CREATE_USER is removed in MySQL 8.0.11 https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-11.html#mysqld-8-0-11-deprecation-removal

Hm, okay, patch is on its way...if you do not use latest developer version (git) just remove every occurance of NO_AUTO_CREATE_USER in our code

Output of the errors would be helpful.