[{"data":1,"prerenderedAt":125},["ShallowReactive",2],{"Q1mIqkmYOa3KqLdOCtU5_UBrBL5T9W9BawWJpyAXsWE":3,"_apollo:default":95},{"page":4,"blog":13},{"__typename":5,"title":6,"slug":7,"subtitle":8,"_seoMetaTags":9,"_allSlugLocales":82,"deal":13,"tapfiliateReferralCode":8,"tapfiliateTapS":8,"footerTheme":87,"seoStructuredData":13,"hideTopNavigation":88,"sections":89},"PageRecord","Download the StartMail Whitepaper – Privacy & Security Insights","whitepaper","",[10,15,19,22,26,29,32,36,40,44,48,51,54,58,62,66,70,74,78],{"__typename":11,"tag":12,"attributes":13,"content":14},"Tag","title",null,"StartMail Whitepaper – Privacy & Security Insights",{"__typename":11,"tag":16,"attributes":17,"content":13},"meta",{"property":18,"content":14},"og:title",{"__typename":11,"tag":16,"attributes":20,"content":13},{"name":21,"content":14},"twitter:title",{"__typename":11,"tag":16,"attributes":23,"content":13},{"name":24,"content":25},"description","Explore in-depth insights on email privacy and security – Download the StartMail whitepaper to learn how to protect your communication.",{"__typename":11,"tag":16,"attributes":27,"content":13},{"property":28,"content":25},"og:description",{"__typename":11,"tag":16,"attributes":30,"content":13},{"name":31,"content":25},"twitter:description",{"__typename":11,"tag":16,"attributes":33,"content":13},{"property":34,"content":35},"og:image","https://www.datocms-assets.com/47413/1628148351-logo-wide.jpg?auto=format&fit=max&w=1200",{"__typename":11,"tag":16,"attributes":37,"content":13},{"property":38,"content":39},"og:image:width","1000",{"__typename":11,"tag":16,"attributes":41,"content":13},{"property":42,"content":43},"og:image:height","500",{"__typename":11,"tag":16,"attributes":45,"content":13},{"property":46,"content":47},"og:image:alt","StartMail Logo",{"__typename":11,"tag":16,"attributes":49,"content":13},{"name":50,"content":35},"twitter:image",{"__typename":11,"tag":16,"attributes":52,"content":13},{"name":53,"content":47},"twitter:image:alt",{"__typename":11,"tag":16,"attributes":55,"content":13},{"property":56,"content":57},"og:locale","en",{"__typename":11,"tag":16,"attributes":59,"content":13},{"property":60,"content":61},"og:type","article",{"__typename":11,"tag":16,"attributes":63,"content":13},{"property":64,"content":65},"og:site_name","StartMail",{"__typename":11,"tag":16,"attributes":67,"content":13},{"property":68,"content":69},"article:modified_time","2025-06-11T12:11:11Z",{"__typename":11,"tag":16,"attributes":71,"content":13},{"property":72,"content":73},"article:publisher","https://www.facebook.com/MyStartMail/",{"__typename":11,"tag":16,"attributes":75,"content":13},{"name":76,"content":77},"twitter:card","summary",{"__typename":11,"tag":16,"attributes":79,"content":13},{"name":80,"content":81},"twitter:site","@MyStartMail",[83,86],{"__typename":84,"locale":85,"value":7},"StringNonNullMultiLocaleField","de",{"__typename":84,"locale":57,"value":7},"light",false,[90,92],{"__typename":91,"centeredTitle":88,"subtitle":8,"title":8},"PageHeaderRecord",{"__typename":93,"requiredBody":94},"MarkdownSectionRecord","\u003Ch2>Table of Contents \u003Ca name=\"startmail-technical-white-paper\">\u003C/a>\u003C/h2>\n\n\u003Cp>\u003Cstrong>1\u003C/strong>. \u003Ca href=\"#1-introduction\">Introduction.\u003C/a>\u003Cbr>\u003C/p>\n\n\u003Cp>\u003Cstrong>2\u003C/strong>. \u003Ca href=\"#2-overview-of-startmail\">Overview of StartMail\u003C/a>\u003Cbr>\u003C/p>\n\n\u003Cp>\u003Cstrong>3\u003C/strong>. \u003Ca href=\"#3-design-considerations\">Design Considerations.\u003C/a>\u003Cbr>\n   \u003Cstrong>3.1\u003C/strong> \u003Ca href=\"#31-webmail-vs-desktop-client\">Webmail vs Desktop Client.\u003C/a>\u003Cbr>\n   \u003Cstrong>3.2\u003C/strong> \u003Ca href=\"#32-client-side-vs-server-side-encryption\">Client-side vs Server-side Encryption.\u003C/a>\u003Cbr>\n   \u003Cstrong>3.3\u003C/strong> \u003Ca href=\"#33-client-side-vs-server-side-key-storage\">Client-side vs Server-side Key Storage.\u003C/a>\u003Cbr>\n   \u003Cstrong>3.4\u003C/strong> \u003Ca href=\"#34-performance-and-debugging-information-vs-privacy\">Performance and Debugging Information vs Privacy.\u003C/a>\u003Cbr>\n   \u003Cstrong>3.5\u003C/strong> \u003Ca href=\"#35-open-source-vs-closed-source-software\">Open Source vs Closed Source Software.\u003C/a>\u003C/p>\n\n\u003Cp>\u003Cstrong>4\u003C/strong>. \u003Ca href=\"#4-security-measures\">Security Measures.\u003C/a>\u003Cbr>\n   \u003Cstrong>4.1\u003C/strong> \u003Ca href=\"#41-processes-and-principles\">Processes and Principles.\u003C/a>\u003Cbr>\n   \u003Cstrong>4.1.1\u003C/strong> \u003Ca href=\"#411-development-process\">Development process.\u003C/a>\u003Cbr>\n   \u003Cstrong>4.1.2\u003C/strong> \u003Ca href=\"#412-open-source\">Open Source.\u003C/a>\u003Cbr>\n   \u003Cstrong>4.1.3\u003C/strong> \u003Ca href=\"#413-cryptography\">Cryptography.\u003C/a>\u003Cbr>\n   \u003Cstrong>4.2\u003C/strong> \u003Ca href=\"#42-service-architecture\">Service Architecture.\u003C/a>\u003Cbr>\n   \u003Cstrong>4.2.1\u003C/strong> \u003Ca href=\"#421-general-architecture\">General Architecture.\u003C/a>\u003Cbr>\n  \u003Cstrong>4.2.2\u003C/strong> \u003Ca href=\"#422-user-vault\">User Vault.\u003C/a>\u003Cbr>\n   \u003Cstrong>4.2.3\u003C/strong> \u003Ca href=\"#423-webmail-features\">Webmail Features.\u003C/a>\u003Cbr>\n   \u003Cstrong>4.2.4\u003C/strong> \u003Ca href=\"#424-recovery\">Recovery.\u003C/a>\u003Cbr>\n   \u003Cstrong>4.2.5\u003C/strong> \u003Ca href=\"#425-imap-and-mobile-devices\">IMAP and Mobile Devices.\u003C/a>\u003Cbr>\n   \u003Cstrong>4.2.6\u003C/strong> \u003Ca href=\"#426-infrastructure-security\">Infrastructure Security.\u003C/a>\u003C/p>\n\n\u003Cp>\u003Cstrong>5\u003C/strong>. \u003Ca href=\"#5-conclusion\">Conclusion.\u003C/a>\u003C/p>\n\n\u003Cp>\u003Cstrong>6\u003C/strong>. \u003Ca href=\"#6-references\">References.\u003C/a>\u003C/p>\n\n\u003Ch2>1. Introduction \u003Ca name=\"1-introduction\">\u003C/a>\u003C/h2>\n\n\u003Cp>In recent years, and in 2013 in particular, a series of events have shown that even our everyday\ncommunications are valuable to eavesdroppers. Email is one of the most privacy sensitive services\npeople use online, and keeping communications private is no simple task. Powerful standards such as\nSSL/TLS and OpenPGP already exist, but using them and setting them up correctly can present\ndifficulties for many novice users. Due to the learning curve associated with setting up and using\nencryption, many people continue to communicate through insecure platforms.\u003C/p>\n\n\u003Cp>StartMail aims to solve this problem. We consider privacy a fundamental human right, and we set out\nto bring privacy and security to the average user. StartMail was designed to help people regain\ntheir right to privacy by using powerful cryptography for their daily email communications.\u003C/p>\n\n\u003Cp>StartMail was created by the people behind the private search engines Startpage.com and Ixquick.com.\nDevelopment took more than three years, and it was a natural step from offering private online\nsearch to offering secure and private email communications.\u003C/p>\n\n\u003Cp>This document explains the choices we made when it comes to security practices and protecting the\nprivacy of our users. We first give a quick overview of our services, and then we list the most\nimportant design choices that were made while designing our service architecture. Finally, we\ndescribe those decisions in detail, focusing on security-oriented precautions and features.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003Ca name=\"2-overview-of-startmail\">\u003C/a>\u003C/p>\n\n\u003Ch2>2. Overview of StartMail \u003Ca name=\"2-overview-of-startmail\">\u003C/a>\u003C/h2>\n\n\u003Cp>StartMail is a platform for secure email communications. Our service can be accessed from a webmail\ninterface, as well as through the traditional IMAP protocol, for compatibility with existing email\nclients.\u003C/p>\n\n\u003Cp>Advanced functionality is available to power users who have enough knowledge and experience to\nbenefit from it. For example, users can autonomously store their recovery code, import and manage\nexisting OpenPGP keys, or even manually handle all the OpenPGP interactions altogether, making\nStartMail the relay platform for their own secure communications.\u003C/p>\n\n\u003Cp>We aim to make secure communications as transparent as possible. To this end, OpenPGP is used. Power\nusers have the option to opt out from all cryptography-related functionality and handle their\ncryptography themselves, then access their email through IMAP. But by default, StartMail offers the\nfollowing security features to users:\u003C/p>\n\n\u003Cul>\n\u003Cli>Asymmetric encryption and signing using OpenPGP to both StartMail and non-StartMail users\u003C/li>\n\u003Cli>Password-based encryption to users who do not use OpenPGP\u003C/li>\n\u003Cli>Company operations and legal entity based strictly outside of US jurisdiction\u003C/li>\n\u003Cli>Storage of a minimal amount of data about users and no tracking cookies. See our \u003Ca href=\"/privacy/\">very strict\nprivacy policy [1]\u003C/a>\u003C/li>\n\u003Cli>All data belonging to users, including mail, preferences, and anti-spam profile, is stored\nencrypted in their “User Vault”\u003C/li>\n\u003Cli>Emails that arrive for users are immediately encrypted with the public key of their “queue key\npair” for later delivery when the User Vault is opened by the user\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch2>3. Design Considerations \u003Ca name=\"3-design-considerations\">\u003C/a>\u003C/h2>\n\n\u003Cp>When creating StartMail, we were presented with several choices concerning security, privacy and\nuser experience in our service. In this section we address the most notable decisions.\u003C/p>\n\n\u003Ch3>3.1. Webmail vs Desktop Client \u003Ca name=\"31-webmail-vs-desktop-client\">\u003C/a>\u003C/h3>\n\n\u003Cp>Our goal in creating StartMail was to develop a beginner-friendly OpenPGP client. We decided to\noffer a webmail client rather than a desktop (or mobile) application for several reasons. First,\nmany email users have grown accustomed to using a browser to access their mail. Second, since users\nexpect to be able to access their mail from different devices, a webmail solution gives them an\nalternative to OS-specific applications and allows them to benefit from the ubiquity that browsers\noffer. Finally, there are already secure OpenPGP compatible desktop clients that can be configured\nto work with StartMail via IMAP.\u003C/p>\n\n\u003Cp>The StartMail Web application is a PGP-enabled mail client for the Web. Nevertheless, we also offer\nfull support for traditional email clients using IMAP.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch3>3.2. Client-side vs Server-side Encryption  \u003Ca name=\"32-client-side-vs-server-side-encryption\">\u003C/a>\u003C/h3>\n\n\u003Cp>By design, OpenPGP operations (such as encryption and decryption) can take place either on the\nserver or on the client. In StartMail, all OpenPGP operations take place server-side.\u003C/p>\n\n\u003Cp>We have opted to perform cryptography on the server after thoroughly considering the client-side\noption. We rejected it because OpenPGP operations in a Web browser take place in a JavaScript\ncontext, which is not at all the right environment for cryptography. A number of compelling reasons\nwhy this is the case are described by NCC Group in this excellent article:\u003C/p>\n\n\u003Cp>\u003Ca href=\"https://web.archive.org/web/20181118155543/https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/\">https://web.archive.org/web/20181118155543/https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/\u003C/a>\u003C/p>\n\n\u003Cp>Among the reasons for rejecting client-side cryptographic operations are:\u003C/p>\n\n\u003Cul>\n\u003Cli>\u003Cp>The malleability of the JavaScript runtime environment means that auditing the future security of\na piece of JavaScript code is impossible: The server providing the JavaScript could easily place a\nbackdoor in the code, or the code could be modified at runtime through another script. This\nrequires users to place the same measure of trust in the server providing the JavaScript as they\nwould need to do with server-side handling of cryptography.\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>JavaScript is executed in an environment (the browser) over which the programmer has extremely\nlittle control. In these conditions it becomes hard or impossible to perform secure memory\nmanagement, protect against timing attacks, and so forth.\u003C/p>\u003C/li>\n\u003C/ul>\n\n\u003Cp>In simpler terms: JavaScript is a poor environment for handling such a delicate operation as\ncryptography. What’s more, JavaScript code that runs in the browser can be influenced by any other\npiece of JavaScript code running in the same browser window, and sometimes even by other pages.\nThese conditions would make it impossible for us to provide the same level of security we can offer\nby delivering server-side cryptography.\u003C/p>\n\n\u003Cp>A commonly cited benefit of performing client-side cryptography is that, in theory at least, the\nserver or mail provider never has access to the user’s OpenPGP private key, thus reducing the amount\nof trust that the user needs to place in the mail provider. In practice, however, this security\nbenefit is illusory. The only way in which OpenPGP private keys are truly not in contact with any\nserver or server-provided code is by performing cryptography through native desktop applications\n(e.g. GnuPG or GPGtools). StartMail already fully supports this through IMAP.\u003C/p>\n\n\u003Cp>Client-side cryptographic operations performed in a Web browser using JavaScript offer only\nsuperficial protection against a server that has been compromised or has malicious intent. This is\nbecause the JavaScript code that is executed is received directly from the server. In this way, the\nbrowser becomes an extension of the server-side application for certain operations.\u003C/p>\n\n\u003Cp>We view the client-side (browser) vs server-side debate as a moving target, and we will be watching\nfor technological advancements that will allow us to revisit our decision. Especially in the field\nof browser-based cryptography, the availability and the quality of libraries change rapidly. We will\nconsider implementing a client-side solution once the browser ecosystem and available libraries have\ndeveloped to a degree necessary to provide trustworthy cryptographic operations.\u003C/p>\n\n\u003Cp>There are trust issues involved regardless of whether OpenPGP operations take place in the browser\nor on the server. For this reason we believe “real client side” (native desktop) to be the most\nsecure option. It allows users to have complete control over their OpenPGP key management and\ncryptography operations in an environment that is more suitable for that purpose than the browser.\nThere are still obvious issues with user experience, setup complexity, and potential data loss in\ndesktop clients. While this option is fully compatible by connecting to StartMail via IMAP, we also\naim to offer the most secure browser-based solution we can.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch3>3.3. Client-side vs Server-side Key Storage \u003Ca name=\"33-client-side-vs-server-side-key-storage\">\u003C/a>\u003C/h3>\n\n\u003Cp>Regardless of where encryption and decryption operations take place, a discussion about OpenPGP key\nstorage is in order. Client-side key storage means that the OpenPGP private key is permanently\nstored on the users’ computers (as opposed to being stored on the server). Users will either store\nthe key permanently in the browser or they will carry their key with them and make it available to\nthe browser when needed.\u003C/p>\n\n\u003Cp>Browsers do not have a secure way of storing OpenPGP keys that meets our standards. What’s more, the\ngreat majority of people still run outdated browsers. In other contexts, this could be solved with\n\u003Ca href=\"https://en.wikipedia.org/wiki/Fault_tolerance\">“graceful degradation” [2]\u003C/a> (e.g. reverting to an\nalternative CSS property because the browser doesn’t support newer ones). This is simply not a\nviable option in a security model. Until this situation improves, we prefer not to expose our users’\nPGP keys to the dangers of in-browser storage. Since we chose the server-side approach for handling\ncryptographic operations (for reasons described above), we do not see a compelling case for exposing\nthe key to browsers.\u003C/p>\n\n\u003Cp>Needless to say, users carrying their OpenPGP keys around with them is a potential security concern.\nUsers may not have the knowledge or patience to take the necessary precautions to ensure their key\nis not overly duplicated or stored insecurely.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch3>3.4. Performance and Debugging Information vs Privacy  \u003Ca name=\"34-performance-and-debugging-information-vs-privacy\">\u003C/a>\u003C/h3>\n\n\u003Cp>Keeping a log of activities that occur on our servers can be useful for debugging purposes,\nperformance improvements and security enhancements. However, in deciding what data to log, we always\ntip the scale in favor of our users’ privacy and security.\u003C/p>\n\n\u003Cp>A key example of this is our approach to handling spam filter profile data. Along with the standard\nalgorithms, we use metadata to obtain real-life examples of what users do and do not consider spam.\nWe choose to store this information in the user’s personal User Vault (described below), instead of\nusing it generally to enhance the overall effectiveness of our spam filter. To do otherwise would\nmean making parts of a user’s emails available within the whole system, which would violate our\ncommitment to making privacy our top priority.\u003C/p>\n\n\u003Cp>A similar situation exists for search indexing. In order for the search functionality to respond\nquickly, email needs to be indexed and indices must be up to date. This can happen at any point in\ntime, provided it occurs before the user begins a search. In the case of StartMail, however, the\nuser’s search indices can only be updated when the user is logged in. When the user is not logged\nin, emails and indices are stored encrypted in the User Vault, and indexing operations cannot take\nplace. The constraint that forces us to index email only upon log-in provides better privacy and\nsecurity for our users at the expense of a slight drawback in terms of processing speed.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch3>3.5. Open Source vs Closed Source Software \u003Ca name=\"35-open-source-vs-closed-source-software\">\u003C/a>\u003C/h3>\n\n\u003Cp>StartMail’s source code consists of a mix of open-source and closed-source components. The\nopen-source components are mainly infrastructure-related code (such as the Linux operating system\nand the OpenPGP cryptographic suite) along with supporting libraries for our Web application, e.g.\njQuery and AngularJS. The code we wrote to provide the webmail service, manage User Vaults, and\nprovide redundancy, is closed source.\u003C/p>\n\n\u003Cp>Open-source code provides a security advantage since a large number of people can access the source\ncode and help to secure it by performing audits and reporting vulnerabilities. However, we believe\nthe advantages of open-source code only apply to large projects with a strong supporting community.\nWhen a project is still too small to draw attention from external security experts, releasing the\nsource code could pose a security risk that offsets the benefits. Potential attackers are given a\npowerful extra weapon: the source code of the application.\u003C/p>\n\n\u003Cp>Therefore, we have chosen to keep our source code closed, as a security measure,\nand hire independent third-party auditors to verify our privacy and security\nmeasures. As StartMail grows, the potential benefits of opening up our source\ncode may at some point outweigh the costs, and we will re-evaluate this decision\nat that time.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch2>4. Security Measures \u003Ca name=\"4-security-measures\">\u003C/a>\u003C/h2>\n\n\u003Cp>The previous section described the design choices that were made during the development of\nStartMail. In this section we explore the security measures that influence the organization, the\ndevelopment and maintenance processes, as well as the technical architecture.\u003C/p>\n\n\u003Ch3>4.1. Processes and Principles \u003Ca name=\"41-processes-and-principles\">\u003C/a>\u003C/h3>\n\n\u003Cp>We designed StartMail with privacy and security as our priorities. But no matter how secure a system\nis in theory, if a critical service contains a vulnerability, attackers can bypass carefully crafted\nsecurity measures. With this possibility in mind, we instituted a security-oriented development\nprocess to ensure that vulnerabilities are not introduced while the code is being developed and\nmaintained. We also added multiple layers of defense to limit the damage any one vulnerability can\ncause.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.1.1. Development Process \u003Ca name=\"411-development-process\">\u003C/a>\u003C/h4>\n\n\u003Cp>Having secure code is a top priority in a project like StartMail. Of course, various measures exist\nto limit the impact that a vulnerability in our software could have.\u003C/p>\n\n\u003Cp>We have multiple measures in place to make sure internal and external auditors can objectively\nassess StartMail’s code:\u003C/p>\n\n\u003Cul>\n\u003Cli>The programmers who work on StartMail have had training in secure development, and have experience\nin the field.\u003C/li>\n\u003Cli>High quality code that is well structured and easily readable is essential for security. Thus, we\ntake great care to ensure that our code is clear for reviewers so they can understand the\nstructure and flows. This allows them to focus on finding vulnerabilities.\u003C/li>\n\u003Cli>Each line of code is reviewed by multiple developers (other than the author) for quality and\nsecurity before it enters the code base. Issues identified during this review cause the code to be\nrejected: It cannot move forward until the issues are resolved.\u003C/li>\n\u003Cli>Security professionals who are not part of the development team perform security audits of the\ncode written by the developers. This is also the case for external libraries.\u003C/li>\n\u003Cli>The development infrastructure (code repository, issue tracker, review tooling) is used only for\nthe StartMail project and is only accessible by its team members and auditors.\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.1.2. Open Source \u003Ca name=\"412-open-source\">\u003C/a>\u003C/h4>\n\n\u003Cp>We believe that using open-source libraries and tools, as opposed to ones controlled by commercial\nentities, is often the more secure choice. Solid communities are behind the development of these\ntools, and the available source allows us to internally audit them before considering whether to\nintroduce them into our application. This is the main reason why, in addition to the code we write\nourselves, we only use open-source components within the application.\u003C/p>\n\n\u003Cp>Since the developers behind these tools also need to be supported in order to continue their\ndevelopment, StartMail has donated to open-source projects like \u003Ca href=\"https://www.openbsdfoundation.org/contributors.html\">LibreSSL\n[3]\u003C/a>.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.1.3. Cryptography \u003Ca name=\"413-cryptography\">\u003C/a>\u003C/h4>\n\n\u003Cp>Reinventing the wheel, when it comes to cryptography (and security in general), is a very \u003Ca href=\"https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own\">bad idea\n[4]\u003C/a>. It is not only\nunnecessary, but potentially harmful. History shows that cryptography is best left to standard\nlibraries and tools, proven algorithms that have been subject to close scrutiny from the open-source\nand academic communities. Generally, developers are aware of this, but the issue is quite nuanced.\nAmong the things we deem best left to cryptography experts, three categories are most notable:\u003C/p>\n\n\u003Cul>\n\u003Cli>Cryptographic algorithms for encryption, decryption and hashing. It is not a very good idea to try\nto replace AES, RSA or SHA-2.\u003C/li>\n\u003Cli>Cryptographic protocols like PBKDF2, HMAC, TLS and various PKCS standards. Even when using proven\ncryptographic algorithms, it is usually unwise to come up with your own scheme to use them in.\u003C/li>\n\u003Cli>Cryptographic implementations. Even when using textbook cryptographic algorithms, and remaining\nwithin the confines of proven protocols, the implementation is never trivial. We leave this to\nopen-source libraries that are vetted by the community. In the case of OpenSSL, which received\n\u003Ca href=\"https://www.openbsd.org/papers/bsdcan14-libressl/\">too little attention from the security community\n[5]\u003C/a>, we follow developments closely and will\nconsider replacing OpenSSL as soon as a viable candidate becomes available.\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch3>4.2. Service Architecture \u003Ca name=\"42-service-architecture\">\u003C/a>\u003C/h3>\n\n\u003Cp>The previous section discussed security measures that take place at the organizational and process\nlevel. In this section we explain our consideration of the general architecture, webmail, account\nrecovery methods and IMAP.\u003C/p>\n\n\u003Ch4>4.2.1. General Architecture \u003Ca name=\"421-general-architecture\">\u003C/a>\u003C/h4>\n\n\u003Ch4>4.2.1.1. Transport Layer Security (TLS)\u003C/h4>\n\n\u003Cp>In order to communicate with our users securely, we encrypt each connection using the TLS protocol.\nThe exact details of how a connection to StartMail is encrypted depend on what the server and client\nnegotiate during the setup of the TLS connection. By configuring secure preferences, the clients\nthat support these requirements (which are all recent clients) will have secure connections with us.\u003C/p>\n\n\u003Cp>StartMail takes strict security measures when it comes to TLS:\u003C/p>\n\n\u003Cul>\n\u003Cli>Our servers are configured according to industry best practices.\u003C/li>\n\u003Cli>We use certificates from Let's Encrypt, the world's largest certificate authority (CA), a\ntransparent non-profit organization whose mission is to make the internet more secure and\nprivacy-respecting.\u003C/li>\n\u003Cli>We use CAA DNS records to prevent other CAs from issuing certificates for StartMail domains.\u003C/li>\n\u003Cli>We monitor the certificate transparency logs for issuance of certificates for StartMail domains.\u003C/li>\n\u003Cli>We use DNSSEC to sign DNS records, protecting visitors with enabled domain signature validation\nagainst manipulated DNS responses.\u003C/li>\n\u003Cli>We use HTTP Strict Transport Security (HSTS). We have submitted our domain to the HSTS Preload\nList.\u003C/li>\n\u003Cli>We encourage the use of Perfect Forward Secrecy (PFS), which prevents past traffic from being\ndecrypted even in the unlikely case that our private key would be compromised.\u003C/li>\n\u003Cli>We improve privacy and security for our users by having Online Certificate Status Protocol (OCSP)\nstapling enabled.\u003C/li>\n\u003Cli>We use DANE (TLSA DNS records) to publish fingerprints of the TLS certificates used by our mail\ndelivery systems (SMTP), allowing others to verify that they are communicating with our MX\nservers. When sending emails to third parties, we check their DANE records to ensure authenticated\nand encrypted delivery.\u003C/li>\n\u003Cli>Similarly, we use MTA-STS to enforce validity checks on our certificates for incoming mail.\u003C/li>\n\u003C/ul>\n\n\u003Cp>For a full evaluation of our TLS connection and practices please refer to our \u003Ca href=\"https://www.ssllabs.com/ssltest/analyze.html?d=startmail.com\">SSL Labs report\n[6]\u003C/a>.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.1.2. Encryption in Transit and Storage\u003C/h4>\n\n\u003Cp>All connections to StartMail servers (and between StartMail servers) are protected by TLS\nencryption. Even though the connection is encrypted in transit, we recommend encrypting the emails\nthemselves using OpenPGP so they can be stored encrypted while on the server or while being\ndelivered via a less reputable external provider. Using OpenPGP is especially vital in communicating\nwith others whose email providers are not committed to privacy and security, and when users access\ntheir email via IMAP (thus storing copies of their emails on a device).\u003C/p>\n\n\u003Cp>The diagrams below illustrate the difference between encrypting the connection and encrypting the\ndata itself, and why they are both important.\u003C/p>\n\n\u003Cp>\u003Cimg src=\"/static/images/ssl-only.png\" alt=\"\">\u003C/p>\n\n\u003Cp>\u003Cimg src=\"/static/images/ssl-and-openpgp.png\" alt=\"\">\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.1.3. Header Stripping\u003C/h4>\n\n\u003Cp>As an added privacy feature we have implemented some header-stripping functionality for both\nincoming and outgoing mail.\u003C/p>\n\n\u003Cp>For both incoming and outgoing mail we have the following measures in place:\u003C/p>\n\n\u003Cul>\n\u003Cli>\u003Cp>Obfuscation of local IP addresses and hostnames. This is done in order not to give out information\nabout the infrastructure.\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>Reject email coming from blacklisted “From” addresses. For instance, emails claiming to be from\n“\u003Ca href=\"mailto:administrator@startmail.com\">administrator@startmail.com\u003C/a>” or similar addresses.\u003C/p>\u003C/li>\n\u003C/ul>\n\n\u003Cp>Specifically for outgoing mail, we strip out the following headers:\u003C/p>\n\n\u003Cul>\n\u003Cli>Mime-Version\u003C/li>\n\u003Cli>Received\u003C/li>\n\u003Cli>User-Agent\u003C/li>\n\u003Cli>X-Enigmail-Version\u003C/li>\n\u003Cli>X-Mailer\u003C/li>\n\u003Cli>X-Originating-IP\u003C/li>\n\u003Cli>X-Pgp-Agent\u003C/li>\n\u003Cli>X-Virus-Scanned\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.1.4. Rate Limiting\u003C/h4>\n\n\u003Cp>We have rate-limiting features in place to protect the system against password brute-forcing and\nusername enumeration. A short-term (less than an hour) storage of IP addresses is used in order to\nidentify potential attackers and limit the rate of password guessing. This is done in accordance\nwith our privacy policy.\u003C/p>\n\n\u003Ch4>4.2.2. User Vault \u003Ca name=\"422-user-vault\">\u003C/a>\u003C/h4>\n\n\u003Cp>User data is stored in what we call a User Vault, which is essentially a fully encrypted \u003Ca href=\"https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup\">LUKS\nvolume [7]\u003C/a>. Users can access its contents\nfor the length of their session by providing their account password.\u003C/p>\n\n\u003Cp>While the Vault is closed (i.e. the volume is not mounted), no one can access the contents of the\nVault, even if they otherwise have access to the server.\u003C/p>\n\n\u003Cp>Because of our User Vault system, we do not have to store users’ passwords. Instead of checking a\nuser’s password, we simply use it to attempt to open the Vault. If this succeeds, the password was\ncorrect. Of course, the appropriate security measures are in place to protect ourselves against\ntiming attacks when checking credentials this way.\u003C/p>\n\n\u003Ch4>4.2.2.1. What do we Store in the User Vaults?\u003C/h4>\n\n\u003Cp>We store the user’s email messages and everything that is private about the user’s account in the\nuser’s own User Vault (see our privacy policy for more details). This means that every time users\nwant to access their Inbox, they must first open the account User Vault.\u003C/p>\n\n\u003Ch4>4.2.2.1.1 Mail\u003C/h4>\n\n\u003Cp>Email is stored in the User Vault when it is delivered to an account. Naturally, messages that\narrive while users are logged out cannot be delivered until users manually open their User Vault by\nlogging in.\u003C/p>\n\n\u003Cp>Since we only want data to be accessible by the user it belongs to, an extra OpenPGP key pair is\ngenerated for every user and used as the “queue key pair”. The private key is stored inside the User\nVault, and the public key is accessible to the mailer service. When mail for a user arrives, it is\nencrypted with the queue’s public key of that user and stored in a queue. Once the User Vault is\nopened (when the user logs in), emails are decrypted with the queue’s private key and moved to the\nuser’s Inbox.\u003C/p>\n\n\u003Cp>NOTE: The queue key pair is *completely separate* from the account’s OpenPGP key pair used for\ncommunications.\u003C/p>\n\n\u003Cp>Of course, end-to-end protection is already in place when the sender of the message chooses to\nencrypt it using OpenPGP, which we always recommend. The process described above is simply an\nadditional security layer.\u003C/p>\n\n\u003Ch4>4.2.2.1.2 Spam and Metadata\u003C/h4>\n\n\u003Cp>StartMail allows users to train SpamAssassin’s Bayesian spam filter by marking emails as spam or\nnot-spam in the webmail interface. The metadata related to spam filter training is still considered\nto be sensitive user data because it contains at least part of the contents of a user’s emails. For\nthis reason this data is stored inside the User Vault. This means that no one but the user can\naccess this data, and that every user will have their own personally trained spam filter.\u003C/p>\n\n\u003Ch4>4.2.2.1.3 Keyring\u003C/h4>\n\n\u003Cp>If users opt in to use OpenPGP features in the StartMail webmail interface, their OpenPGP keyring\nwill also be stored in their User Vault. They can add other (public and private) keys to their\nkeyring for communication with other users.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch3>4.2.3. Webmail Features \u003Ca name=\"423-webmail-features\">\u003C/a>\u003C/h3>\n\n\u003Cp>Through our webmail platform, we offer various features that enhance the security of messages. In\nthis chapter we provide details about the implementation of these features.\u003C/p>\n\n\u003Ch4>4.2.3.1. Password-protected messages\u003C/h4>\n\n\u003Cp>Password-protected messaged can be created by simply selecting\n"Encrypt" when composing an email. Sending a Password-protected\nmessage is very similar to sending an encrypted email, with a few\ndifferences:\u003C/p>\n\n\u003Cul>\n\u003Cli>\u003Cp>The message is encrypted with GnuPG in symmetric mode, where the password is the passphrase supplied to GnuPG.\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>Unlike a classic asymmetric OpenPGP encrypted message that needs to be encrypted for all the\npublic keys of the recipients, this encryption option is available for any recipient – even those\nfor whom no OpenPGP public key has been imported.\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>The message is not actually sent out as an email. Instead:\u003C/p>\n\n\u003Cul>\n\u003Cli>It is stored encrypted on our servers.\u003C/li>\n\u003Cli>A notification email is sent out to the recipient of the message. This notification contains a\nlink to a page on a StartMail server.\u003C/li>\n\u003Cli>When the recipient clicks the link in the notification email, they have to enter the password to decrypt the message.\u003C/li>\n\u003Cli>The recipient has only five (5) opportunities available to provide the correct password, after\nwhich the message will no longer be accessible. This is done to prevent brute-forcing.\u003C/li>\n\u003Cli>Once the recipient provides the correct password, he or she will be able to view\nthe content of the message and reply securely through the same interface.\u003C/li>\n\u003C/ul>\u003C/li>\n\u003C/ul>\n\n\u003Cp>As an additional security measure, password-protected messages are\nautomatically deleted from the StartMail server after a set amount of\ntime.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.3.2. OpenPGP\u003C/h4>\n\n\u003Cp>We offer \u003Ca href=\"https://en.wikipedia.org/wiki/Pretty_Good_Privacy\">OpenPGP functionality [8]\u003C/a> in our\nwebmail interface. OpenPGP is a standard protocol, described in depth in \u003Ca href=\"https://tools.ietf.org/html/rfc4880\">RFC 4880\n[9]\u003C/a>. According to the OpenPGP standard, two separate keys are\nused for encrypting and decrypting data. Every user has their own key pair: One private key which is\nused, along with a secret passphrase, to decrypt messages and files; and one public key, designed to\nbe given to other people. Messages encrypted with a particular public key can only be decrypted with\nthe associated private key.\u003C/p>\n\n\u003Cp>Once users activate OpenPGP functionalities, they are prompted to either generate a new key pair or\nimport an existing PGP key pair.\u003C/p>\n\n\u003Ch4>4.2.3.2.1 New OpenPGP Key\u003C/h4>\n\n\u003Cp>We use the standard GnuPG tool to generate a new key pair (a public and private key) on the server.\nThe key pair’s associated email address is, of course, the user’s StartMail address.\u003C/p>\n\n\u003Cp>The keys that are generated by StartMail are 4096 bit RSA keys.\u003C/p>\n\n\u003Ch4>4.2.3.2.2 Imported OpenPGP Key\u003C/h4>\n\n\u003Cp>Users who already have an OpenPGP key pair can import it into StartMail. The StartMail email address\nneeds to be associated with the key pair before importing it.\u003C/p>\n\n\u003Ch4>4.2.3.2.3 OpenPGP Key Management\u003C/h4>\n\n\u003Cp>Basic key management is available in the StartMail Web application:\u003C/p>\n\n\u003Cul>\n\u003Cli>\u003Cp>Changing the private key’s passphrase\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>Importing/exporting keys\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>Regenerating keys\u003C/p>\u003C/li>\n\u003C/ul>\n\n\u003Ch4>4.2.3.2.4 Passphrase Caching\u003C/h4>\n\n\u003Cp>The private OpenPGP key is stored encrypted on the server inside the User Vault. Additionally, the\nkey itself is always encrypted with a passphrase. The use of OpenPGP in the Web interface means that\nthe private key’s passphrase will have to be available to the application so that decryption and\nencryption operations can take place on the server. Whenever the passphrase is needed, users are\nprompted to type it in and can choose to optionally keep it in memory.\u003C/p>\n\n\u003Cp>If the user chooses to keep the passphrase cached, then the passphrase is encrypted and stored in-memory on the server. The\nencryption key for the passphrase is stored in a cookie in the browser. This means that an attacker\nwho gains access to a user’s cookie still cannot recover the passphrase itself.\u003C/p>\n\n\u003Cp>Obviously, not caching the passphrase at all is the most secure option, if somewhat inconvenient,\nbut we leave this choice to the user.\u003C/p>\n\n\u003Ch4>4.2.3.2.5 OpenPGP Key Directory\u003C/h4>\n\n\u003Cp>When users let StartMail handle their OpenPGP operations, the public key is automatically added to\nan internal key directory. When the user composes an encrypted email message to another StartMail\nuser who has also set up OpenPGP in StartMail, the public key of the recipient is retrieved from the\nkey directory. Users can opt out from this key directory in their preferences.\u003C/p>\n\n\u003Cp>NOTE: The public keys are not shared with StartMail users, nor are they publicly available. They are\nonly used to transparently encrypt communications *among* StartMail users. However, users are\nadditionally given the option to upload their OpenPGP public key to the \u003Ca href=\"https://pgp.mit.edu/\">MIT OpenPGP Key Server\n[10]\u003C/a>.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.3.2.6 Signing and Verifying a Signature\u003C/h4>\n\n\u003Cp>Along with email encryption and decryption in the StartMail webmail interface, we provide the\npossibility of signing emails with OpenPGP signatures. Signing emails is very important: It provides\na way to verify the sender’s identity by guaranteeing that the person sending the encrypted email is\nthe owner of a private key that matches the sender’s email address. By default, all OpenPGP\nencrypted emails sent via the StartMail webmail interface are also signed.\u003C/p>\n\n\u003Cp>The StartMail webmail interface provides visual feedback about the validity of signatures on email\nmessages and warns users when they receive messages with an invalid signature. In order to verify\nsignatures of other StartMail users, their OpenPGP public key is automatically retrieved from the\ninternal key directory mentioned in the previous section.\u003C/p>\n\n\u003Ch4>4.2.3.2.7 OpenPGP Keyring in Vault\u003C/h4>\n\n\u003Cp>As previously mentioned, one of the items stored in the User Vault is the OpenPGP keyring. This is\nimportant because without opening the User Vault, the user’s own key pair is not available to the\nsystem. The keyring contains the user’s own key pair and all other keys he has uploaded or imported.\u003C/p>\n\n\u003Ch4>4.2.3.2.8 OpenPGP and BCC Receivers\u003C/h4>\n\n\u003Cp>With traditional PGP encrypted email, using the BCC field to declare recipients that should not be\nexposed to others is impossible. This follows from the fact that an encrypted message also includes\nthe key IDs for which the message has been encrypted. Any recipient with knowledge about the key IDs\ncan also determine who was included in the message by inspecting the keys listed in the encrypted\nmessage.\u003C/p>\n\n\u003Cp>There are several ways to prevent this leaking of data. We chose to extract all BCC receivers from a\nmessage sent through our webmail service. We then create and encrypt a separate email for each\nindividual BCC recipient and leave them out completely from the original message that is sent. This\nway, no information about the BCC recipients will leak to the other primary recipients.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.3.2.9 PGP Message Type (MIME/Inline)\u003C/h4>\n\n\u003Cp>We fully adopt the PGP/MIME message structure for all outgoing messages because it cleanly encrypts\nall attachments without exposing metadata about them. Furthermore, it is more reliable for non-ASCII\ntext and works properly with HTML email.\u003C/p>\n\n\u003Cp>Finally, PGP/MIME is generally considered the most appropriate method and allows all mail clients to\nproperly display the message, whether they have PGP support or not.\u003C/p>\n\n\u003Cp>If we receive a message encrypted or signed with PGP/Inline, we can correctly decrypt it (given we\nhave access to a matching private key) and verify signatures (given we have access to the public\nkey). When replying or forwarding PGP/Inline messages, we convert them to PGP/MIME.\u003C/p>\n\n\u003Cp>Although PGP/MIME is known to be unsupported by some older email clients, we value the privacy and\nsecurity improvements of this structure and consider them to be more important than compatibility\nwith clients that have limited MIME compatibility.\u003C/p>\n\n\u003Ch3>4.2.4. Recovery \u003Ca name=\"424-recovery\">\u003C/a>\u003C/h3>\n\n\u003Ch4>4.2.4.1. Personal Account Password Recovery\u003C/h4>\n\n\u003Cp>Should users ever forget their account password, we offer the possibility to recover it:\u003C/p>\n\n\u003Cul>\n\u003Cli>Using a recovery code\u003C/li>\n\u003Cli>Having a reset link emailed to their recovery email address\u003C/li>\n\u003C/ul>\n\n\u003Cp>During signup, users may choose between either obtaining a recovery code or setting a recovery email\naddress. The recovery code is provided if the user chooses not to set and confirm a recovery email\naddress.\u003C/p>\n\n\u003Cp>It is important to note that regardless of the user’s choice, a recovery code will be generated\nautomatically by the system. The user will be completely responsible for its safekeeping. If the\nuser does not set and confirm a recovery email address, StartMail will not store the code. When the\nuser designates and confirms a recovery email address, StartMail will store the code encrypted. We\nexplain the process in detail in this section.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.4.1.1 Recovery with a Recovery Code\u003C/h4>\n\n\u003Cp>The recovery code, obtained during signup, can be used to manually reset the account if the user\nforgets their account’s password.\u003C/p>\n\n\u003Cp>StartMail does not store recovery codes for accounts that do not set and confirm a recovery email\naddress. Therefore, our staff cannot help users who lose their recovery code. It is technically\nimpossible for us to manually reset accounts, and, even if it were possible, we would have no way to\nverify the identity of the person requesting the recovery.\u003C/p>\n\n\u003Cp>Whenever giving out recovery codes this way, the responsibility of secure storage shifts to the\nusers. We recommend that users who feel they may have trouble safely storing the recovery code\nthemselves, provide a recovery address and allow StartMail to handle the storage and the recovery\nfor them, should it be necessary.\u003C/p>\n\n\u003Ch4>4.2.4.1.2 Recovery with a Recovery Address\u003C/h4>\n\n\u003Ch5>ADDRESS VERIFICATION\u003C/h5>\n\n\u003Cp>After signup, if a recovery address is added, a verification email is sent out to the recovery\naddress. Confirming that recovery email address is very important because it allows StartMail to\nverify the ownership of the email address set for recovery. Once the address is verified, users can\nproceed to request a recovery, should it become necessary.\u003C/p>\n\n\u003Cp>NOTE: Users must confirm their recovery email address before attempting to recover their account, or\nwe will not be able to proceed with the recovery process.\u003C/p>\n\n\u003Ch5>RECOVERY CODE STORAGE\u003C/h5>\n\n\u003Cp>The recovery code is generated automatically by the server and stored in an OpenPGP encrypted file,\nusing multiple layers of encryption. (The next section explains why this is relevant.) No one,\nincluding StartMail support staff or administrators, can access the unencrypted recovery code, nor\ncan anyone manually produce a recovery code associated with any account.\u003C/p>\n\n\u003Cp>We deem it very important to shield the recovery code from human access. The recovery code\neffectively gives whoever possesses it the power to reset an account’s password. An attacker in\npossession of such a code could take over the account completely. We take every precaution necessary\nto make sure it can only be obtained by the legitimate user.\u003C/p>\n\n\u003Ch5>MORE THAN ONE PERSON REQUIRED TO DECRYPT\u003C/h5>\n\n\u003Cp>The process of authorizing a recovery request is not entirely automated. It requires two separate\nsenior members of the management team to decrypt (remove a layer of encryption) and acknowledge the\nrequest. The people involved reside on separate continents (EU and US) to keep them under different\nlegal jurisdictions.\u003C/p>\n\n\u003Cp>This is done to prevent a single person from having the power to approve a request. Should the\nauthority of one person be compromised, additional interaction is always required in order to\nproceed with the account recovery.\u003C/p>\n\n\u003Cp>Once the second required manager has acknowledged the recovery request and decrypted the recovery\nfile with their key, the resulting file is forwarded to the StartMail system. The StartMail system\nthen removes the last layer of encryption and sends out the recovery code to the verified email\nrecovery address for the account.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.4.2. Recovering the Account\u003C/h4>\n\n\u003Cp>The account recovery process involves changing the password of a user’s User Vault. The Vault is a\n\u003Ca href=\"https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup\">LUKS volume [7]\u003C/a>, which has several key\nslots: one slot is used for authentication, another for recovery. A successful recovery will result\nin the following:\u003C/p>\n\n\u003Cul>\n\u003Cli>The Vault is unlocked using the key corresponding to the recovery slot\u003C/li>\n\u003Cli>The old authentication slot is overwritten by setting a new password\u003C/li>\n\u003Cli>The old recovery slot is overwritten by generating a new recovery code\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.5. IMAP and Mobile Devices \u003Ca name=\"425-imap-and-mobile-devices\">\u003C/a>\u003C/h4>\n\n\u003Cp>Users who wish to access their email through a separate email client can do so through IMAP. IMAP\naccess is disabled by default, and can be enabled in the Settings menu.\u003C/p>\n\n\u003Cp>NOTE: Many users accessing their email from a separate email client are used to the POP3 protocol.\nIMAP works in a very similar way, but is designed to keep messages stored on the remote server until\nthey are deleted, as opposed to always downloading them to the client machine and deleting them from\nthe server.\u003C/p>\n\n\u003Cp>IMAP (as opposed to POP3) integrates more naturally with viewing email in StartMail’s Web interface\nand allows users to still benefit from the secure storage that the User Vault system offers.\u003C/p>\n\n\u003Cp>We recommend configuring every external device separately that connects to StartMail via IMAP. Once\nusers add a (named) device, they will obtain a unique username, password and IMAP server information\ncombination that they can use to configure the device.\u003C/p>\n\n\u003Cp>Creating separate IMAP credentials for every device has several advantages in case one of the\nIMAP-enabled devices (laptop, phone) is compromised:\u003C/p>\n\n\u003Cul>\n\u003Cli>An attacker in possession of valid IMAP credentials only has access to a user’s messages. There is\nno risk that the entire StartMail account can be taken over by an attacker in this scenario.\u003C/li>\n\u003Cli>IMAP accounts can be independently disabled.\u003C/li>\n\u003C/ul>\n\n\u003Cp>Creating a different password for each device that connects to StartMail also offers an overview of\nwhich external services are accessing StartMail. Should a service ever become lost, obsolete, or\nunused it is simple to remove the device and revoke access.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.5.1. Automatic Disabling of a Device\u003C/h4>\n\n\u003Cp>After numerous unsuccessful authentication attempts, a device will be disabled. Users can verify\nthat a device has been disabled by logging into their StartMail account, going to the Mobile/IMAP\nSettings page, and verifying that the device in question is marked as disabled.\u003C/p>\n\n\u003Cp>Once a device has been disabled, it cannot be re-enabled. A disabled device can be set up again as a\n“new” device.\u003C/p>\n\n\u003Ch4>4.2.6. Infrastructure Security \u003Ca name=\"426-infrastructure-security\">\u003C/a>\u003C/h4>\n\n\u003Cp>Our infrastructure is strictly based in the Netherlands and has been built to support the security\nrequirements of the StartMail service.\u003C/p>\n\n\u003Cp>As a general rule, we isolate services and components of StartMail as much as possible in order to\ncontain the potential damage an attacker can do. For instance, User Vaults are stored on separate\nservers, in terms of infrastructure, from the Web servers. They communicate with each other through\na very limited API to minimize the damage that can be done by someone compromising a Web server.\u003C/p>\n\n\u003Cp>Furthermore, we have taken all standard precautions that would be expected in a secure hosting\nenvironment, such as internal (PFS) TLS communications, strict firewalls, full disk encryption on\nall machines, and so forth. We have also taken extra measures to anonymize logs, as described in\ndetail in our privacy policy.\u003C/p>\n\n\u003Cp>Finally, we use active logging and alerting, integrated with a kernel-level audit system that alerts\nus to anomalous activities on all the servers. These logs are regularly reviewed for activity that\nmight indicate a compromise. In addition, failing to acknowledge audit log messages in a timely\nmanner results in a monitoring alert itself.\n\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch2>5. Conclusion \u003Ca name=\"5-conclusion\">\u003C/a>\u003C/h2>\n\n\u003Cp>The people behind StartMail have many years of experience in offering privacy-enhancing services.\nOur goal was to create an email service that truly embraces the promise of “encryption made easy,”\nto help people regain their right to secure and private communications.\nCreating a platform to make encrypted email communications available to the average user was a\nprocess of finding the optimal combination of user friendliness, privacy and security.\u003C/p>\n\n\u003Cp>We use proven cryptography libraries and rely on standard implementation to provide the underlying\nsecurity structure. Our development process is entirely focused on eliminating vulnerabilities\nbefore they enter our codebase. Our very strict (and complex) account recovery process prevents\nunauthorized users from having the ability to reset accounts. One of StartMail’s most important\nfeatures is the user’s personal User Vault, which allows us to encrypt all the data that belongs to\nthe user.\u003C/p>\n\n\u003Cp>We made carefully thought out choices, such as selecting server-side cryptography versus\nbrowser-based JavaScript solutions. We have thoughtfully considered where to store OpenPGP private\nkeys to ensure maximum security for the non-tech-savvy users. We have weighed enhancing our search\nand spam-detection algorithms against protecting email contents, and we have considered whether to\nrelease StartMail’s source code or remain closed source. In every trade-off, when given a choice, we\nhave made — and always will make — the decision that favors the security and privacy of our users.\u003C/p>\n\n\u003Cp>Our approach to introducing new technologies into our system is a very conservative one. We only\nrely on proven solutions that the cryptographic community has confidence in to securely protect our\nusers’ privacy. At the same time, we keep a keen eye out for new opportunities to enhance our\nsecurity practices. We periodically re-evaluate our decisions in the light of the new technologies\nas they become available so we can continue to offer the most secure, state-of-the-art service\npossible.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technical-white-paper\">Back to Top.\u003C/a>\u003C/p>\n\n\u003Ch2>6. References \u003Ca name=\"6-references\">\u003C/a>\u003C/h2>\n\n\u003Col>\n\u003Cli>\u003Cp>\u003Ca href=\"/privacy/\">https://www.startmail.com/privacy/\u003C/a> “StartMail Privacy Policy”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://en.wikipedia.org/wiki/Fault_tolerance\">https://en.wikipedia.org/wiki/Fault_tolerance\u003C/a> “Fault tolerance” (Graceful degradation is a particular type of implementing fault tolerance)\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://www.openbsdfoundation.org/contributors.html\">https://www.openbsdfoundation.org/contributors.html\u003C/a> “OpenBSD contributors list”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://www.openbsdfoundation.org/contributors.html\">https://www.openbsdfoundation.org/contributors.html\u003C/a> “Why shouldn’t we roll our own?”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://www.openbsd.org/papers/bsdcan14-libressl/\">https://www.openbsd.org/papers/bsdcan14-libressl/\u003C/a> “LibreSSL – The first 30 days”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://www.ssllabs.com/ssltest/analyze.html?d=startmail.com\">https://www.ssllabs.com/ssltest/analyze.html?d=startmail.com\u003C/a> “StartMail Qualys SSL Labs report”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup\">https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup\u003C/a> “Linux Unified Key Setup”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://en.wikipedia.org/wiki/Pretty_Good_Privacy\">https://en.wikipedia.org/wiki/Pretty_Good_Privacy\u003C/a> “PGP Encryption”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://tools.ietf.org/html/rfc4880\">https://tools.ietf.org/html/rfc4880\u003C/a> “RFC 4880”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://pgp.mit.edu/\">https://pgp.mit.edu/\u003C/a> “MIT PGP Public Key Server”\u003C/p>\u003C/li>\n\u003C/ol>\n",{"ROOT_QUERY":96},["null","__typename",97,"page({\"filter\":{\"slug\":{\"eq\":\"whitepaper\"}},\"locale\":\"en\"})",98,"blog({\"filter\":{\"slug\":{\"eq\":\"whitepaper\"}},\"locale\":\"en\"})",13],"Query",["null","__typename",5,"title",6,"slug",7,"subtitle({\"markdown\":true})",8,"_seoMetaTags",99,"_allSlugLocales",119,"deal",13,"tapfiliateReferralCode",8,"tapfiliateTapS",8,"footerTheme",87,"seoStructuredData",13,"hideTopNavigation",88,"sections",122],[100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118],["null","__typename",11,"tag",12,"attributes",13,"content",14],["null","__typename",11,"tag",16,"attributes",17,"content",13],["null","__typename",11,"tag",16,"attributes",20,"content",13],["null","__typename",11,"tag",16,"attributes",23,"content",13],["null","__typename",11,"tag",16,"attributes",27,"content",13],["null","__typename",11,"tag",16,"attributes",30,"content",13],["null","__typename",11,"tag",16,"attributes",33,"content",13],["null","__typename",11,"tag",16,"attributes",37,"content",13],["null","__typename",11,"tag",16,"attributes",41,"content",13],["null","__typename",11,"tag",16,"attributes",45,"content",13],["null","__typename",11,"tag",16,"attributes",49,"content",13],["null","__typename",11,"tag",16,"attributes",52,"content",13],["null","__typename",11,"tag",16,"attributes",55,"content",13],["null","__typename",11,"tag",16,"attributes",59,"content",13],["null","__typename",11,"tag",16,"attributes",63,"content",13],["null","__typename",11,"tag",16,"attributes",67,"content",13],["null","__typename",11,"tag",16,"attributes",71,"content",13],["null","__typename",11,"tag",16,"attributes",75,"content",13],["null","__typename",11,"tag",16,"attributes",79,"content",13],[120,121],["null","__typename",84,"locale",85,"value",7],["null","__typename",84,"locale",57,"value",7],[123,124],["null","__typename",91,"centeredTitle",88,"subtitle",8,"title",8],["null","__typename",93,"body({\"markdown\":true})",94],1775572981419]