I spent significant time before giving up trying to follow this red herring of CKEDITOR is not defined, and had given up because nothing made sense and the mailcow setup mostly worked. I could send and receive mail, mostly. SOGo -> SOGone. I could live with that.
Now after a week or two I’ve finally randomly stumbled across more clues and more breakage. SMTP wasn’t working partially. It turned out that either the update from mailcow from a version of one or two years ago to latest, or some other tinkering I had done, had caused breakage. Or both combined.
Importantly:
- mailcow switched to Dovecot
- dovecot auth goes to
https://nginx:port
- my nginx container had only the alias nginx-mailcow
- fixed by adding
nginx to nginx-mailcow’s mailcow-network aliases
- hard to spot because most of the stack seems unaffected, possibly only dovecot broke, and not everything depends on dovecot
Relevant issues that can indicate this is the issue:
- every SMTP/IMAP login (every mailbox) gets rejected as “password mismatch.” Webmail keeps working because SOGo uses a different auth path. Certain local tests that aren’t subject to the docker network alias config error are false passes
- navigating between SOGo and the admin pages or within them leads to random inexplicable redirects (network responses contain no clear indication why the redirects happen, http responses all are non-error and pretend there is not any issue)
- you can log in to SOGo but the web interface isn’t loading fully, making you wonder what you did wrong. But providing no clues other than the single error of ‘CKEDITOR is not defined’
STRONG INDICATOR: you observe that your password hash and the one in the database match but the SMTP access still rejects;
My agent had trouble debugging because there is some auth script file that either is dead code or fulfills similar tasks;
∴ I've been analyzing the wrong file this whole time—the actual Dovecot auth script in use is /etc/dovecot/auth/passwd-verify.lua at 1790 bytes, not the one I examined at /etc/dovecot/lua/passwd-verify.lua which is 3809 bytes. Flushing the cache didn't resolve the issue either, so I need to read the correct file that's actually being executed.
The file actually in use is /etc/dovecot/auth/passwd-verify.lua (1790 bytes) — a different, smaller file than the one I analyzed before. That's the real bug source. Let me read it.
[...]
● Now I see the real architecture. mailcow moved auth to an HTTP endpoint: this Lua POSTs credentials to https://nginx:9082 and trusts its JSON success. The MySQL query file I analyzed before is dead legacy. The
"HTTP request failed" warnings I'd dismissed as a red herring may be the actual failure. Let me run a fresh auth test while tailing the dovecot log, and find what serves nginx:9082.
∴ I'm seeing two distinct issues here. First, the Lua script is hardcoded to connect to https://nginx:9082, but from the dovecot container, only nginx-mailcow resolves—nginx doesn't work at all. This suggests a
missing network alias in the docker-compose configuration, since services should normally be reachable by their service name. Second, there's something about the port configuration that's cut off, but it seems
related to the same connectivity problem.
The resolved nginx-mailcow address is IPv6-only, which could complicate things if the Lua client tries IPv4 first. But the real blocker is that nginx isn't resolving at all. I should test whether
nginx-mailcow:9082 actually works, and then figure out why the nginx alias is missing from the network setup.
● nginx doesn't resolve at all — only nginx-mailcow does (and only on IPv6). The Lua hardcodes https://nginx:9082, so every auth fails. Let me confirm the endpoint works under the right name and check the network
aliases.
[...]
● [...] The update moved Dovecot's auth to an HTTP call to https://nginx:9082, but Coolify's compose had stripped the nginx network alias — so the name didn't resolve and every SMTP/IMAP login (every mailbox) got rejected as "password mismatch." Webmail kept working only because SOGo uses a different auth path.
It was a rather costly and time consuming effort. It was not much of my effort, luckily, it was roughly $8.37 worth of Claude Code usage, had I been on API billing, counting 16 messages from me. This does not include the debugging session from weeks ago. I had spent probably at least the same amount of time back then too, if not more.
I’d say the error reporting could have been a bit clearer, or perhaps some unified warning destination and or UI so that I wouldn’t have had to figure to look in one of the 16 in-memory logs and spot an unknown error type that would not have any messaging that would seem relevant to the custom-sogo.js error I was stuck with for weeks.
@esackbauer I am burnt out and I cannot find out how to tag a dev team group nor can I find a staff members page. You’re a true hero and therefore I request your assistance in tagging the right person that might want to look into this problem I encountered. This post is mainly to ensure this error has any public information on one possible cause. But I think it’s worth triaging if I had significant skill issues, or if there is indeed room for improvement on the error reporting of severe service degradation alerts in general in UI, as well as a quick fix so that a relevant error is presented to the user affected for this specific error. I’ve thoroughly and painstakingly inspected the firefox console, the firefox network tab (unexplained 302’s, mostly, not really any leads) and I even inspected custom-sogo.js, did endless inconclusive ‘CKEDITOR is not defined’ searches. It was frustrating and time consuming.
TL;DR The error message is not relevant to the root cause. There are little indications of what the actual problem is. This very message is the sole documentation on what the cause and solution are.
For @ixnay the cause was cache invalidation, resolved with the same strategy a my initial attempt: “wait and pray it goes away”.
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.
– Leon Bambrick