Hello - how are you? I don't know if anyone can help, and please forgive me - I'm not particularly savvy when it comes to these things!

I am able to access my webmail via roundcube on my main PC via a browser, and also via Outlook on the same PC. However, using the same credentials I am unable to access my mail from any other device, phone - tablet - other PC, the login always fails. It fails when logging in via the roundcube login page OR trying to login via outlook or any other email client.

Is this a 'roundcube' issue or an I barking up the wrong tree?

Any advice appreciated.

Thanks in advance!

I've got an answer.. So please close this topic.
Thanks, Rob

We want to forward messages depending on the cc-address or the bcc-address instead of 'only'the to-address...

I still don't have an answer, but it must be some odd caching issue as you suggested @JohnDoe. When I revert back to version 1.7-beta2 and even version 1.6.10 I now get the same behavior. I'll keep investigating and report back here if I find a solution. If anyone has ideas to try, I'm all ears. fwiw, I'm running a fedora 43 server with caddy v. 2.10.2.

Thanks for the reply.

No error messages in the roundcube errors.log file, and I am not using any imap or message caching:

// config/default.inc.php
$config['imap_cache'] = null;
$config['messages_cache'] = false;

Just in case, I rebooted the entire server and the issue persists.

The issue is with LemonLDAP-NG, not with roundcube.

There is an issue with the nginx-lua-headers.conf, it messes with the cookie.

is there anything in the roundcube error log? also do you have any of the imap or message caching options enabled? if so does resetting the cache make any difference?

I cannot find that skin. In the template files if you can find the reference to the "listmenulink" object. Something like:
<roundcube:object name="listmenulink"...
and it should have an attribute called either `optionsmenuicon` or `icon`. If you remove that attribute then the problem should go away.

I recently updated from version 1.7-beta2 to 1.7-rc4. The problem below has now appeared:

When I first load ANY new unread message, all images in the message are blocked, as expected. However all email headers (From, To, ReplyTo, Date) are also missing (see screenshot). If I click off of the message then return to the new message, now all headers are correctly displayed. If I have previoulsy "allowed all from <email address>" then I see all message images (as expected) or I have the additional button of "Always allow from <email address>" (also as expected).

So, it's just the initial load of any new unread message. I'm not sure which version this problem appeared between beta2 and rc4.

Dear community,

I'm trying to set up roundcube with LemonLDAP-NG as SSO.

I use LemonLDAP HTTP Header for authentication: https://lemonldap-ng.org/documentation/latest/applications/roundcube.html
So my roundcube application is a reverse proxy protected application (https://lemonldap-ng.org/documentation/latest/configvhost.html)

My roundcube is served by a nginx virtualhost :

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name default_server;
    root /var/www/roundcube/public_html;
    index index.php index.html;

    ssl_certificate "/etc/letsencrypt/live/webmail5.mydomain.com/fullchain.pem";
    ssl_certificate_key "/etc/letsencrypt/live/webmail5.mydomain.com/privkey.pem";
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout  10m;
    ssl_ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305";
    ssl_prefer_server_ciphers on;

    access_log /var/log/nginx/roundcube.access.log debug_host;
    error_log /var/log/nginx/roundcube.error.log;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        proxy_set_header X-Forwarded-Proto https;
        fastcgi_pass unix:/var/run/php/php-fpm.sock;  # Path to PHP-FPM socket
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param  HTTP_AUTH_USER $http_auth_user;

        include fastcgi_params;
    }

    # Deny access to sensitive files
    location ~* ^/(config|temp|logs)/ {
        deny all;
    }
}

My LemonLDAP-NG virtual is configured this way:

map $lmlocation $lmerror_location {
    ~^      $lmlocation;
    default @lmAuth401;
}

server {
  listen 443 ssl;
  listen [::]:443 ssl;
  server_name webmail-2fa.mydomain.com;
  root /var/www/html;

  ssl_certificate "/etc/letsencrypt/live/webmail-2fa.mydomain.com/fullchain.pem";
  ssl_certificate_key "/etc/letsencrypt/live/webmail-2fa.mydomain.com/privkey.pem";
  ssl_session_cache shared:SSL:1m;
  ssl_session_timeout  10m;
  ssl_ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305";
  ssl_prefer_server_ciphers on;

  set_real_ip_from  127.0.0.1;
  real_ip_header    X-Forwarded-For;

  # Internal authentication request
  location = /lmauth {
    internal;

    # FastCGI configuration
    include /etc/nginx/fastcgi_params;
    fastcgi_pass unix:/var/run/llng-fastcgi-server/llng-fastcgi.sock;
    # Drop post datas
    fastcgi_pass_request_body  off;
    fastcgi_param CONTENT_LENGTH "";
    # Keep original hostname
    fastcgi_param HOST $http_host;
    # Keep original request (LLNG server will receive /lmauth)
    fastcgi_param X_ORIGINAL_URI $original_uri;
    fastcgi_param UNIQUE_ID $request_id;

    # Improve performances
    #fastcgi_buffer_size 32k;
    #fastcgi_buffers 32 32k;
  }

  location @lmAuth401 {
      return 401;
  }


  # Client requests
  location / {
    auth_request /lmauth;
    set $original_uri $uri$is_args$args;
    auth_request_set $lmremote_user $upstream_http_lm_remote_user;
    auth_request_set $lmremote_custom $upstream_http_lm_remote_custom;
    auth_request_set $lmlocation $upstream_http_location;
    error_page 401 $lmerror_location;

    # Reverse proxy
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_pass https://webmail5.mydomain.com/;

    include /etc/lemonldap-ng/nginx-lua-headers.conf;
  }
}


If I connect directly by https://webmail5.mydomain.com, it works I'm authenticated. Cookies `roundcube_sessauth` and `roundcube_sessid` are set.

If I connect through LemonLDAP, i.e https://webmail-2fa.mydomain.com, it doesn't work. Cookie `roundcube_sessid` is set but not cookie `roundcube_sessauth`.
And I can see those errors in the session.log :

[03-Mar-2026 14:10:24 +0000]: <7rt2lack> Session regenerate: phetvsg27b4ur63601brjetmg8 -> 7rt2lack21ognfg1aj6j2ta2p6
[03-Mar-2026 14:10:24 +0000]: <7rt2lack> Session auth check failed for 7rt2lack21ognfg1aj6j2ta2p6; timeslot = 2026-03-03 14:10:00
[03-Mar-2026 14:10:24 +0000]: <7rt2lack> Session authentication failed for 7rt2lack21ognfg1aj6j2ta2p6; invalid auth cookie sent; timeslot = 2026-03-03 14:00:00
[03-Mar-2026 14:10:24 +0000]: <7rt2lack> Session destroy: 7rt2lack21ognfg1aj6j2ta2p6
[03-Mar-2026 14:10:46 +0000]: <6h9rhlds> Session auth check failed for 6h9rhlds6onf5qf36v3ql8jquq; timeslot = 2026-03-03 14:10:00
[03-Mar-2026 14:10:46 +0000]: <6h9rhlds> Send new auth cookie for 6h9rhlds6onf5qf36v3ql8jquq: 8s3bQpSdhBnZXqVABCKw2nRWn7-1772546700

The logs on my IMAP server confirm there is a successful IMAP authentication.

Do you have any idea about what's going on?