Network Working Group M. Richardson Internet-Draft Sandelman Software Works Intended status: Standards Track 22 June 2025 Expires: 24 December 2025 A policy on third-party links in IETF emails and archives draft-richardson-no-trackers-in-archives-00 Abstract This document established a hyper-linking policy for IETF mailing lists and IETF mailing list archives. The IETF will not tolerate posts that contain third-party links that can track users and contributors. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-richardson-no-trackers-in- archives/. Discussion of this document takes place on the ietf Working Group mailing list (mailto:ietf@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ietf/. Subscribe at https://www.ietf.org/mailman/listinfo/ietf/. Source for this draft and an issue tracker can be found at https://github.com/mcr/no-trackers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Richardson Expires 24 December 2025 [Page 1] Internet-Draft no-trackers June 2025 This Internet-Draft will expire on 24 December 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Risks to other Participants . . . . . . . . . . . . . . . 3 1.2. Risks to the IETF . . . . . . . . . . . . . . . . . . . . 4 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Filter URLs in mail archive . . . . . . . . . . . . . . . 4 2.2. Filter URLs when processing emails . . . . . . . . . . . 4 2.3. No HTML email . . . . . . . . . . . . . . . . . . . . . . 5 3. Objections . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The IETF does most of it's work via email lists. Indeed unlike many organizations, face to face meetings are not considered final, and process documents [RFC2026] emphasis that it is on mailing lists that rough consensus is sought: [RFC7282]. To that end, an accurate, searchable, safe and public archive is maintained by the IETF. Viewing the archives should not subject participants to monitoring by third parties. Richardson Expires 24 December 2025 [Page 2] Internet-Draft no-trackers June 2025 An increasing occurance is (enterprise) email systems that attempt to make all links "safe" for their employees, screening their employees from the phising attack of the day. This is often accomplishing by filtering all email for HTTP links that appear in email, and then rewriting them to go through a filtering service. Such services attempt to then block links that the enterprise considers harmful. When contributors from So, instead of a link to https://example.com/, a link to something like https://filtering-service.example/https%3A/example.com/ is left, often with HTML adjusted so that users that use the text/html part never even know they are going through a filtering service. This is fine for the IETF contributor themselves, but then the contributor might reply to the email, quoting the original email, including the rewritten link. This is then sent back to the IETF mailing list. 1.1. Risks to other Participants Other readers, particularily those whose mail user agent prefers an HTML rendering, will then get links which go through the filtering service. Should the reader decide to follow that link: it might point some important discussion on an IETF mailarchive, or reference data, or other standards organization, then the reader will disclose their activity to this third party filtering service. (The author of this document suspects that this may well violate privacy proviions of the GDPR, but the author has no expertise to know) The above is the _best case_ situation. The user's privacy is violated. In some other cases, the filtering service in question will refuse to process the request, and the link is broken. This could because the filtering service has no contract with the reader. Filtering services would be well advised to not process link requests from random strangers on the Internet. Answering such things is essentially creating an open proxy by which attackers can mount destributed denial of service attacks on others. These services should be encouraged not to allow this, but closing this loophole would render all the links broken to others. Richardson Expires 24 December 2025 [Page 3] Internet-Draft no-trackers June 2025 Some filtering services are not stateless: that is, they do not store the entire method to access the target URL in the URL they provide. Instead, there is some amount of state that is created in a database, and that state is used to find the target URL. Such systems have some advantages to the enterprises that use them, but at some point the database will fill up, and the state will be removed. When that occurs the link will also break, and end users will not be able to recover the original link. 1.2. Risks to the IETF The IETF maintains an extensive archive for all emails accessible by web browser, and by IMAP. While the archive stores the entire email, including all renderings (text/plain, text/html, and any other attachments), the web interface to the archive does not display the text/html part. Users who are reading the archives will therefore see that the link will redirect them. Knowing not to follow that link depends upon the sophistication of the user, and their knowledge of current filtering systems. Some users will know how to edit the link to remove the filtering part, but this is at best an arcane activity. Users that access the archives by IMAP have access to all parts of the email, and if they rely on the text/html part, will also never see that they are being redirected. 2. Solutions 2.1. Filter URLs in mail archive Recognizing URLs in email, even text/plain parts is already done by the mailarchive system. They are turned into HTML links in the web presentation. A denylist system could filter links that simply not turn links that include trackers/filters into HTML on the web interface. This still leaves direct readers and IMAP users vulnerable. 2.2. Filter URLs when processing emails The same URL recognizing system could operate as a mailman filter. It could either render the filtering URLs unuseable. Richardson Expires 24 December 2025 [Page 4] Internet-Draft no-trackers June 2025 Alternatively, it could reject the email. While the 451 result code used in HTTP [RFC7725] might seem appropriate, 4xx code in SMTP are retriable, some 5xx code would need to be used. There would need to be a FAQ page cited back to the user so that they could understand what the problem was. 2.3. No HTML email Since the trackers are hardest to see for users when the email is HTML encoded, one answer is to just filter out the text/html part of emails. This is already a feature of mailman3, and there are other large volunteer organizations, such as the Linux Kernel Community where this is routinely done: [tsohtmlkernel] Some contributors send only the text/html part, and once it is removed, there is nothing left. Such emails would then need to be rejected, again with a clear message, and a reference to a FAQ. 3. Objections The list of all the filtering systems is unbounced, which ones are a problem is a problem. Like all security questions, there are no promises of absolute security, but rather incremental improvements that make this better. One advantage of the increasingly centralization of email is that the set of filtering systems that these centralized solutions use is not that large. A great deal of improvement can be made with only a few rules. The filtering options that would reject email will be confusing to many users. In particular, if the filter rewriting is not visible to the user in their Sent box, then it might be very difficult for them to understand what has gone one. In many cases, the tracking URL was not placed in the user themselves, but was in some of the text that was quoted. Lack of editing of quoted parts in email, particularly by those in top-quote and do not read the email itself, is unfortunately endemnic. Learning to quote properly is a key part of contributing well to the IETF. In many cases, the presence of the tracking URL is part of quoted that text that does not even need to be present. It is not a new problem that many enterprises have email systems that are incompatible with the IETF. Contributors who can not get their local systems fixed have wound up going to email providers which do not have these problems. This has often had a positive effect on stability of email references in documents, however, this represents a significant barrier to new contributors. Richardson Expires 24 December 2025 [Page 5] Internet-Draft no-trackers June 2025 4. Privacy Considerations This entire document is about a privacy violation that the lack of a policy is perpetuating. 5. Security Considerations This document establishes a policy. This policy has significant possibility to inappropriately filter email, which may appear to some as censorship. However, as explained by [RFC8890], when there is a conflict, the needs of the end users are considered more important than the needs of expert IETF contributors. One purpose of this document is to allow IETF contributors to point to a policy document in order to get their local enterprise entities to make appropriate arrangements. 6. IANA Considerations This document establishes a policy and requires no IANA activities. However, the list of links that would be filtered by the IETF mail processing system needs to be placed in a public place. An IANA Registry was considered, but was deemed in appropriate. Instead the IETF Tools team is asked to make the filter list public in some form. 7. Acknowledgements Hello. 8. Changelog 9. References 9.1. Normative References [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, DOI 10.17487/RFC7282, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References Richardson Expires 24 December 2025 [Page 6] Internet-Draft no-trackers June 2025 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7725] Bray, T., "An HTTP Status Code to Report Legal Obstacles", RFC 7725, DOI 10.17487/RFC7725, February 2016, . [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, DOI 10.17487/RFC8890, August 2020, . [tsohtmlkernel] T'so, T., "IETF@IETF.org email archive, posting from Theodore T'so", 19 August 2023, . Author's Address Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca Richardson Expires 24 December 2025 [Page 7]