Elitism-Free Working Group Within Errata Exist Category: Informational July 2019 Stop Gatekeeping Email Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. In order to prevent misunderstanding of context in which this RFC applies, please refer to the document "Use Plaintext Email"[1] before drawing your conclusions on this document. This, combined with the commentary in Section 3 regarding the lockout of users not using plain-text email from contributing to a popular Linux distribution known as "Alpine Linux"[2], should provide adequate introduction as to the parameters of this RFC. 1. https://useplaintext.email/ 2. https://lists.alpinelinux.org/~alpine/devel/ Abstract In a world of things to get angry about, a select group of people [Ref. 1] have decided that the thing which riles them up most in their lives is the decision of other people to use standard email. That is, electronic mail with contents that are not purely plain-text. This memo discusses allowing individuals to contribute to already borderline-fringe communities without gatekeeping contributors based on their choice of electronic mail client. A portion of this memo contains a detailed functional specification for taking over a project to enforce your views by exploiting a power vacuum in the project's leadership, and seizing upon that moment of weakness[Appendix A]. TABLE OF CONTENTS 1. INTRODUCTION ................................................... 2 2. USING NORMAL E-MAIL LIKE A NORMAL PERSON ....................... 2 3. NOT GATEKEEPING CONTRIBUTIONS DUE TO YOUR VIEWS ON HTML ..... .. 2 APPENDIX A: CONDUCTING A HOSTILE TAKEOVER OF A LINUX DISTRIBUTION . 3 SECURITY CONSIDERATIONS REFUTATIONS ............................... 4 REFERENCES ........................................................ 5 POSTSCRIPT ........................................................ 5 ERRATA ............................................................ 6 Within & Company [Page 1] RFC -1 Stop Gatekeeping Email July 2019 1. INTRODUCTION The set of protocols colloquially known as e-mail (electronic mail) comprise a low-bandwidth, asynchronous, international, and de-centralized method of communication for individuals across the internet. As technology has improved, matured, and extended in the years since the introduction of the Simple Mail Transfer Protocol (SMTP) in 1988 [RFC 288], modifications to the restrictions upon mail sent and received has been made. One such change is the addition of, and support for, the usage of HyperText Markup Language (HTML) in e-mail [RFC 2822] in 2001. 1.1 Evolution of E-mail Like many things in the digital space, the usage of HTML inside an email is voluntary and in no way an enforced standard. An individual can choose to send email that renders like it was written in Microsoft Notepad without obtaining permission or, in many cases, even changing settings of their e-mail client. E-mail itself is an asynchronous method of communication between two or more parties, and has several extensions to allow the addition of HTML for markup, or the attachment of files or other media, including the ability to do so in-line in order to provide maximum contextual understanding of the subject matter. 1.2 Problem Individuals Recently, there has been an uptick in organisations that, due to their choice of mailing list operations manager, are utilising mailing list management software that explicitly blocks and denies e-mail submissions that are using HTML, even if the email's contents are purely plain-text. This includes messages that contain a plain-text multipart which can be rendered separately. This has resulted in a considerable loss of talent by individuals[Ref. 2] who are choosing to use e-mail clients that do not provide the ability to disable HTML emails for the sake of simplicity, or because the functionality is not required for the majority of the application's user base. 2. USING NORMAL E-MAIL LIKE A NORMAL PERSON From a user standpoint, e-mail is extremely simple to use. An e-mail account can be made at any number of free or paid services, which provides a Post Office Protocol (POP) or Internet Message Access Protocol (IMAP) version 4 account to which an e-mail client can be connected and used to receive mail. Further information on the structure of a client-server e-mail connection can be found in [RFC 3501]. 2.1 Server to Server Transmission After outbound email has been queued by the e-mail client, it is transmitted between the user's home e-mail server and the target's e-mail server in a series of hops over the Simple Mail Transfer Protocol. Further information on the structure of a server-server e-mail connection, including hop and gateway functionality, can be found in [RFC 822]. 2.2 Using Standard E-mail Settings Most e-mail clients and servers permit the usage of HTML inside the Within & Company [Page 2] RFC -1 Stop Gatekeeping Email July 2019 body of the e-mail message in order to provide markup. Outside of a select few services, this would be widely considered the standard operating procedure for e-mail. This behaviour is considered default in a vast array of e-mail clients that are in use by the overwhelming majority of individuals who use e-mail for both business and personal reasons. It is possible, although unlikely, that once the custom settings to perform operations such as limiting ones' e-mail messages to a line width of 72 characters, or disabling the transmission of e-mails in HTML format, are discovered by an operator they will choose not to enable them. This phenomenon has been named "not being a contrarian" by the scientific community. 3. NOT GATEKEEPING CONTRIBUTIONS DUE TO YOUR VIEWS ON HTML It is possible, though extremely unlikely, that once these settings are enabled the operator will not choose to enforce them on others - often against their will. The scientific community has named this phenomenon "not being retroactively uninvited to parties". 3.1 Not enforcing your choice on mailing shared e-mail spaces It is thoroughly recommended that upon choosing to enable settings whose justification has largely faded screen were only 80 characters wide, one does not enforce this choice on other people. This is especially true in volunteer communities such as the Alpine Linux community, whereby any individual who utilises e-mail clients in that cannot disable HTML e-mail messages - such as macOS Mail, iOS mail, GMail, or others - will find that they cannot contribute to the mailing lists, which are used for development and steering of the community and distribution. 3.2 Using whatever client you please It is thoroughly recommended that you let individuals within the community use whatever e-mail client they please. APPENDIX A: CONDUCTING A HOSTILE TAKEOVER OF A LINUX DISTRIBUTION Case Study: Alpine Linux Upon the dismantling of the original mailing lists due to the power vacuum caused by several high-profile Alpine Linux core contributors leaving the project due to burnout or personal reasons, the individual behind SourceHut, aka sr.ht, stepped up to provide new mailing list software. After this individual stepped in to provide this "service", the ability to contribute to the mailing lists using e-mail with HTML ceased. This was described by the Alpine Linux project lead as: > a surprise and unintentional (except from a single person) > super annoying to get locked out of participation like this > imho, unacceptable Experts world-wide are still attempting to discern the identity of the "single person". Efforts are ongoing, but progress is being made. Within & Company [Page 3] RFC -1 Stop Gatekeeping Email July 2019 SECURITY CONSIDERATIONS REFUTATIONS Several security considerations have been made by individuals who have demonstrated that they are making things up on the spot[3]. This section will address each of those accusations: 1. HTML as a vector for phishing Most, if not all, mail clients used by normal people will detect that the URL of the link is not the same as the text of the link, and flag it as suspicious. Additionally, individuals who perform phishing attacks have - for as long as domain names have been purchaseable - purchased domains that look almost, but not entirely, like the domain of the target. Examples of these domain purchases can be found in the Certificate Transparency Logs, known as CRT.SH. 2. Privacy invasion and tracking The accusation levelled against HTML emails is that marketers use HTML e-mails which provide things like a tracking pixel or other minutia in order to discern as to whether or not you have opened and read the e-mail. E-mail providers such as Google will automatically cache all remote content and serve it from its own server to prevent your IP address being leaked to the owner of the server to which the tracking pixel points. This also masks the time at which you open the email. Additionally, bad actors are also known use knives. An adequate justification for using scissors or an egg-wash brush to cut bread has yet to be seen. 3. Mail client vulnerabilities The accusation levelled against HTML emails in this subsection is that HTML is a complex and grey-area construct. This is not true. HTML has a standard grammar[4]. Additionally, only a small subset of HTML is often implemented into e-mail clients. E-mail clients do not need complex functionality such as iframes or JavaScript support, and as such ignore or discard parts of e-mails containing them. 4. HTML emails are less accessible and 5. Some clients can't display HTML emails at all These are only true if you explicitly choose to not render HTML in your e-mail client. Even text-only clients, such as Alpine[5] and Mutt[6], support the ability to render HTML contents as readable text. Additionally, mobile e-mail clients such as GMail and Apple Mail, used on the popular Android and iOS mobile operating systems, default to HTML email, and offer accessibility features for blind or low-vision users. Additionally, hard-linewraps at 70 characters are known to cause legitimate issues with synthesized-voice screen reading software. 6. Rich text isn't that great, anyway This was written on a site using HTML to enlarge headers, show horizontal rules, and allow in-line links using HTML's anchor functionality. In short, every single point inside this list has been demonstrated as false. [3] https://useplaintext.email/ [4] https://html.spec.whatwg.org/ [5] https://en.wikipedia.org/wiki/Alpine_(email_client) [6] http://jasonwryan.com/blog/2012/05/12/mutt/ Within & Company [Page 4] RFC -1 Stop Gatekeeping Email July 2019 REFERENCES DeVault, Drew (@sir@cmpwn.com). "https://cmpwn.com/@sir/102496129057809282" 24 July 2019 11:13AM UTC Dodrill, Christine (Cadey). "What is the process to mass-disown all the packages you maintain?" 24 July 2019 10:36AM UTC POSTSCRIPT > "But if plaintext is so good, why is this page written in HTML?" > This is a reference document, not an email, you twit. If a defence of HTML e-mail can be written in plain-text, a defence of using an abacus can too. Within & Company [Page 5] RFC -1 Stop Gatekeeping Email July 2019 ERRATA 2019-07-25 0700 UTC Evolution of strongly-worded language which undermined the point of the memorandum - partly to poke fun, partly to be sarcastic, and partly to stop a project from becoming even more edgy. All for $4 in domain costs. Thanks to unnamed individuals on the Hacker News website for discussing this. Within & Company [Page 6]