Proton Mail & Calendar
- or
No existing idea results
- ~ No ideas found ~
2123 results found
-
Privacy-Preserving Notifications/Generic Notification Mode
Recently, reports involving Signal highlighted that operating system notification databases may retain sensitive information from message notifications, even after the original messages are deleted. While this example involved Signal and iOS, the same general risk may apply to other apps and operating systems where notification content is stored or indexed outside the app.
For privacy-focused users, Proton Mail and other Proton products should offer an option to use generic notification text instead of exposing message content in system notifications.
For example, instead of showing sender names, subject lines, or message previews, the notification could simply say:
“New Proton Mail message received”
This would reduce the chance that sensitive email metadata or content could later be recovered from operating system notification logs, backups, search indexes, forensic tools, or other third-party access.
Suggested feature: Generic Notification Mode
Proposed options:
Show full notification preview
Show sender only
Show generic notification only
Disable notifications entirelyThis would be a valuable privacy enhancement for Proton Mail, Proton Calendar, Proton Drive, Proton Pass, and other Proton apps where notifications may reveal sensitive content.
Recently, reports involving Signal highlighted that operating system notification databases may retain sensitive information from message notifications, even after the original messages are deleted. While this example involved Signal and iOS, the same general risk may apply to other apps and operating systems where notification content is stored or indexed outside the app.
For privacy-focused users, Proton Mail and other Proton products should offer an option to use generic notification text instead of exposing message content in system notifications.
For example, instead of showing sender names, subject lines, or message previews, the notification could simply say:
“New Proton Mail message…
3 votes -
Proton Calendar: Set date by day, month and year
When creating an event in Proton Calendar, it would be great to be able to select the day, month and year separately. On the web / desktop app, you can scroll through by month which is somewhat acceptable, but on iOS, you have to scroll day by day. Very cumbersome if you are trying to add an event a year or more into the future.
4 votes -
Mail extension for browser
A mail extension for browsers like the Proton Pass extension.
The extension should show a counter of unread mails and provide a preview when clicking the extension icon.
So that you can see if new mails arrived even without opening the Mail UI in a tab.4 votes -
Make Linux desktop app (Arch/Deb/RHL)
Make Linux desktop app (Arch/Deb/RHL)
748 votes -
(Current) Critical Security Vulnerability: Missing Default-Deny Policy - Why Whitelists Fail Against Zero-Click Exploits (State Trojans)
(Current Text) April 26, 2026
Dear Proton Team,Currently, Proton Mail under (Filters) "Blocked and Allowed Senders Lists" offers only a whitelist as a positive exception in a system that standardly accepts everything ("Default-Allow"). The "Allow" function serves merely to move important emails back from the Spam folder to the Inbox; it does not prevent the receipt of emails from other domains. The "Block" function serves only to block known, malicious senders.
The fundamental security problem is that for users who need to protect themselves against Zero-Click Exploits (e.g., advanced state trojans like Pegasus or similar spyware), this "Default-Allow" model is fundamentally insufficient and dangerous. An attacker can register thousands of domains or use hacked servers to send malicious emails. A "Block" list can never cover all future, unknown attackers; as soon as a new, malicious domain is created, it is not on the list, and the email is accepted. Furthermore, as long as the Proton server accepts every connection from an unknown domain (even if it is later moved to Spam), there is a critical risk that a Zero-Click Exploit could be executed during the processing phase, such as rendering images, parsing metadata, or analyzing attachments. The malicious code does not even need the user to open it; it can compromise the email client or server infrastructure as soon as the data touches the server. Many users mistakenly believe that an "Allow" list automatically blocks everything else. Technically, this is not the case. The current list is merely a filter ensuring that certain emails do not land in Spam, not a firewall that cuts off access for everyone else.
I therefore demand the introduction of a separate, explicit setting "Allow Only Permitted Senders" that fulfills the following technical requirements. First, the whitelist must offer flexible granularity by supporting both individual email addresses and entire domains. This allows users to define permitted senders with two distinct levels of granularity to balance maximum security with practical usability. Individual email addresses are essential for high-security scenarios where only a specific person is trusted (e.g., john.doe@company.com); this prevents access even if other accounts within the same domain are compromised. Entire domains, on the other hand, serve for the efficient management of trusted organizations or partners (e.g., @trusted-partner.com) and allow all current and future senders from that domain without manual maintenance. The system must evaluate incoming mail against both lists, with a specific address rule taking precedence over a general domain rule if conflicts arise.
Second, server-side rejection at the TCP/SMTP level is required. The server must immediately reject the connection before any data transfer if the sender is not explicitly on the whitelist. This requires validation already during the SMTP handshake, ideally immediately after the EHLO/HELO command or at the latest before the MAIL FROM command. If the sender is not allowed, the server must immediately terminate the TCP connection or return an SMTP error code (e.g., 550 Access Denied or 554 Transaction Failed) before the actual email data transfer (DATA command) begins. No data packets containing potential exploits may be received; the server must not buffer or analyze the email content even temporarily if the sender is not on the list. The connection must be severed at the entrance so that no data packet containing a potential exploit is received by the server infrastructure.
Third, full user control must be guaranteed. Users must be given the opportunity to completely close their digital gate ("Air-Gap" principle for email) without relying on infinite and never-complete blocklists. The responsibility for maintaining the whitelist lies with the user; this is the principle of every high-security system.
Proton advertises worldwide with "maximum protection" and "end-to-end encryption." Yet, without a "Default-Deny" option that supports both address and domain whitelisting, the door remains physically open to unknown attackers. With this function, Proton would be the only commercial email provider enabling users to protect themselves against state surveillance and zero-day attacks through strict perimeter security. For journalists, whistleblowers, and activists, this is not an optional comfort feature, but a matter of survival. The ability to whitelist entire domains simplifies communication with teams, while the option to whitelist single addresses ensures precision against targeted attacks.
Please evaluate this request for technical feasibility and prioritize its integration into the roadmap for security updates. Proton should offer this choice to substantiate its position as the world's safest provider.
Thank you for your work on a safer internet.
(Current Text) April 26, 2026
Dear Proton Team,Currently, Proton Mail under (Filters) "Blocked and Allowed Senders Lists" offers only a whitelist as a positive exception in a system that standardly accepts everything ("Default-Allow"). The "Allow" function serves merely to move important emails back from the Spam folder to the Inbox; it does not prevent the receipt of emails from other domains. The "Block" function serves only to block known, malicious senders.
The fundamental security problem is that for users who need to protect themselves against Zero-Click Exploits (e.g., advanced state trojans like Pegasus or similar spyware), this "Default-Allow" model…
3 votes -
Strike agenda items
When deleting an event in the Proton Calendar, I still want to be reminded that it was there originally. Is it possible to offer two kinds of delete:
(A) strike through the event (so it is still visible in the calendar, but now the title is in strike through), or
(B) permanently delete the event?3 votes -
newsletter digest
Creating a daily or weekly digest message of newsletters. I can see the implementation being like an automatically generated email (opt in) that takes all the sender addresses and subject lines from every messages sorted into the newsletter view and delivered back into the inbox. This would condense messages quickly to make sure nothing important was missed and allow you to skip over everything else. This would be EXTRA useful if newsletters could be completely removed from the inbox view, or is a new -newsletter view was created. Really cut down on the clutter without the chance of missing something or something being misfiled
Creating a daily or weekly digest message of newsletters. I can see the implementation being like an automatically generated email (opt in) that takes all the sender addresses and subject lines from every messages sorted into the newsletter view and delivered back into the inbox. This would condense messages quickly to make sure nothing important was missed and allow you to skip over everything else. This would be EXTRA useful if newsletters could be completely removed from the inbox view, or is a new -newsletter view was created. Really cut down on the clutter without the chance of missing something…
2 votes -
Option to alphabetically sort labels
I would like the option to automatically sort labels alphabetically whenever I create a new label. This would make it easier to find a particular label in the side panel.
2 votes -
Reading mode for email body
Reading mode for email body with the ability to choose font size and background color would have been fantastic.
4 votes -
Provide the ability to edit the subject line of an e-mail
Often an e-mail comes with a subject line that doesn't completely describe the content. For example, in a newsletter e-mail there may be several articles and the subject line is the first article. I may want to save the e-mail because of the second article. When this happens, I forward the e-mail to myself so I can change the subject line, but then I lose who it came from. Outlook has provided the capability to edit the subject line for many years and I'm surprised I haven't seen this feature in other e-mail applications. Seems like a simple thing to do.
Often an e-mail comes with a subject line that doesn't completely describe the content. For example, in a newsletter e-mail there may be several articles and the subject line is the first article. I may want to save the e-mail because of the second article. When this happens, I forward the e-mail to myself so I can change the subject line, but then I lose who it came from. Outlook has provided the capability to edit the subject line for many years and I'm surprised I haven't seen this feature in other e-mail applications. Seems like a simple thing to…
8 votes -
Restore position of 'unread' filter button to left column on desktop
When using the Column layout on desktop, the new position of the Unread button anchored to the right of the top bar (the one with the 'select all' button) means that for larger monitors with greater real estate, it's now in a much more inconvenient and further away position compared to when it was above the list of emails.
I believe it was on the top bar, but in line with the rightmost side of the left pane. I saw this as quite a logical place, as you would usually be looking at the list in the left pane when considering applying the unread filter.
An option to change this, or alternatively just an 'unread mail' folder as other ideas have suggested, would be greatly appreciated solutions, as my primary use is for just checking for every unread message across all folders. Thanks for your time!
When using the Column layout on desktop, the new position of the Unread button anchored to the right of the top bar (the one with the 'select all' button) means that for larger monitors with greater real estate, it's now in a much more inconvenient and further away position compared to when it was above the list of emails.
I believe it was on the top bar, but in line with the rightmost side of the left pane. I saw this as quite a logical place, as you would usually be looking at the list in the left pane when…
1 vote -
Reordering categories
It should be possible to choose the order of the new automatic categories on top of Proton Mail.
1 vote -
Offer drag and drop for Social, Promotional, and Newsletters
I'm having trouble moving messages to their best location, which rather defeats the purpose of these new settings.
1 vote -
Improve Android Tablet and Desktop Resizability
Please improve proton android apps to support Android Tablets, Android Desktop, Chromebook and Googlebook. https://developer.android.com/about/versions/17/changes/ff-restrictions-ignored
1 vote -
Search date filter use standard date format
Protonmail search web, when searching in mails, trying to filter by date or date range.
- Manually clicking on arrow month by month.. no no.
- We can edit the date year at least but still have to enter manuall month name but only it's short version or the filter fails/reset.
- I'd like to search like anywhere else typing dd/mm/YYYY or dd-mm-YYYY please let me filter by standard date format !
Example 01/01/2020 and not 01 Jan. 2020
Thanks ! :D
1 vote -
Critical Security Vulnerability: Missing Default-Deny Policy – Why Whitelist Fails Against Zero-Click Exploits (State Trojans)
Dear Proton Team,
Currently, Proton Mail under "Blocked and Allowed Senders Lists" offers only a whitelist as a positive exception in a system that standardly accepts everything ("Default-Allow").
The "Allowed" function serves merely to move important emails back from the Spam folder to the Inbox. It does not prevent the receipt of emails from other domains.
The "Blocked" function serves to block known, malicious senders.
The Fundamental Security Problem: For users who need to protect themselves against Zero-Click Exploits (e.g., advanced state trojans like Pegasus or similar spyware), this "Default-Allow" model is fundamentally insufficient and dangerous.
The Impossibility of a Complete Blocklist: An attacker can register thousands of domains or use hacked servers to send malicious emails. A "Blocked" list can never cover all future, unknown attackers. As soon as a new, malicious domain is created, it is not on the list, and the email is accepted.
The Risk of Server-Side Acceptance: As long as the Proton server accepts every connection from an unknown domain (even if it is later moved to Spam), there is a critical risk that a Zero-Click Exploit could be executed during the processing phase (rendering images, parsing metadata, analyzing attachments). The malicious code does not even need the user to open it; it can compromise the email client or server infrastructure as soon as the data touches the server.
Misunderstanding of the Current "Allowed" List: Many users mistakenly believe that an "Allowed" list automatically blocks everything else. This is technically not the case. The current list is only a filter ensuring that certain emails do not land in Spam. It is not a firewall that cuts off access for everyone else.
The Demand: A True "Strict Allow-Only Mode" (Default-Deny Policy) I demand the introduction of a separate, explicit setting "Allow Only Permitted Senders" that fulfills the following technical requirements:
Server-Side Rejection (TCP-Level Blockade): The server must immediately reject every connection from a domain/sender that is not explicitly on the whitelist (e.g., with 550 Access Denied) before the email data is even transmitted.
No Data Acceptance: The connection must be severed at the entrance. No data packets containing a potential exploit may be received.
Full User Control: Users must be given the opportunity to completely close their digital gate ("Air-Gap" principle for email) without relying on infinite and never-complete blocklists.
Why Proton Urgently Needs This: Proton advertises worldwide with "maximum protection" and "end-to-end encryption." Yet, without a "Default-Deny" option, the door remains physically open to unknown attackers.
Competitive Advantage: With this function, Proton would be the only commercial email provider enabling users to protect themselves against state surveillance and zero-day attacks through strict perimeter security.
Existential Necessity: For journalists, whistleblowers, and activists, this is not an optional comfort feature, but a matter of survival.
Next Steps: Please evaluate this request for technical feasibility and prioritize its integration into the roadmap for security updates. The responsibility for maintaining the whitelist lies with the user this is the principle of every high-security system. Proton should offer this choice to substantiate its position as the world's safest provider.
Thank you for your work on a safer internet.
Dear Proton Team,
Currently, Proton Mail under "Blocked and Allowed Senders Lists" offers only a whitelist as a positive exception in a system that standardly accepts everything ("Default-Allow").
The "Allowed" function serves merely to move important emails back from the Spam folder to the Inbox. It does not prevent the receipt of emails from other domains.
The "Blocked" function serves to block known, malicious senders.
The Fundamental Security Problem: For users who need to protect themselves against Zero-Click Exploits (e.g., advanced state trojans like Pegasus or similar spyware), this "Default-Allow" model is fundamentally insufficient and dangerous.
The Impossibility of a…
3 votes -
Support more than 4 Security Keys
Proton supports only 4 hardware security keys - this is not enough. Especially since using biometrics counts against the 4 key limit. I have three desktop computers which run my Proton accounts, and I have mobile devices which require 1 key. So I can't use the biometrics option without forcing a game of musical chairs with my security keys. I'm forced to continue using and subscribing to my 1Password account rather than Proton Pass until this limit is increased.
51 votes -
Saving calendar entry needs to be faster on iOS
Saving a calendar entry in iOS is very very slow, please make it faster.
5 votes -
Dynamic email / alias addressing
This would be most likely against the way email is working nowadays, but could every email I create be sent from dynamically created alias so I do not own a real, static email address as such and I am not prone to any spam, phishing attemps and so on?
I could imagine me, my digital identity, my emails being of a digital pod which could be contacted only when I would have made a first, initial attempt.
I am not even sure if this technically makes sense,
2 votes -
Tags and sub-tags
I would love it if we could have sub-tags. For example, Hawaii would be a tag nested under Travel. Although folders allow subfolders, I think tags are so much more nimble and flexible.
72 votes
- Don't see your idea?