--- title: "Secure Messages" --- # Secure Messages ## Installation ## Requirements - Joomla 5.1.3 or later - PHP as required by your Joomla version - MySQL or MariaDB - A working mail setup (**System > Global Configuration > Server > Mail Settings**) - Secure Messages delivers its links by e-mail ## Installing the package Secure Messages is delivered as a single package: `pkg_securemessages_vX.X.X.zip`. Install it via **System > Install > Extensions > Upload Package File**. The package installs four extensions in one go: - **Joomill Secure Messages** - the component (backend management and the public pages) - **Secure Messages - Send Form** - a site module that shows the public send form in any module position - **Secure Messages - Cleanup** - a Scheduled Tasks plugin that removes expired messages (installed *disabled*; see the Scheduled cleanup article) - **Secure Messages - Action Log** - records message activity in the Joomla User Actions Log (enabled automatically) After a successful installation you see a quickstart screen with direct links to the component options and the create form. The installer also registers the `com_securemessages.link` mail template (editable under **System > Templates > Mail Templates**) and creates the database table. ## Updates Updates arrive through the Joomla updater (**System > Update > Extensions**). Enter your Download Key under **System > Update > Update Sites > Joomill Secure Messages** to receive them. Installing a newer package over an existing installation is always safe: the installer runs any pending database changes and never overwrites a mail template you edited. ## Uninstalling Uninstall the package under **System > Manage > Extensions** (select the *Joomill Secure Messages* package). This removes all four extensions, the mail template and the database table - including every stored message, so export anything you still need first. [Lees meer...](https://www.joomill-extensions.com/secure-messages/installation.md) ## Configuration All settings live in one place: open **Components > Secure Messages** and click the **Options** button in the toolbar. The options screen has five tabs. ## Secure Messages Settings - **Default expiry** - the lifetime applied when the sender cannot choose one (see Field modes below). 1, 3, 7 or 30 days, or Never. - **Burn after reading by default** - whether messages self-destruct on first opening when the sender cannot choose. - **Require a password by default** / **Default password** - applied together when a field mode uses the admin default with password protection enabled. Note that the recipient must receive this password through another channel. ## Recipients The recipient list powers the public send form. One recipient per line, in either of two formats: ``` info@example.com Support|support@example.com``` A bare e-mail address, or `Name|email` to show a friendly name. With one recipient the form shows a fixed "This message will be sent to ..." line; with more than one, visitors get a dropdown. Lines without a valid e-mail address are silently skipped, and duplicate addresses are merged (the first name wins). **The public form only works when at least one valid recipient is configured** - without it, visitors see a notice that sending is unavailable. ## Field modes For each of **Expiry**, **Burn after reading** and **Password protection** you decide what the public form offers: - **Sender chooses** - the visitor sees the control and decides. - **Use default (shown)** - the admin default applies; the form shows a short fixed notice instead of a control. - **Use default (hidden)** - the admin default applies silently; the form shows nothing. These modes are enforced on the server: a manipulated form submission cannot override an admin-enforced default. ## Anti-spam **Require a captcha on the public form** uses whichever captcha plugin is selected under **System > Global Configuration > Site > Default Captcha**. If no captcha plugin is configured there, this setting has no effect and the form simply works without one. ## Advanced **Custom CSS** - stylesheet rules injected on the public pages (both the send form and the message page). Useful to align the form with your template without an override. ## The notification e-mail The e-mail that delivers the secure link is a regular Joomla mail template. Edit its subject and body under **System > Templates > Mail Templates > com_securemessages.link**. Two placeholders are available: `{SENDER_NAME}` (the sender's name, or the site name for guests) and `{SECURE_MESSAGE_LINK}` (the one-time link). Your edits survive updates. [Lees meer...](https://www.joomill-extensions.com/secure-messages/configuration.md) ## Sending and receiving messages ## Creating a message in the backend Open **Components > Secure Messages** and click **New Message**. Type your message, optionally add a reference (only visible in the backend list, never to the recipient), choose the expiry, burn-after-reading and password options, and click **Generate link**. The message is encrypted in your browser before anything is sent to the server, and you get the secure link. **The link is shown only once**: the decryption key is part of the link and is never stored, so it cannot be shown again later. Copy it right away, or use the *"Or e-mail this link to..."* field below the link to send it to any address directly. ## The messages list The Messages overview shows every stored message with its reference, password and burn flags, expiry and creation date - never its content. Select messages and click **Delete** to revoke them: a deleted message's link stops working immediately. Messages opened with burn-after-reading enabled remove themselves and disappear from this list automatically. ## What the recipient sees The recipient receives an e-mail with the secure link. The link opens a page with a **Show message** button (and a password field when the message is password-protected). After clicking, the message is decrypted in the recipient's browser and shown in a highlighted panel, preserving line breaks. - With **burn after reading**, the page warns beforehand that the message will be deleted on opening; once shown, the message is permanently removed and reloading the page says it is no longer available. - With an expiry, the page shows the expiry date; after that date the link reports the message is no longer available. - With a password, the recipient needs the password you agreed on through another channel - a wrong password simply fails to decrypt. ## The public send form Visitors of your site can send secure messages *to you* through the public form (via a menu item or the module - see those articles). They write their message, pick a recipient from your configured list, and submit. The message is encrypted in their browser and the secure link is e-mailed automatically to the chosen recipient. The sender never handles the link themselves. ## Activity logging Message creation and deletion (including guest submissions and automatic burn/expiry deletions) is recorded in **Users > User Actions Log**. The log identifies messages by their reference - never by their secret link and never by their content. [Lees meer...](https://www.joomill-extensions.com/secure-messages/sending-and-receiving-messages.md) ## Menu items Secure Messages ships one menu item type for the frontend. ## Secure Messages - Send a Secure Message Puts the public send form on its own page. Create it via **Menus > [your menu] > Add New Menu Item**, click **Select** next to Menu Item Type, and pick **Secure Messages - Send a Secure Message** under the Joomill Secure Messages heading. The menu item has no options of its own: the form is driven entirely by the component options (recipients, field modes, captcha - see the Configuration article). If no valid recipients are configured, the page shows a notice that sending is currently unavailable instead of the form. ## The message page The page that recipients open through their secure link needs no menu item: the link works on every site. It carries a `noindex, nofollow` robots instruction, so search engines never index or cache secure message URLs. ## Tips - Give the menu item a clear title such as "Send us a secure message" - that is also the page heading visitors see in your template. - Registered visitors who are logged in are recorded as the sender of their messages; anonymous visitors are recorded as guests. Both can use the form - no login is required. - Prefer the form in a sidebar or on an existing page instead of its own page? Use the *Secure Messages - Send Form* module (see the Modules article). [Lees meer...](https://www.joomill-extensions.com/secure-messages/menu-items.md) ## Modules Besides the menu item type, Secure Messages ships one site module. It is installed together with the package but, like every Joomla module, it is not published automatically: go to **Content > Site Modules**, open it, assign a position and the pages you want, and publish it. ## Secure Messages - Send Form Shows the same public send form as the component's page, in any module position: the message field, the recipient choice, the expiry/burn/password controls you allow, and the captcha if configured. - The module has no settings of its own. Everything - recipients, field modes, captcha, custom CSS - follows the component options under **Components > Secure Messages > Options**. - Only one send form can appear per page. Don't assign this module to the page that already shows the send-form menu item (or place two instances on one page); the second form won't work. - If no valid recipients are configured, the module shows the same "sending is unavailable" notice as the component page. This module is useful when the send form should appear somewhere a menu item can't put it: a sidebar, a footer, or embedded on an existing content page such as your contact page. [Lees meer...](https://www.joomill-extensions.com/secure-messages/modules.md) ## Scheduled cleanup Expired messages already stop being readable the moment their expiry date passes - the link then reports the message is no longer available. The cleanup task additionally removes the expired rows from the database, so no expired ciphertext lingers on your server. ## Enabling the task 1. Go to **System > Manage > Plugins**, search for *Secure Messages - Cleanup*, and enable the plugin. It ships disabled so that enabling scheduled cleanup is a conscious decision. 2. Go to **System > Manage > Scheduled Tasks** and click **New**. 3. Choose the task type **Secure Messages - Remove expired messages**. 4. Give the task a schedule. Once a day is usually plenty; hourly if you use short expiry times a lot. Make sure your site actually runs scheduled tasks: either through Joomla's built-in "lazy" scheduler (System - Schedule Tasks plugin) or, more reliably, through a real cron job or webcron. See the Joomla documentation on the Task Scheduler for the options. ## What it does - and what it doesn't - Removes every message whose expiry date has passed, and records each removal as an automatic deletion in the User Actions Log. - Messages with burn-after-reading remove themselves when opened; the cleanup task only catches the ones that were never opened and then expired. - Messages set to *Never* expire are never touched - delete those manually from the backend list when you no longer need them. [Lees meer...](https://www.joomill-extensions.com/secure-messages/scheduled-cleanup.md) ## Use cases Secure Messages replaces the habit of putting passwords and other secrets in plain e-mail. Some scenarios it was built for: ## Sending credentials to a client You finished a website and need to hand over the hosting or CMS login. Create a message in the backend with **burn after reading** enabled and a short expiry, e-mail the link straight from the result screen, and tell the client to store the credentials in their password manager. The message destroys itself after they open it - and if the link ever leaks later, there is nothing left to open. ## Receiving sensitive information from clients Put the public send form on your site (menu item or module) and point clients to it whenever they are about to e-mail you a password, an API key or personal data. Whatever they submit is encrypted in their own browser and reaches you as a one-time link - instead of sitting readable in both mailboxes forever. ## Temporary access for suppliers A photographer, developer or auditor needs access for a week? Send the credentials with a 7-day expiry and no burn flag: they can re-open the link while working, and the message evaporates by itself when the job is done. ## Two-channel secrets For the truly sensitive cases, enable password protection: send the link by e-mail and the password via another channel (phone, chat). Even someone with full access to the recipient's mailbox cannot open the message - the password is part of the decryption key itself, not a gate on the server. ## An internal drop box On an intranet or members-only site, restrict the send-form page through normal Joomla access levels and let staff send secrets to the IT department without using chat or e-mail. Logged-in senders are recorded by name in the User Actions Log. [Lees meer...](https://www.joomill-extensions.com/secure-messages/use-cases.md) ## Frequently asked questions ## Can the site owner (or their host) read my message? No. Messages are encrypted in the sender's browser before they are sent to the server; the server only ever stores the encrypted result. The decryption key travels in the part of the link after the `#`, which browsers never send to the server when the page is requested. Without the full link (and the password, if set), the stored data is unreadable - for the site owner, the host and any database backup alike. The one nuance is automatic e-mail delivery: see the Security & encryption article. ## I lost the link. Can it be recovered? No. The key only exists inside the link, and the link is shown or e-mailed exactly once. Create a new message instead - that is the point of the design. ## I forgot the password of a password-protected message. There is no reset. The password is folded into the encryption key itself; without it, decryption mathematically fails. Send a new message. ## Why does the link say the message is no longer available? Either it was a burn-after-reading message that has already been opened, the expiry date passed, or a backend user deleted it. In all three cases the encrypted data is gone from the server. ## Can I change the e-mail the recipient gets? Yes - it is a normal Joomla mail template: **System > Templates > Mail Templates > com_securemessages.link**. Your changes survive updates. ## Does the public form work without a login? Yes, by design. Guests can send messages to the recipients you configured (and only to those). Enable the captcha option if you are worried about abuse, and remember the recipient list is a strict whitelist - the form can never be used to mail arbitrary addresses. ## Which languages are included? English, Dutch, German, French, Italian and Spanish, for all parts of the package. ## What ends up in the logs? The User Actions Log records who created or deleted which message, identified by its reference (or a shortened, non-usable identifier fragment). Message content, links and passwords are never logged. ## Does it work with my template? The public pages use standard Bootstrap markup, carry UIkit classes for YOOtheme-based templates, and include neutral fallback styling for everything else. The Custom CSS option (Options > Advanced) covers any remaining fine-tuning. [Lees meer...](https://www.joomill-extensions.com/secure-messages/frequently-asked-questions.md) ## Troubleshooting ## The public form says "Sending secure messages is not available right now" No valid recipients are configured. Open **Components > Secure Messages > Options > Recipients** and check the list: one recipient per line, either `email@example.com` or `Name|email@example.com`. Lines whose e-mail address is invalid are silently skipped - a single typo in the only address produces this notice. If the list looks correct but the notice persists, update to the latest package version (older builds had a bug where saved options never reached the frontend; the update repairs this automatically). ## The e-mail never arrives Secure Messages sends through Joomla's own mail system. Test it under **System > Global Configuration > Server > Send Test Mail**; if that fails, fix your site's mail settings (SMTP is far more reliable than PHP mail). Also check the recipient's spam folder - a message consisting mostly of a long link is a typical spam-filter trigger, which you can soften by personalising the mail template. ## The link shows "This message is no longer available" Expected in three cases: the message was burned after its first opening, it expired, or it was deleted from the backend. If the recipient claims they never opened it, note that some corporate mail scanners and link-preview bots follow links; the message page is safe against that (the message is only burned when someone actually clicks *Show message*), but a colleague or shared mailbox may have opened it first. ## "Could not decrypt this message" The decryption key is missing or incomplete. The key is everything after the `#` in the link; some chat apps and mail clients cut links there. Ask the sender to re-send the full link, preferably as-is from the original e-mail. For password-protected messages, "Wrong password" means exactly that - check for keyboard layout and copy-paste whitespace issues. ## The captcha does not appear The component option only activates whichever captcha plugin is selected under **System > Global Configuration > Site > Default Captcha**. Configure and publish a captcha plugin there first. ## The cleanup task fails with "Is it already running?" Misleading Joomla message: it usually means the *Secure Messages - Cleanup* plugin is disabled, so the task type cannot run. Enable the plugin under **System > Manage > Plugins** and run the task again. ## The module shows nothing at all The module renders only when the Secure Messages component is installed and enabled. Also check the module's menu assignment and that no second send form is on the same page. ## Still stuck? Please [contact us](https://www.joomill-extensions.com/contact) with your Joomla and package version and a description of what you tried. [Lees meer...](https://www.joomill-extensions.com/secure-messages/troubleshooting.md) ## Security and encryption This article explains, in technical terms, how Secure Messages protects a message and what the server can and cannot see. It is written for the sceptical reader - the security model only works if you can verify it. ## Zero-knowledge encryption When a message is created, the sender's browser: 1. generates a random 128-bit key using the browser's cryptographically secure random generator (`crypto.getRandomValues`); 2. derives a 256-bit AES key from it with **PBKDF2-SHA256** (100,000 iterations, random 16-byte salt); 3. encrypts the message with **AES-256-GCM** (random 12-byte IV) via the browser's native Web Crypto API - GCM is authenticated encryption, so any tampering with the stored data makes decryption fail outright; 4. sends only the packed result (salt + IV + ciphertext, base64-encoded) to the server. The random key never leaves the browser as part of that request. It becomes the *fragment* of the secure link - the part after the `#`. URL fragments are handled entirely client-side: when the recipient opens the link, the browser requests the page *without* the fragment, receives the ciphertext, and decrypts it locally. The server, its logs and its database never contain the key. ## Password protection is part of the key When a message is password-protected, the password is concatenated into the secret that PBKDF2 derives the AES key from. There is no server-side password check at all - a wrong password simply produces a key that fails GCM authentication. This means the password cannot be brute-forced against the server, and nobody can "reset" it. ## What the server does store - The ciphertext (useless without the link). - Metadata: an unguessable 128-bit message identifier, the optional reference, the expiry date, the burn flag, the chosen recipient address for frontend messages, and who created it (user id, or "guest"). - A bcrypt hash of the password, stored only so the backend can indicate that a message is password-protected. It is never used to verify anything. The stored payload is validated to contain only base64 characters, which structurally rules out stored-XSS through the message body; the decrypted text is additionally rendered as plain text, never as HTML. ## The e-mail delivery trade-off One deliberate, documented weakening: when a link is delivered by e-mail (the public form does this automatically; the backend offers it as an option), the full link - including the key in the fragment - passes through your server's mail system and the e-mail infrastructure between you and the recipient. For that moment, confidentiality rests on your SMTP transport (use TLS) and on the recipient's mailbox security, exactly as with any e-mailed secret. Burn-after-reading and expiry limit how long an intercepted link would remain usable. If you copy the link yourself and share it through another channel, the key never touches the server after creation. ## Burn-after-reading and revocation A burn message is deleted server-side the moment the recipient reveals it; afterwards the ciphertext no longer exists anywhere. Deletion is authorised by possession of the unguessable message identifier (the same value needed to reach the page at all), and the endpoint answers identically whether or not a message existed, so it cannot be used to probe for valid identifiers. Backend users can revoke any message at any time by deleting it from the list. ## Other measures - Message pages send `noindex, nofollow`, so links never end up in search engines or their caches. - The public send endpoints are CSRF-protected and validate the chosen recipient against the configured whitelist server-side; the mail endpoint additionally refuses any link that does not point at this site's own message page, so it cannot be abused to relay foreign URLs. - All activity is auditable in the User Actions Log without ever exposing content or usable links. ## Honest limitations Client-side encryption trusts the client: a compromised browser, a malicious browser extension, or a tampered-with server that ships modified JavaScript could undermine it - this is inherent to every in-browser encryption tool. Keep your site updated, serve it over HTTPS, and treat the e-mail channel as the weakest link. For secrets that must survive a hostile mailbox, use password protection with the password shared out-of-band. [Lees meer...](https://www.joomill-extensions.com/secure-messages/security-and-encryption.md)