July 11
We have added the ability to change the color schemes. It is available under Settings-Preferences-User Interface-Color Scheme There are currently 15 different color combinations, please feel free to contact helpdesk if you would like to see any particilar combinations or would like us to duplicate an existing app's colors.
This pairs nicesly with the ability to change your layout to match your favorite mail app's layout. This is under Settings-Preferences-Mailbox View-Layout
This pairs nicesly with the ability to change your layout to match your favorite mail app's layout. This is under Settings-Preferences-Mailbox View-Layout
July 6
Secure private unified WebDAV/CalDAV/CardDAV
tldr; We have released Calendar, Address Book, and Tasklist DAV services, allowing you to sync your phone and other device calendars, contacts, and ToDo lists. See Settings-DAV Server
Setup instructions for IOS/macOS, Android, Thunderbird, and Evolution
In looking to add DAV features to our services we encountered the simple fact that DAV services are just not private by design. There are two main problems, the weaknesses of basic authentication, which is required for client compatibility, and unique identifier in the URL derived from the login, which enables sync correlation and behavioral analysis based on sync times and services. These exist at the core of every WebDAV server. You can add authentication features like OAuth2, which excels in some things, but WebDAV/CalDAV/CardDAV is not one of them.
It didn't exist, so we built it
We introduce a novel unified DAV server that handles full method level scoped WebDAV, CalDAV, and CardDAV, built from the ground up for privacy, security, and scalability. We also turned basic authentication into full cryptographic authentication, removed the unique identifiers from login and URL, and gave users individually selectable full-scoped CRUD and global CDM create/delete/modify(PROPPATCH) abilities per sets with the ability to immediately and dynamically change scopes without authentication set reissue.
We took it even further by allowing multiple authentication sets per user, each with their own unique properties, enabling the user to create compartmentalized unique authentication sets with fine grained permissions cross services, thus appearing to DAV services as different users for each authentication set. All while maintaining 100% RFC compliance and 100% client compatibility with IOS/macOS, DAVx5, Thunderbird with TBsync, Evolution, and all basic authentication clients.
How did we do that?
We had three issues to solve, the basic authentication issue of base64 encoded login and password, which really does not provide enough entropy without increasingly complex passwords. It has also enabled cross service behavioral correlation in DAV because it is the unique identifier in both the login and URLs. Finally, the fact that nothing provided the fine grained method level permission scopes per user that we wanted to achieve.
Basic Authentication Problem
In order to achieve 100% client compatibility you need basic authentication, which consists of a base64 encoded combination of login and password for transport, then split back into separate plain text login/password for authentication. It's the only method most clients speak, and it isn't that cryptographically secure. So we rethought basic authentication and we redesigned it into a more secure cryptographic authentication.
We have two fields to work with, so lets use them differently
What was realized was that for decades the general community has believed that the login must be unique because the authentication flow has always been lookup unique username/login -> find associated password hash -> match hash of provided password to stored password hash -> if match, authenticate.
Yet this flow is inefficient and a waste of cryptograpic potential. Clients just save the login and password anyway, and the login field is providing no cryptographic benefit. Even worse, it is providing a public facing unique identifier that enables the correlation of cross service behavior.
It was then realized that a unique login name is not necessary at all, we only need a unique identifier. With the login field available for additional entropy, we developed Dual Random Component Authentication, or as it's referred to internally, 1+1=2, because of it's simple elegance.
We reversed the flow
By providing two independent randomized hashes for the login and password fields instead of the traditional unique login with the password credential, we were able to create the unique identifier needed by combining the values of the two fields together, password hashing them as one, and storing only that hash.
That hash is our unique identifier. To authenticate we combine both fields again, password hash them, then lookup the hash and match it to the user. By reversing the flow we have not only further secured, but we have also streamlined, basic authentication... and it gave us entirely new abilities:
- It removed the unique identifier from the external side and moved it to the internal side, randomizing both aspects of the login and thereby eliminating cross service correlation by common login, giving the user complete privacy in authentication.
- It increased entropy and future-proofed the authentication because length and uncorrelated randomness of each field allows us to increase entropy as needed, without any changes to user behavior, no changes to client user interface, and no changes to enterprise backend. It's very simple middleware. Every computing language can combine two strings and rapidly generate a unique secure one way password hash of them.
- It secured the backend even in the event of compromise because by storing only the combined hash it is mathematically impossible to derive either principal or credential fields from that hash.
- It allowed for multiple authentication set hashes per user, each with it's own uncorrelated unique cryptographic properties. Thus allowing users to create unique scoped authentication sets for each service.
- Because the method of transfer is the same, it maintained 100% current client compatibility.
What about the URL?
The URL in typical WebDAV/CalDAV/CardDAV services is comprised of the unique identifier, the login. This enables correlation of cross service behavior and behavior analysis via unique username, sync times, and sync sets. While we already altered the unique identifier in our dual random authentication method, we go for overkill and decided not to expose even a small part of the dual random component authentication, so we created a completely uncorrelated fixed length hash that is unique between authentication sets, thus allowing multiple fine grained scoped private permission sets per user... and we did this while maintaining 100% RFC 4918, 4791, and 6352 compliance.
For a complete whitepaper see DAV ReImagined
--
This privacy-preserving WebDAV system and specifically this disclosure is protected by:
1. **U.S. Provisional Patent Application No. 63/838,770** filed July 4, 2025, titled "System and Method for Dual-Random Component Authentication"
- Covers the fundamental dual-random authentication method
- Establishes the cryptographic foundation
2. **U.S. Provisional Patent Application No. 63/838,831** filed July 4, 2025, titled "System and Method for Privacy-Preserving Resource Access Through Dynamic URL Routing"
- Covers the dynamic URL derivation
- Protects the resource addressing privacy layer
tldr; We have released Calendar, Address Book, and Tasklist DAV services, allowing you to sync your phone and other device calendars, contacts, and ToDo lists. See Settings-DAV Server
Setup instructions for IOS/macOS, Android, Thunderbird, and Evolution
In looking to add DAV features to our services we encountered the simple fact that DAV services are just not private by design. There are two main problems, the weaknesses of basic authentication, which is required for client compatibility, and unique identifier in the URL derived from the login, which enables sync correlation and behavioral analysis based on sync times and services. These exist at the core of every WebDAV server. You can add authentication features like OAuth2, which excels in some things, but WebDAV/CalDAV/CardDAV is not one of them.
It didn't exist, so we built it
We introduce a novel unified DAV server that handles full method level scoped WebDAV, CalDAV, and CardDAV, built from the ground up for privacy, security, and scalability. We also turned basic authentication into full cryptographic authentication, removed the unique identifiers from login and URL, and gave users individually selectable full-scoped CRUD and global CDM create/delete/modify(PROPPATCH) abilities per sets with the ability to immediately and dynamically change scopes without authentication set reissue.
We took it even further by allowing multiple authentication sets per user, each with their own unique properties, enabling the user to create compartmentalized unique authentication sets with fine grained permissions cross services, thus appearing to DAV services as different users for each authentication set. All while maintaining 100% RFC compliance and 100% client compatibility with IOS/macOS, DAVx5, Thunderbird with TBsync, Evolution, and all basic authentication clients.
How did we do that?
We had three issues to solve, the basic authentication issue of base64 encoded login and password, which really does not provide enough entropy without increasingly complex passwords. It has also enabled cross service behavioral correlation in DAV because it is the unique identifier in both the login and URLs. Finally, the fact that nothing provided the fine grained method level permission scopes per user that we wanted to achieve.
Basic Authentication Problem
In order to achieve 100% client compatibility you need basic authentication, which consists of a base64 encoded combination of login and password for transport, then split back into separate plain text login/password for authentication. It's the only method most clients speak, and it isn't that cryptographically secure. So we rethought basic authentication and we redesigned it into a more secure cryptographic authentication.
We have two fields to work with, so lets use them differently
What was realized was that for decades the general community has believed that the login must be unique because the authentication flow has always been lookup unique username/login -> find associated password hash -> match hash of provided password to stored password hash -> if match, authenticate.
Yet this flow is inefficient and a waste of cryptograpic potential. Clients just save the login and password anyway, and the login field is providing no cryptographic benefit. Even worse, it is providing a public facing unique identifier that enables the correlation of cross service behavior.
It was then realized that a unique login name is not necessary at all, we only need a unique identifier. With the login field available for additional entropy, we developed Dual Random Component Authentication, or as it's referred to internally, 1+1=2, because of it's simple elegance.
We reversed the flow
By providing two independent randomized hashes for the login and password fields instead of the traditional unique login with the password credential, we were able to create the unique identifier needed by combining the values of the two fields together, password hashing them as one, and storing only that hash.
That hash is our unique identifier. To authenticate we combine both fields again, password hash them, then lookup the hash and match it to the user. By reversing the flow we have not only further secured, but we have also streamlined, basic authentication... and it gave us entirely new abilities:
- It removed the unique identifier from the external side and moved it to the internal side, randomizing both aspects of the login and thereby eliminating cross service correlation by common login, giving the user complete privacy in authentication.
- It increased entropy and future-proofed the authentication because length and uncorrelated randomness of each field allows us to increase entropy as needed, without any changes to user behavior, no changes to client user interface, and no changes to enterprise backend. It's very simple middleware. Every computing language can combine two strings and rapidly generate a unique secure one way password hash of them.
- It secured the backend even in the event of compromise because by storing only the combined hash it is mathematically impossible to derive either principal or credential fields from that hash.
- It allowed for multiple authentication set hashes per user, each with it's own uncorrelated unique cryptographic properties. Thus allowing users to create unique scoped authentication sets for each service.
- Because the method of transfer is the same, it maintained 100% current client compatibility.
What about the URL?
The URL in typical WebDAV/CalDAV/CardDAV services is comprised of the unique identifier, the login. This enables correlation of cross service behavior and behavior analysis via unique username, sync times, and sync sets. While we already altered the unique identifier in our dual random authentication method, we go for overkill and decided not to expose even a small part of the dual random component authentication, so we created a completely uncorrelated fixed length hash that is unique between authentication sets, thus allowing multiple fine grained scoped private permission sets per user... and we did this while maintaining 100% RFC 4918, 4791, and 6352 compliance.
For a complete whitepaper see DAV ReImagined
--
This privacy-preserving WebDAV system and specifically this disclosure is protected by:
1. **U.S. Provisional Patent Application No. 63/838,770** filed July 4, 2025, titled "System and Method for Dual-Random Component Authentication"
- Covers the fundamental dual-random authentication method
- Establishes the cryptographic foundation
2. **U.S. Provisional Patent Application No. 63/838,831** filed July 4, 2025, titled "System and Method for Privacy-Preserving Resource Access Through Dynamic URL Routing"
- Covers the dynamic URL derivation
- Protects the resource addressing privacy layer
July 5
We are experiencing difficulties with the web hosting server host1, this affects all users of that server and is currently being addressed.
The issue with host1 has been resolved.
The issue with host1 has been resolved.
June 27
We are currently experiencing an issue with the express1 ssh proxy, this is being addressed and we hope to have it back online shortly.
Express1 is again functional.
Express1 is again functional.
June 25
In keeping up with being available in 80+ languages, we have released national holidays for 80+ different countries that can easily be imported into your calendars. See Settings->National Holidays. This is a dynamic regularly updated list that will stay current should any countries add, remove, or change any national holidays. Select the counrty or countries you wish to import.
We have also updated our private domains settings to allow those who have already had their domains set up by us to enter them there in case they want to see them and/or dmarc, spf, mx records once verified. Please note that once you add them there, if you delete them, you delete them from our service, too.
CalDAV is currently in testing and coming soon. calDAV will allow you to sync your existing calendars and tasklists: work, phone, etc. with CodaMail calendars. We have created our own fully RFC compliant server (not using any existing calDAV or groupware solutions available) with some completely unique and fully backward compatible features that no proprietary enterprise level or open source software currently provides. They will work with existing calDAV clients like Apple iCal, Android davx5, Thunderbird Lightning, Evolution, and frankly all popular calDAV clients for both calendars and tasklists. We have reimagined calendaring and intend to set a new bar with our solutions.
CalDAV features will be plan dependent and our basic e-mail plan will not get calDAV at all, email only will get some calDAV features, and Internet Shield or SocksPlus will level up even further. Our base tier mail service is just going to be basic email as we move to segment more features by service level. Of course you will be able to easily change plans should you desire more features or don't need them and wish to downgrade.
We have also updated our private domains settings to allow those who have already had their domains set up by us to enter them there in case they want to see them and/or dmarc, spf, mx records once verified. Please note that once you add them there, if you delete them, you delete them from our service, too.
CalDAV is currently in testing and coming soon. calDAV will allow you to sync your existing calendars and tasklists: work, phone, etc. with CodaMail calendars. We have created our own fully RFC compliant server (not using any existing calDAV or groupware solutions available) with some completely unique and fully backward compatible features that no proprietary enterprise level or open source software currently provides. They will work with existing calDAV clients like Apple iCal, Android davx5, Thunderbird Lightning, Evolution, and frankly all popular calDAV clients for both calendars and tasklists. We have reimagined calendaring and intend to set a new bar with our solutions.
CalDAV features will be plan dependent and our basic e-mail plan will not get calDAV at all, email only will get some calDAV features, and Internet Shield or SocksPlus will level up even further. Our base tier mail service is just going to be basic email as we move to segment more features by service level. Of course you will be able to easily change plans should you desire more features or don't need them and wish to downgrade.
June 19
Just another reminder as AI makes phishing look even more real. We never send formatted email and we never include anything you have to click on. Any messages from us are always plain text. If it's pretty, looks official, and tells you to click something, it's a phish, ignore it.
June 19
We have added the ability for you to set up your own private domains under Settings->Private Domains. We have also added imap/pop/smtp settings to Settings->Account Information so you don't have to look through the support page for them. As with everything else, both are fully localized to 80+ languages.
Important: If your domain is already hosted with us DO NOT set it up again, this is only for new domains that have not been set up by us in the past.
Important: If your domain is already hosted with us DO NOT set it up again, this is only for new domains that have not been set up by us in the past.
June 17
We have added a Deadman Switch. This allows you to set a message or a number of messages, including attachments, that will automatically be sent to recipients of your choice if you do not log in for N days.
You set the number of days without login, you set whether or not to automatically lock or delete your account upon trigger after the messages send, and you configure whether or not to send warning messages of trigger N days prior. Regarding warning messages, you also set the number of days in advance and frequency of the warnings (one time or every day from the number of days in advance you set until trigger). Simply logging into the CodaMail webmail resets it.
Subject, body, and attachments are all fully encrypted via AES-256-GCM for storage. For access to the Deadman Switch see Settings -> Deadman Switch. Like everything else, this is fully localized in 80+ languages with separate desktop, tablet, and mobile (phone) interfaces.
You set the number of days without login, you set whether or not to automatically lock or delete your account upon trigger after the messages send, and you configure whether or not to send warning messages of trigger N days prior. Regarding warning messages, you also set the number of days in advance and frequency of the warnings (one time or every day from the number of days in advance you set until trigger). Simply logging into the CodaMail webmail resets it.
Subject, body, and attachments are all fully encrypted via AES-256-GCM for storage. For access to the Deadman Switch see Settings -> Deadman Switch. Like everything else, this is fully localized in 80+ languages with separate desktop, tablet, and mobile (phone) interfaces.
June 14
Added the ability to label messages, customizable under Settings -> Preferences -> Labels Options.
June 12
If you have not been keeping up, here is a one page list of all features and their descriptions.
June 11
Did you know that you can used the scheduled message feature as a reminder service too? Just schedule a message to deliver to yourself on a specific day and time.
We have increased our translations/localization across the webmail (including calendar, tasks, notes, etc) to support 80+ languages.
We have increased our translations/localization across the webmail (including calendar, tasks, notes, etc) to support 80+ languages.
June 7
We have added Scheduled Send: Schedule anything that can be sent in a mail (plain text, pgp, formatted text, attachments, etc) to be sent at a specific date and time in the future. Automatically detects if the identity has a custom SMTP server and will use the proper server and credentials for that identity. You can view, reschedule, and delete scheduled messages under Settings->Scheduled Messages. Scheduled Send has also been localized into 40+ languages.
We have also addressed a bug in our mobile and tablet views that caused light mode to automatically switch to dark in some browsers when reading messages.
We have also addressed a bug in our mobile and tablet views that caused light mode to automatically switch to dark in some browsers when reading messages.
June 5
We have added the ability to change the layout. Go to Settings->Preferences->Mailbox View and you will now see an option for Layout. This allows you to change from Widescreen (3 column view - what it has been), Desktop (similar to Thunderbird and the legacy Cotse layout - wide list with preview below), or List (No mail preview pane - double click to open message in it's own window).
As a nod back to our early Cotse roots, we have changed our background to our original Cotse background, 26 years ago now.
As a nod back to our early Cotse roots, we have changed our background to our original Cotse background, 26 years ago now.
May 28
We fixed an issue where some were not seeing their rejected aliases (Manage Catch-alls) or blocked from addresses rejected at SMTP. This was due to a recent update that changed permissions when entries were added or deleted.
May 26
We added localizations for 40+ languages across all of CodaMail.
May 24
We have added Notes to our offerings. Upload images, pdfs, and more as Notes. Create and edit Notes in plain text, html, or markdown. Easily send notes to email attachments. Search capabilities.
May 22
We have added an attachment option called Secure Link to CodaMail. This will password encrypt an attachment on your machine using the WebCrypto API (available with most modern browsers, your browser must support this for this feature to work. If it is a newer browser, whether computer, tablet, or phone, it should work). The encryption is AES-256-GCM and happens on your device. The encrypted file is then uploaded to our server and a link to it is added to the email.
When the recipient clicks the link they will be brought to the secure download page and prompted for the password that you shared with them, preferably, some other way than in the same email that contains the link. Upon entering the correct password the file will be downloaded and decrypted. You will receive email notification when it is downloaded. Links are active for a max of 24 hrs and can be downloaded a maximum of 5 times during that 24 hr period.
This is to provide a way for secure communication or secure sharing of files with those who are not using PGP or any other form of end-to-end encryption.
When the recipient clicks the link they will be brought to the secure download page and prompted for the password that you shared with them, preferably, some other way than in the same email that contains the link. Upon entering the correct password the file will be downloaded and decrypted. You will receive email notification when it is downloaded. Links are active for a max of 24 hrs and can be downloaded a maximum of 5 times during that 24 hr period.
This is to provide a way for secure communication or secure sharing of files with those who are not using PGP or any other form of end-to-end encryption.
Phishing Alert:
We are a constant target of phishing e-mail. We will never send you formatted e-mail, we only send plain text. We do not send links for you to click. Do not follow links or click things in emails. Manually come to our website and check notices, to make a payment, etc. As always, email helpdesk if you have questions.
Privacy Policy:
Because we are a privacy service, we do not back up your personal e-mail. This means that when you delete it, it is irretrievably gone. It is not floating around in some backup that can be retrieved from us against your will. However, it also means you must download and save your important mail, if you delete it, or we suffer a data failure, we do what we can with recovery tools, but we most likely cannot restore it.
Recommended Best Practices:
For optimum privacy with the service use a pop3s mail app and set it to delete the mail from the server after retrieval. We also recommend that your local mail store be an encrypted volume. Once your mail is removed from the server by your mail app, we no longer have a copy, no mail backups and we are deliberately not with a large cloud service, instead opting to keep everything in-house, for the same reason. This puts you in full control of your mail and its privacy. When you delete it, it can't be retrieved and there is no record of it being there.