Hi,

Sorry if this goes a bit outside pure email topics, but the logic feels close to how identities are handled here.

I recently looked into how animal RFID microchips work. The chip itself only stores a unique ID and all real information lives in an external database that gets queried when the chip is scanned. It reminded me of how Roundcube acts more like an interface while IMAP remains the actual data source.

I'm wondering if anyone ever used Roundcube as a lightweight interface to consult external identifiers stored somewhere else, not emails but things like inventory IDs or badge references tied to another system.

I'm not sure if this would make sense from a security or performance perspective, so I'm curious if any admins experimented with something similar or maybe rejected the idea for good reasons.

Thanks.

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?

Hey everyone,

I'm trying to send an eSIM promo code to a colleague using Roundcube, but the link always ends up unreadable or the formatting gets messed up. I've tried plain text and HTML, but it still fails.
Has anyone managed to handle external links in emails without Roundcube altering them? I really need the code to stay clickable and clear.

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.

Hello. My Roundcube instance is struggling to interpret media-rich emails correctly, particularly those from casino platforms such as RodeoSlot.
The problem is that the promotional blocks and slot machine visuals are completely unstructured. Despite allowing remote content in the preferences, the display remains fragmented, making the payout tables and bonuses unreadable. Could this be due to a limitation of the internal rendering engine or specific filtering at the IMAP server level? If you have a configuration change to suggest to force a clean display of these complex templates, I'm interested.

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