Webmail button redirects to Mailcow UI

keggy82

After major update to 2025-05, the webmail button redirects to the Mailcow UI. I can no longer open Sogo since then.

I have understood and read that https://yourdomain.com/SOGo/ no longer works. But the automatic redirection at user login and the webmail button won’t work either.

esackbauer

keggy82 But the automatic redirection at user login and the webmail button won’t work either.

Now thats what I call a detailed error description…

DocFraggle

You have to login through the mailcow UI to Sogo

keggy82

I’m already logged in as the user. But it does not work.

DocFraggle

keggy82 I’m already logged in as the user. But it does not work.

@ETNyx I asked that already.

@keggy82 do you use a special setup like reverse proxy or something like that?

ETNyx

@keggy82 Try it via new private window in your browser, i would guess your browser have cached the old way and do not want to let go,…

keggy82

I already tried it in private Window. It shortly load https://mymaildomain.de/SOGo/so and then redirect to https:/mymaildomain.de/user. You can shortly see the Sogo-Logo

My mailcow.conf

Skip SOGo: Will disable SOGo integration and therefore webmail, DAV protocols and ActiveSync support (experimental, unsupported, not fully implemented) - y/n

SKIP_SOGO=n

SOGo session timeout in minutes

SOGO_EXPIRE_SESSION=1200

the docker-container is running
ghcr.io/mailcow/sogo:1.133 “/docker-entrypoint.…” 2 days ago Up 2 days

ETNyx

Ok, while you are not logged in this is expected behavior, next when you log in you are able to use SoGo right?

keggy82

@DocFraggle I use the NGINX that comes with the mailcow-dockerized installation.

That ist the redirect.conf for nginx

server {
root /web;
listen 80 default_server;
listen [::]:80 default_server;
include /etc/nginx/conf.d/server_name.active;
if ( $request_uri ~* “%0A|%0D” ) { return 403; }
location ^~ /.well-known/acme-challenge/ {
allow all;
default_type “text/plain”;
}
location / {
return 301 https://$host$uri$is_args$args;
}
}

and the parts out of the nginx.conf.j2
location ^~ /SOGo {
location ~* ^/SOGo/so/.*.(xml|js|html|xhtml)$ {
auth_request /sogo-auth-verify;
auth_request_set $user $upstream_http_x_user;
auth_request_set $auth $upstream_http_x_auth;
auth_request_set $auth_type $upstream_http_x_auth_type;
proxy_set_header x-webobjects-remote-user “$user”;
proxy_set_header Authorization “$auth”;
proxy_set_header x-webobjects-auth-type “$auth_type”;

    proxy_pass http://{{ SOGOHOST }}:20000;

    proxy_set_header X-Forwarded-For {% if not NGINX_USE_PROXY_PROTOCOL %}$proxy_add_x_forwarded_for{% else %}$proxy_protocol_addr{%endif%};
    proxy_set_header X-Real-IP {% if not NGINX_USE_PROXY_PROTOCOL %}$remote_addr{% else %}$proxy_protocol_addr{%endif%};
    proxy_set_header Host $http_host;
    proxy_set_header x-webobjects-server-protocol HTTP/1.0;
    proxy_set_header x-webobjects-remote-host $remote_addr;
    proxy_set_header x-webobjects-server-name $server_name;
    proxy_set_header x-webobjects-server-url $client_req_scheme://$http_host;
    proxy_set_header x-webobjects-server-port $server_port;
    proxy_hide_header Content-Type;
    add_header Content-Type text/plain;
    break;
}
auth_request /sogo-auth-verify;
auth_request_set $user $upstream_http_x_user;
auth_request_set $auth $upstream_http_x_auth;
auth_request_set $auth_type $upstream_http_x_auth_type;
proxy_set_header x-webobjects-remote-user "$user";
proxy_set_header Authorization "$auth";
proxy_set_header x-webobjects-auth-type "$auth_type";

proxy_pass http://{{ SOGOHOST }}:20000;

proxy_set_header X-Forwarded-For {% if not NGINX_USE_PROXY_PROTOCOL %}$proxy_add_x_forwarded_for{% else %}$proxy_protocol_addr{%endif%};
proxy_set_header X-Real-IP {% if not NGINX_USE_PROXY_PROTOCOL %}$remote_addr{% else %}$proxy_protocol_addr{%endif%};
proxy_set_header Host $http_host;
proxy_set_header x-webobjects-server-protocol HTTP/1.0;
proxy_set_header x-webobjects-remote-host $remote_addr;
proxy_set_header x-webobjects-server-name $server_name;
proxy_set_header x-webobjects-server-url $client_req_scheme://$http_host;
proxy_set_header x-webobjects-server-port $server_port;
proxy_buffer_size 128k;
proxy_buffers 64 512k;
proxy_busy_buffers_size 512k;
proxy_send_timeout 3600;
proxy_read_timeout 3600;
client_body_buffer_size 128k;
client_max_body_size 0;
break;

}

location ~* /sogo$ {
return 301 $client_req_scheme://$http_host/SOGo;
}

location /SOGo.woa/WebServerResources/ {
alias /usr/lib/GNUstep/SOGo/WebServerResources/;
}

location /.woa/WebServerResources/ {
alias /usr/lib/GNUstep/SOGo/WebServerResources/;
}

location /SOGo/WebServerResources/ {
alias /usr/lib/GNUstep/SOGo/WebServerResources/;
}

location (^/SOGo/so/ControlPanel/Products/[^/]UI/Resources/..(jpg|png|gif|css|js)$) {
alias /usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2;
}
{% endif %}

this is from the sogo log

mailcowdockerized-sogo-mailcow-1 | Jul 14 10:30:23 2f1ca1a65093 sogod [54]: 95.223.78.86 “GET /SOGo/so HTTP/1.0” 302 0/0 0.001 - - 0 - 12
mailcowdockerized-sogo-mailcow-1 | Jul 14 10:30:23 2f1ca1a65093 sogod [54]: 95.223.78.86 “GET /SOGo/so/ HTTP/1.0” 200 11943/0 0.020 43453 72% 0 - 12

this is from the sogo log

form the logfile

DocFraggle

Do you remember if you changed/modified anything in the past regarding your mailcow config?

You can check this by running

git diff refs/tags/2025-05 data/

in your mailcow-dockerized dir. There will be legit diffs there, but you can check if there’s something else which you may have done in the past

keggy82

I checked the configuration diff but found nothing that gives advice for Sogo Redirect.

MikeDawson1945

I have the same problem. Neither my normal link nor the button in the user UI works. I haven’t made any changes to the configurations or anything else. I do the monthly updates promptly.