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?

it's the "Mobile Device Skin" by Melanie, long time EOL, would love to get rid of it - but not that easy with some customers ... ^^

What is "the mobile device skin" skin?

The call to `asset_url()` has been their since 1.5. May be the skin is just not compatible with 1.7 but I am interested to see the cause of the eror because your fix will cause the skin to not render properly I guess.

Quote from: JohnDoh on February 27, 2026, 09:28:02 AMWhat skin are you using? Elastic does not use the `icon` attribute.

Hi,

thanks for the hint regarding the skin/theme question.

In our setup we currently run the default Elastic skin, but in parallel we still offer Larry + the mobile device skin for a small group of older users who struggle with bigger GUI changes. We're fully aware that Larry/mobile is not supported anymore with the newer Roundcube versions, however we have adjusted the templates so they work again with 1.7.

Most likely this old TPL is also what triggers the issue (`rcmail_output_json::asset_url()` not being available in that context).

That said, I personally prefer to have core code hardened in a way that even if a template/plugin/theme does something unexpected, it doesn't result in a fatal error. The small guard using `method_exists()` seems like a safe improvement and shouldn't have any downsides — so maybe it could be considered for inclusion upstream.

Best regards,
Andy

JohnDoh,
Thanks again. Your comments got things working for me.

JohnDoh,
Thanks! This got my install up and working.

Thanks. I may well take your advice!

Roundcube is just webmail software that your web host is using, its not a service and doesn't control or have access to your email account.

In addition the error about the account being blocked would have come from the mail server run by your host not from Roundcube.

In conclusion, I think its time to find a new hosting provider.

This is very frustrating, ever since my domain moved to a different (Exact) server (from ChillidogHosting) it has been a string of problems, ChillidogHosting was purchased by ExactHosting a week or so ago. First the web site went down for 2.5 days because the nameservers had been changed in the transition. Then MailChimp could not be authorised because of a propogation of DNS settings issue.

The later issue caused my client to try and use Roundcube to send out emails while the MailChimp issue was being sorted out, After 2 batches of 20 the Roundcube web mail will no longer send emails saying 'Account [email protected] has been blocked from sending due to abusive activity'! It now want me to update the password and (re)-enable 2FA to be unblocked.

When I log into my Chillidog cPanel the email address is no longer there so I cannot access the settings, presumably because it has been transferred to Roundcube? However I have no way to access the RoundCube 'Home' (to go to the admin settings) in order to make these changes. I have not been supplied with appropriate instuctions on where and how to do this? Even if given these instructions with what login details should I use?

I have spent hours on these problems, my client is really fed up because I recommended moving to Chillidog in the first place and I am looking incompetant!