RFC 4096

Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best

📅 published May 2005, from ietf

RFC 4096 📜✨

Okay bestie, RFC 4096 is titled "Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best" 💅 It was written by C. Malamud at Memory Palace Press, it's marked Informational, and the date is May 2005 🎀. The header doesn't say it obsoletes or updates anything, so it's a standalone little vibe check.

Status of This Memo 🌸

This memo gives information to the Internet community. It is not an Internet standard of any kind, and distribution of it is unlimited 🫶.

Copyright (C) The Internet Society (2005).

Abstract 🦋

This memo is about policies that make certain labels go into the "Subject:" header of an email. These policies are hard to write down accurately while still following the key RFCs, so they're probably ineffective at best 💀. The memo then pitches a different approach that's way simpler to spec and a little less likely to flop 🍓.

Table of Contents 🧚

   1. Labeling Requirements ...........................................2
      1.1. Terminology ................................................3
   2. Subject Line Encoding ...........................................3
   3. Implementing a Labeling Requirement .............................5
   4. Subjects are For Humans, Not Labels .............................6
   5. Solicitation Class Keywords .....................................8
   6. Security Considerations ........................................10
   7. Recommendations ................................................10
   8. Acknowledgements ...............................................10
   9. References .....................................................11
      9.1. Normative References ......................................11
      9.2. Informative References ....................................11

1. Labeling Requirements 🚨

Okay so the U.S. Congress and President passed the Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003 (CAN-SPAM Act of 2003) [US] 🇺🇸. Section 11(2) of it tells the Federal Trade Commission to do this:

"[transmit to the Congress] a report, within 18 months after the date of enactment of this Act, that sets forth a plan for requiring commercial electronic mail to be identifiable from its subject line, by means of compliance with Internet Engineering Task Force Standards, the use of the characters "ADV" in the subject line, or other comparable identifier, or an explanation of any concerns the Commission has that cause the Commission to recommend against this plan."

Next up, the Korean Government passed the Act on Promotion of Information and Communication and Communications Network Utilization and Information Protection of 2001 [Korea] 🇰🇷. The Korea Information Security Agency, which enforces it, explains that since June, 2003, Korean law requires the following:

"include the '@' (at) symbol in the title portion (right-side) of any commercial e-mail address, in addition to the words '(Advertisement)' or '(Adult Advertisement)' as applicable. The inclusion of the '@' symbol, as proposed by the Korean government, is intended to indicate an e-mail advertisement. Because e-mails easily cross international borders, the '@' symbol may be used as a symbol for filtering advertisement mails." [KISA]

The State of Colorado passed the Colorado Junk Email Law 🤠, which says:

"It shall be a violation of this article for any person that sends an unsolicited commercial electronic mail message to fail to use the exact characters "ADV:" (the capital letters "A", "D", and "V", in that order, followed immediately by a colon) as the first four characters in the subject line of an unsolicited commercial electronic mail message." [Colorado]

And the Rules of Professional Conduct of the Florida Bar, in Rule 4-7.6(c)(3), say:

"A lawyer shall not send, or knowingly permit to be sent, on the lawyer's behalf or on behalf of the lawyer's firm or partner, an associate, or any other lawyer affiliated with the lawyer or the lawyer's firm, an unsolicited electronic mail communication directly or indirectly to a prospective client for the purpose of obtaining professional employment unless ... the subject line of the communication states 'legal advertisement.'" [Florida] ⚖️

So a subject line that follows all of the above could look like this:

Subject: ADV: @ (Advertisement) legal advertisement

A full survey of every applicable law would, no doubt, make that example way longer 😭.

1.1. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. Those are the official requirement words, so they stay in caps 💅.

2. Subject Line Encoding 🎀

The basic definition of the "Subject:" of an email is in [RFC2822] 💌. The normative requirements that apply to all headers are:

  • The maximum length of the header field is 998 characters.
  • Each line must be no longer than 78 characters.

A multi-line subject field is marked by a carriage return followed by white space, like this:

Subject: This
 is a test

The standard says the three unstructured fields ("Subject:", "Comments:", and "Keywords:") are "intended to have only human-readable content with information about the message." It also says this about the "Subject:" field specifically:

The "Subject:" field is the most common and contains a short string identifying the topic of the message. When used in a reply, the field body MAY start with the string "Re: " (from the Latin "res", in the matter of) followed by the contents of the "Subject:" field body of the original message. If this is done, only one instance of the literal string "Re: " ought to be used since use of other strings or more than one instance can lead to undesirable consequences.

If you want more on how the "Subject:" field is structured, [RFC2047] is the place to go 🔍. It covers character set encoding in mail headers. [RFC2978] then specifies how to register character sets with the [IANA] 📝.

On top of picking a character set, [RFC2047] uses two algorithms, "Base64 Encoding" and "Quoted Printable". Both are ways of encoding characters that fall outside the basic 7-bit ASCII requirements in the core email standards 🍰.

So an encoded piece of text has these parts, in order:

  • The string =?, which marks the start of encoded text.
  • A valid character set indicator.
  • The string ?, which is a delimiter.
  • The string b if "Base64 Encoding" is used, or the string q if "Quoted Printable" encoding is used.
  • The string ?, which is a delimiter.
  • The text, which has been properly encoded.
  • The string ?=, which marks the end of the encoded text.

For a simple example, take the popular [8859-1] character set, which has accents and other characters that aren't in ASCII 🌈:

  • Subject: This is an ADV: is an unencoded header.
  • Subject: =?iso-8859-1?b?VGhpcyBpcyBhbiBBRFY6?= is encoded using Base64.
  • Subject: =?iso-8859-1?q?This=20is=20an=20ADV:?= is encoded using Quoted Printable.
  • Subject: =?iso-8859-1?q?This=20is=20an=20=41=44=56=3A?= is also encoded using Quoted Printable, but this time the last four characters are written as their hexadecimal representations 🧠.

Heads up, both the character set and the encoding indicators are case insensitive ✨. You can also add a language specification to the character set, as covered in [RFC2231] and [RFC3066]. That language spec is the string "*" followed by a valid language indicator. For example, "US-ASCII*EN" means the "US-ASCII" character set in English 🇬🇧.

When a message gets read, the "Subject:" field is decoded, and the characters from the character set show up for the user 👀. [RFC2047] Section 7 (Conformance) says a conforming mail reading program must do the following:

"The program must be able to display the unencoded text if the character set is "US-ASCII". For the ISO-8859-* character sets, the mail reading program must at least be able to display the characters which are also in the ASCII set."

But there's no rule that every system has to support every character set 🙈. Mail readers that can't display certain characters do all kinds of things, like silently dropping the unknown text or throwing an error or warning message.

Two traits of a lot of common Message User Agents (MUAs), like mail readers, are worth knowing about 🫶:

  • Even though the subject line is, in theory, unlimited in length, many mail readers only show the first few dozen characters.
  • Email often goes through gateways to reach pagers or cell phones with SMS capability, and those systems usually need short subject lines 📱.

More in part 2, bestie 🫶💖

3. Implementing a Labeling Requirement ✨

okay so this section is a hypothetical, but it's giving real-life government drama 💀 there are two key players:

  • John Doe [Doe] is an attorney at the firm of Dewey, Cheatem & Howe, LLC [Stooges].
  • The Federal Trust Commission (FTC) has been entrusted with implementing a recent labeling requirement, promulgated by the Sovereign Government of Freedonia [Duck]. Specifically, President Firefly directed the FTC to "make sure that anybody spamming folks get the symbol 'spam:' in the subject line and or shoot them, if you can find them."

bestie, the FTC wrote a super simple regulation: "Please obey the law." 🙈 John Doe is a lawyer, so he read the law and immediately found a loophole. He made his subject line really long and shoved all the stuff like "spam:" and the "@" symbol and other verbiage near the end of the 998 allowed characters. He was technically complying with the law, but nobody saw the labels in their reader 😭🫠

the FTC did a periodic review and got more specific: "If you send spam, put 'spam:' at the _beginning_ of the subject line." But then the Freedonian FTC got a visit from the Sylvanian Ambassador, who said this clashed with his country's requirements under the Marx Doctrine. Apparently they have to put the string "WATCH OUT! THE CONTENTS OF THIS MESSAGE ARE SUSPECT!" at the beginning of the subject line 💀

so the re-promulgation got rescinded, more experts were called in, and a new regulation came out: "Put it as close to the beginning of the subject line as you can, modulo any requirements by other governments." John Doe looked at this, scratched his head, and came up with a clever little hack 🧠 He picked the ISO [8859-8] character set for Hebrew and spelled out the letters ":" Mem Alef Pe Samech:

Subject: =?iso-8859-8?q?=f1=f4=e0=ee=3a?=

the problem is that some receivers get an error message because they don't have Hebrew installed on their systems. Others get a cryptic indicator of a missing character set, like "[?iso-8859-8?]" 🥴

the FTC called a summit of leading thinkers, and the regulation got amended to read "but don't use languages that go from right to left or up and down instead of plain old left to right." Needless to say, the Freedonian League for the Defense of Linguistic Diversity absolutely roasted that proposal, and it was killed really quickly 💅

the commission kept doing the cycle of re-promulgation and refinement, but ultimately every version still had either a loophole, objectionable requirements, or violations of the relevant RFCs. 😩

4. Subjects are For Humans, Not Labels 🎀

okay this part is the real tea. using an unknown character set, or a super long subject line, are just two examples of how people can dodge labeling requirements. to write a regulation with zero ambiguity, it would have to be extremely complex just to block loopholes like these 🌀

drafting the regulations is one issue, but there's another one too. subject lines are used for, as [RFC2822] says, a "short string identifying the topic of the message." 🦋

any labeling rule has to compete with all the other words in the subject, and that mixing of purposes makes it really hard for a machine to filter out messages at the direction of the user. for example, if you go looking for the "@" symbol, per the Korean law, you have to check that this symbol isn't a legit part of a legit message 😵‍💫

it's not just that multiple labeling requirements compete with legitimate subject lines. there's also no easy way for the sender of a legitimate message to add other labels that tell the recipient that, even though the message might have a required label, it's actually something the user might want to see, based on something like a prior relationship. 🫶

even if you only think about the sender, it's really hard to write a loophole-free way of putting a specific label in a specific place. and even if we could control what the sender does, it's a sad fact of life that other agents can also change the subject line. for example, mailing list management software and even personal email filtering systems will often "munge" the subject line to add stuff like the name of a mailing list, or the fact that a message comes from a certain group of people. these transformations have long been generally accepted as potentially harmful [RFC0886], and they're still being discussed, which is outside the scope of this document (see [Koch] and [RFC3834]) 🌸

the Subject: field is currently overloaded. it's become a handy spot for all kinds of agents to try to insert information. because of that overloading, it's a bad place to demand a mandatory label, since that label is unlikely to "rise to the top" and be noticed by the reader or even by the mail-filtering software that checks the mail before the user does 👀 people like [Moore-1], [Lessig], and [Levine] have pointed out the difficulty of implementing subject line labeling without extra steps. and honestly the problem is a general one. Keith Moore listed seven good reasons why tags of any sort in the Subject: field have potential problems 🧚

  1. The Subject: field space is not strictly limited, and long fields can be folded.
  2. PDAs, phones, and other devices and software have only limited space to display the Subject: field.
  3. A variety of different kinds of labels, like "ADV:" and "[Mailing List Name]", compete for scarce display space.
  4. There are conflicting legal requirements from different jurisdictions.
  5. There's a conflict between human use of the Subject: field and use of that field for filtering and filing:
    • Machine-readable tokens interfere with human readability.
    • Representation of human-readable text was not designed with machine interpretation in mind and, thus, does not have a canonical form.
  6. Lack of support in a few existing mail readers for displaying information from elsewhere in the message header (e.g., from newly-defined fields), along with familiarity, motivates additional uses of the Subject:, further compounding the problem.
  7. Any text-based tags added or imposed by outside parties (i.e., those that are not the sender or recipient of the message) will not be reliably meaningful in the recipient's language. 🌍

Source: [Moore-2].

5. Solicitation Class Keywords 🍓

okay so [RFC3865] defines the "solicitation class keyword," which is an arbitrary label that can be attached to an electronic mail message and carried by the ESMTP mail service, as defined in [RFC2821] and related documents. these keywords are formatted like domain names, but backwards 🔄 for example, the registrant of "example.com" might pick a solicitation class keyword like "com.example.adv" that could go in a No-Solicit: header or in a trace field. anybody with a domain name can define one, and anybody sending a message can use any solicitation class keyword that has been defined by themselves or by others. 💜

this memo argues that the No-Solicit: approach is either a superior alternative or a necessary complement to Subject: field labeling requirements, and here's why:

  • You can specify very precisely what a label should be and where it should go using the No-Solicit: header, which is designed specifically for this purpose. 🎯
  • The sender of a message can add extra solicitation class keywords to help tell the message apart. For example, if the "Freedonian Direct Marketing Council" wanted to form a voluntary consortium of direct marketers who follow certain practices, they could specify a keyword (e.g., org.example.freedonia.good.spam) and educate the public to set their filters to receive these types of messages. ✨
  • Message Transfer Agents (MTAs) may insert solicitation class keywords in the received: trace fields, which gives recipients more tools for filtering messages. 🔥
  • A recipient can also define a solicitation class keyword, which is a tool that lets them give friends and correspondents a "pass key," so the recipient's mail filtering software always lets through messages containing that keyword 🫶

as you can see, the solicitation class keyword approach is flexible enough to be a tool for government-mandated labeling and for other purposes too. iconic 👑

most modern email software gives users a bunch of filtering tools. for example, the popular Eudora program lets a user specify the name of a message header, the desired match (like a wild card or regular expression, or just a phrase to match), and an action to take (like moving the message to a particular folder, sounding an alarm, or even automatically deleting messages with harmful content such as viruses). there's one popular email reader that only allows filtering on selected fields, like To:, From:, or Subject:, but that program is the exception to the rule 🙄

in summary, for senders and receivers of email, using the No-Solicit: mechanism would be simple to understand and use. for policy makers, it would be extremely simple to specify the format and placement of the solicitation class keyword. needless to say, how to define which classes of messages are subject to such a requirement, and how to enforce it, are beyond the scope of this discussion 🌈

6. Security Considerations 🚨

this part is serious, bestie, so pay attention 🥺

the use of labels in the Subject: field gives users and policy makers an unwarranted illusion that certain classes of messages will be "flagged" correctly by the MUA of the recipient. because it's so hard to specify requirements for labels in the Subject: field in a precise, unambiguous way, it's hard for the MUA to systematically identify labeled messages, and this leads to both false positive and false negative indications 💀

on top of that, conflicting labeling requirements from policy makers, plus other current practices that use the Subject: for a variety of purposes, make that field "overloaded." to meet these conflicting requirements, software designers and bulk mail senders resort to a bunch of tactics, some of which may violate fundamental requirements of the mail standards, like the practice of an intermediate MTA inserting various labels into the Subject: field. these practices increase the likelihood of non-compliant mail messages and, thus, threaten interoperability between implementations. 😭🔥

7. Recommendations ✨

okay so this section is the RFC's big group-chat moment 💅 it makes three recommendations, and they're kind of a chain of "okay but what if" 🙈

  1. there is seriously widespread skepticism in the technical community that labels of any sort will work 😭 like, labels should probably be avoided because they're ineffective at best 💀
  2. BUT despite all that skepticism in point 1, over 36 states in the U.S. and 27 countries have passed anti-spam laws, and a lot of them require labels [Sorkin] 📜 so if labels are gonna happen anyway, there's a pretty broad consensus in the technical community that they should NOT go in the Subject: field and should go in a designated header field instead 🎀
  3. and if, even after points 1 and 2, someone decides to mandate labels in the Subject: field anyway 🫠 then a complementary requirement to use the No-Solicit: header should also get added 🦋

8. Acknowledgements 🫶

the author wants to thank these amazing people for their helpful suggestions and reviews of this document: Joe Abley, Harald Alvestrand, Elwyn Davies, Alain Durand, Frank Ellermann, Ted Hardie, Tony Hansen, Scott Hollenbeck, Peter Koch, Bruce Lilly, Keith Moore, Pekka Savola, and Mark Townsley 💖 literally the dream team 👑

9. References 📚

9.1. Normative References

[IANA]     IANA, "Registry of Official Names for Character Sets That
           May Be Used on the Internet", February 2004,
           <http://www.iana.org/assignments/character-sets>.

[RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
           Part Three: Message Header Extensions for Non-ASCII Text",
           RFC 2047, November 1996.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
           Word Extensions: Character Sets, Languages, and
           Continuations", RFC 2231, November 1997.

[RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
           April 2001.

[RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
           April 2001.

[RFC2978]  Freed, N. and J. Postel, "IANA Charset Registration
           Procedures", BCP 19, RFC 2978, October 2000.

[RFC3066]  Alvestrand, H., "Tags for the Identification of
           Languages", BCP 47, RFC 3066, January 2001.

[RFC3865]  Malamud, C., "A No Soliciting Simple Mail Transfer
           Protocol (SMTP) Service Extension", RFC 3865,
           September 2004.

9.2. Informative References

[8859-1]   International Organization for Standardization,
           "Information technology - 8-bit single byte coded graphic
           - character sets - Part 1: Latin alphabet No. 1, JTC1/
           SC2", ISO Standard 8859-1, 1987.

[8859-8]   International Organization for Standardization,
           "Information Processing - 8-bit Single-Byte Coded Graphic
           Character Sets, Part 8: Latin/Hebrew alphabet",
           ISO Standard 8859-8, 1988.

[Colorado] Sixty-Second General Assembly of the State of Colorado,
           "Colorado Junk Email Law", House Bill 1309, June 2000,
           <http://www.spamlaws.com/state/co.html>.

[Doe]      Frank Capra (Director), "Meet John Doe", IMDB Movie
           No. 0033891, 1941, <http://us.imdb.com/title/tt0033891/>.

[Duck]     The Mark Brothers, "Duck Soup", IMDB Movie No. 0023969,
           1933, <http://us.imdb.com/title/tt0023969/>.

[Florida]  The Florida Bar, "Rules of Professional Conduct", 2005,
           <http://www.flabar.org/divexe/rrtfb.nsf/
           WContents?OpenView&Start=1&Count=30&Expand=4.8#4.8>.

[KISA]     Korea Information Security Agency, "Korea Spam Response
           Center -- Legislation for Anti-Spam Regulations: Mandatory
           Indication of Advertisement", 2003,
           <http://www.spamcop.or.kr/eng/m_2.html>.

[Koch]     Koch, P., "Subject: [tags] Considered Harmful", Work in
           Progress, November 2004.

[Korea]    National Assembly of the Republic of Korea, "Act on
           Promotion of Information and Communication and
           Communications Network Utilization and Information
           Protection of 2001", 2001, <http://www.mic.go.kr/eng/res/
           res_pub_db/res_pub_mic_wp/2003/whitepaper2003/in3_7.htm>.

[Lessig]   Lessig, L., "How to unspam the Internet", The
           Philadelphia Inquirer, May 2003, <http://www.philly.com/
           mld/inquirer/news/editorial/5778539.htm?1c>.

[Levine]   Levine, J., "Comments In the Matter of: REPORT TO CONGRESS
           PURSUANT TO CAN-SPAM ACT", Federal Trade Commission,
           Matter No. PO44405, February 2004, <http://www.ftc.gov/
           reports/dneregistry/xscripts/dne040226pm.pdf>.

[Moore-1]  Moore, K., "Individual Comment of Mr. Keith Moore Re:
           Label for E-mail Messages", Federal Trade Commission of
           the U.S., NPRM Comment RIN 3084-AA96, February 2004, <http
           ://www.ftc.gov/os/comments/adultemaillabeling/
           040216moore.pdf>.

[Moore-2]  Moore, K., "E-mail Message to the Author and the IESG",
           March 2005.

[RFC0886]  Rose, M., "Proposed standard for message header munging",
           RFC 886, December 1983.

[RFC3834]  Moore, K., "Recommendations for Automatic Responses to
           Electronic Mail", RFC 3834, August 2004.

[Sorkin]   Sorkin, D., "http://www.spamlaws.com/", 2005,
           <http://www.spamlaws.com/>.

[Stooges]  The Three Stooges, "Heavenly Daze", IMDB Movie
           No. 0040429, 1948, <http://us.imdb.com/title/tt0040429/>.

[US]       United States Congress, "The Controlling the Assault of
           Non-Solicited Pornography and Marketing Act of 2003 (CAN-
           SPAM Act of 2003)", Public Law 108-187, 117 STAT. 2699, 15
           USC 7701, December 2003, <http://frwebgate.access.gpo.gov/
           cgi-bin/getdoc.cgi?dbname=108_cong_public_laws
           &docid=f:publ187.108.pdf>.

Author's Address 🎀

Carl Malamud
Memory Palace Press
PO Box 300
Sixes, OR  97476
US

EMail: carl@media.org

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔍

the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available, and it doesn't claim to have made any independent effort to identify any such rights 🤷‍♀️ info on how rights work for RFC documents is in BCP 78 and BCP 79.

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

the IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard 🌈 send that info to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society 💜

📦 where this page comes from