Youvecottmail

The craft, infrastructure, and history of email and newsletters — read through dated artifacts.

List-Unsubscribe: RFC 2369 and the Header That Turned Leaving Into a Protocol

There is a line in some email messages that you will never see in the body. It sits in the header section, above the first paragraph, in the same structural layer as From: and Subject:, and it looks like this:

List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>

That is the example given in RFC 2369, published in July 1998 and written by G. Neufeld and J. Baer. The document is titled, with the flat earnestness of its era, The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields. It is the artifact I want to read closely here, because it marks the moment when leaving a publication stopped being a sentence you wrote in the footer and became a field the container could carry.

The argument is not that the header is elegant. It is that the header is a design decision about the reader’s exit, made at the level of format rather than copy, and that the history of that decision — from 1998 to the one-click revision of 2017 — shows how much of editorial independence lives in the parts of the message the writer does not compose.

What the header displaced

Before RFC 2369, mailing list commands were prose. To leave a list managed by Majordomo or Listserv, you sent a message to a command address with a line like unsubscribe listname in the body, and you learned this from instructions buried somewhere in a welcome message or a footer. The commands varied by list manager, the addresses varied by list, and the whole apparatus was, in the RFC’s own words, “cryptic and varied.”

RFC 2369 proposed to move the command out of the body and into the header, where a mail client could read it and offer it as a button. The abstract is explicit about the intent: “By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands.”

That sentence is worth sitting with. The RFC is not primarily about making it easier for senders to manage lists. It is about making it possible for clients to present list functions in a consistent way, so that the reader does not have to learn a different dialect for every publication they subscribe to. The command becomes a property of the message, and the interface becomes a property of the client.

The design choice: URLs as meta-syntax

RFC 2369 defines six header fields. Three are core: List-Help, List-Subscribe, and List-Unsubscribe. Three are secondary: List-Post, List-Owner, and List-Archive. Each field typically contains a URL, usually a mailto: URL, that either locates information or performs the command directly.

The choice of URL syntax was deliberate. The RFC’s appendix explains that a single header field carrying a new meta-syntax was rejected because “every additional layer of complexity and newness reduces the likelihood of actual implementation.” URLs were already widely understood, already supported by clients, and already extensible. The header would inherit that.

The syntax also allowed for fallbacks. A field could contain multiple comma-separated URLs, ordered left to right by preference, and the client would use the leftmost protocol it supported. The RFC’s example for List-Unsubscribe shows this:

List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>, <mailto:list-request@host.com?subject=unsubscribe>

The web URL comes first, the mailto second. A client that could open a browser would use the first; a client that could only send mail would use the second. The RFC recommends that senders include a mailto command “in addition to any other protocols used, in order to support users who do not have access to non-mail-based protocols.” The preference order is a bet on universality: the exit should work even for the reader whose only tool is email.

Why the header is a container argument

Here is the part that matters for writers. The List-Unsubscribe field lives in the header section, which RFC 5322 defines as the sequence of fields that precedes the optional body, separated from it by an empty line. The header is not the place where you make your argument or set your tone. It is the place where the message declares what it is and what can be done with it. Putting the unsubscribe command there rather than in the body means the command survives whatever the writer does with the content. You can redesign the footer, change the template, rewrite the closing paragraph, and the exit is still there, in the same structural layer as the sender’s identity.

This is what I mean by the container disciplining the content. The format decides what the reader can do, and it does so before the reader has read a word. A newsletter whose only exit is a link at the bottom of a long issue has made leaving a function of the reader’s patience and scroll position. A newsletter that emits List-Unsubscribe has made leaving a function of the message’s structure, available to the client regardless of what the body says.

There is a further consequence. Because the header is read by the client, the client decides how the exit is presented. The sender supplies the command; the interface supplies the affordance. That is a different distribution of editorial control than a footer link, where the sender controls the placement, the wording, and the surrounding copy. The header cedes some of that control to the container, and in exchange the exit becomes consistent across publications.

The failure mode

For nearly two decades, that was the arrangement. Then the container started reading the URLs.

RFC 8058, published in January 2017 and written by J. Levine and T. Herkula, opens with the problem in plain terms: “The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.” Anti-spam software, scanning messages for links, would fetch the unsubscribe URL automatically. The sender could not tell whether the request came from a person or a crawler. So senders added confirmation pages: a live reader would see the page and click through; an automated system would not. The RFC is blunt about the cost: “That makes the unsubscription process more complex than a single click.”

This is a container-side problem that had been patched on the content side. The confirmation page asked the reader to do extra work because the protocol could not distinguish a human from a bot. The better fix, RFC 8058 argues, was not a better landing page but a new header and a narrower contract.

The fix and its cost

RFC 8058 introduces List-Unsubscribe-Post, a second header whose only permitted value is List-Unsubscribe=One-Click. A sender that wants to offer one-click unsubscription places one List-Unsubscribe header containing an HTTPS URI and one List-Unsubscribe-Post header with that single key/value pair. The receiver performs an HTTPS POST to the URI, sending the key/value pair as the request body. The POST is the signal that a human consented; a GET, which is what a crawler would issue, does not complete the unsubscribe.

The contract is tighter than RFC 2369’s, and the tightness is the point. Several requirements are worth naming because they show how much the container now has to guarantee:

  • The message must carry a valid DKIM signature covering at least the List-Unsubscribe and List-Unsubscribe-Post headers. If the signature is missing, the receiver “SHOULD NOT offer a one-click unsubscribe for that message.” The exit is only trustworthy if the message carrying it is authenticated.
  • The POST request must not include cookies, HTTP authorization, or any other context information. The unsubscribe operation is “logically unrelated to any previous web activity,” and context information could link the exit to the reader’s browsing history.
  • The sender must not return an HTTPS redirect, because redirected POSTs have historically not worked reliably and many browsers have turned them into GETs.
  • The URI should contain an opaque or hard-to-forge component, and the server should verify it, to deter attacks that abuse unsubscribe links.
  • The receiver must not perform the POST without user consent, though how consent is obtained is outside the specification.

There is also a constraint that reads almost like a design principle: because there is no provision for extra POST arguments, all the information needed to identify the recipient and the list must be encoded in the URI. One-click “has no way to ask the user what address or from what list the user wishes to unsubscribe.” The exit cannot ask a question. It can only act.

RFC 8058 is careful to say that it does not update RFC 2369, so the use of List-Unsubscribe for anything other than one-click is unchanged. The mailto command still works. The web URL with a confirmation page still works. What the new header adds is a way to signal that a particular URI will accept a POST and complete the unsubscribe without further interaction.

What the two documents disagree about

Read together, the two RFCs are a record of a changed bet about what “simple” means. RFC 2369 preferred mailto because it was universal: it worked for readers with no web access, and it did not depend on a browser. RFC 8058 requires an HTTPS URI for one-click because the problem it is solving is not access but automation: a mailto command cannot be accidentally triggered by a crawler fetching a link, but it also cannot be completed without the reader composing and sending a message. The one-click path trades the universality of mail for the immediacy of a POST.

Neither choice is wrong. They are answers to different failure modes. RFC 2369 was optimizing against the reader who could not use the web. RFC 8058 was optimizing against the software that used the web too eagerly. The lesson is not that one protocol superseded the other but that “the simplest exit” is always relative to the failure you are trying to prevent.

The practical test for writers

If the container disciplines the content, then the unsubscribe path is part of the editorial container, and it deserves the same scrutiny as the subject line or the opening paragraph. The test I would propose is not “do I have an unsubscribe link” but a set of questions about format:

  • Can a reader leave in one action, from the client, without opening a browser?
  • Does the exit work if the reader’s only tool is email?
  • Does the exit require the reader to log in, confirm an identity, or explain a reason?
  • Is the exit present in the header, where the client can find it, or only in the body, where the reader has to scroll for it?

Consider a clearly hypothetical example. A small newsletter offers only a footer link that leads to a page requiring a login to cancel. The reader who wants to leave must find the link, open a browser, remember or reset a password, and navigate a settings page. The same newsletter adds a List-Unsubscribe header with a mailto command. Nothing in the issue changes. The reader’s cost of leaving drops from several steps to one message. The editorial voice is identical; the format is not.

Or consider the one-click case. A publication that emits List-Unsubscribe with an HTTPS URI but no List-Unsubscribe-Post header is offering a link that, in a client that supports one-click, may still require a confirmation page. Adding the second header and signing both is a format decision that changes what the reader can do without changing a word of the content. It is also a decision that requires the sender to maintain a POST endpoint, verify an opaque token, and keep the DKIM signature valid — infrastructure work that is invisible in the issue but constitutive of the reader’s experience of leaving.

Why this is an editorial question

The inbox is a site of editorial independence, and independence includes the right to leave. A publication that makes leaving easy is making a claim about its own confidence: it expects to be read because the reader chooses to read it, not because the exit is hard to find. That claim is made in the header, not in the footer. It is made by the presence of a field the reader never sees, in a format the reader never inspects, and it is enforced by a client that decides how to present the exit.

This is the sense in which the container disciplines the content. The header does not argue with the reader. It does not persuade. It simply makes a structural commitment: the command to leave is part of the message, available to the client, and not dependent on the writer’s prose. A format that makes leaving easy is a format that makes the writing trustworthy, because it removes the suspicion that the reader is being kept by inconvenience rather than convinced by argument.

The artifact is one line. It has been revised once, in 2017, to add a second line and a POST. It will probably be revised again. What will not change is the principle the two RFCs share: the exit belongs in the container, and the container is where the reader’s autonomy is either respected or quietly eroded. Writers who treat the inbox as a place for deliberate format choices should read their own headers before they read their own footers.

Questions readers ask

Does RFC 8058 replace RFC 2369?

No. RFC 8058 states explicitly that it does not update RFC 2369, so the use of List-Unsubscribe for anything other than one-click is unchanged. The mailto command and the web URL with a confirmation page still work as described in 1998. RFC 8058 adds a way to signal that a particular HTTPS URI will accept a POST and complete the unsubscribe without further interaction.

Can I offer both a mailto and an HTTPS URI?

Yes. RFC 8058 says the List-Unsubscribe header must contain one HTTPS URI and may contain other non-HTTP/S URIs such as MAILTO:. The RFC’s own complex example shows a mailto URI followed by an HTTPS URI. The one-click POST applies to the HTTPS URI; the mailto command remains available for clients that use it.

Why does the message need a DKIM signature?

RFC 8058 requires a valid DKIM signature covering at least the List-Unsubscribe and List-Unsubscribe-Post headers. If the signature is missing, the receiver should not offer one-click unsubscribe. The signature ties the exit to an authenticated message, so a forged header cannot be used to trigger unsubscriptions on someone else’s behalf.

Why can’t the unsubscribe page just ask a confirmation question?

It can, and RFC 2369’s web URL path still allows it. But RFC 8058 was written because confirmation pages made the process more complex than a single click, and because automated systems cannot answer a confirmation question. The one-click path exists for cases where the unsubscribe must complete without a human reading a page — for example, when a mail system processes a junk report or closes an abandoned mailbox.

Sources

The Mugshot Board as a Container: Reading the ‘Got Too Silly’ Bird Shirt

On a standard t-shirt listed in the US marketplace on 14 October 2026, the printed artwork reads GOT TOO SILLY in capital letters above a white, goose-like bird. The bird wears an orange prison uniform and holds a black mugshot board. The phrase sits at the top like a headline; the bird sits below it like the subject of a photograph. The board is blank in the visual observation, which is the first thing I noticed and the thing I keep returning to.

This is not a complicated image. It is a joke compressed into two visual registers: a caption and a portrait. But the more I look at it, the more it seems to be about the format of a confession — the way a mugshot board turns a person into a record, and the way a caption turns a record into a punchline. The shirt is not asking you to laugh at a bird. It is asking you to notice the mismatch between the seriousness of the apparatus and the silliness of the charge.

The phrase got too silly is a kind of confession, but it is also a kind of category error. You do not usually get arrested for silliness. You get arrested for things that have names in a penal code. The joke works because the bird has been processed by a system that expects a crime, and the only crime available is a temperament. The mugshot board is the container: it holds a name, a date, a number, a charge. Here it holds nothing visible, which makes the bird’s expression — whatever it is — do all the work. The board is a form waiting to be filled, and the joke is that the form has already been filled by the caption above it.

I have been thinking about this shirt in the context of correspondence because a mugshot is a kind of letter. It is a standardized document that says: this is who I am, this is what I did, this is the date. It is addressed to an institution, not a person, but it has the same basic structure as a form letter — a header, a body, a signature. The bird’s board is the header. The bird is the body. The caption is the subject line. And the whole thing is a joke about what happens when a playful creature is forced into an official format.

That is the argument I want to make about this artwork: it is a small essay on the way containers discipline content. The orange uniform and the black board are the container. The white bird is the content. The phrase GOT TOO SILLY is the editorial framing — the headline that tells you how to read the image. Without the phrase, the bird in the uniform would be a slightly sad image. With the phrase, it becomes a joke about the gap between the charge and the creature. The container does not just hold the content; it changes what the content means.

This is the same problem I write about every week in the context of email. A plain-text message and an HTML newsletter can contain the same words, but the container changes the reading. A subject line is a caption. A header is a mugshot board. The format tells you what kind of attention to pay. The bird shirt makes that visible because the container is so literal: a board, a uniform, a caption. You can see the discipline happening.

The shirt is sold by Quirky Cotton Collective under the title Got Too Silly Funny Bird Mugshot Prison Meme. If you want to see the listing, it is here: Got Too Silly Funny Bird Mugshot Prison Meme. I am not going to tell you how it fits or how it wears, because I have not worn it. I am telling you what the artwork does, because the artwork is the thing I can see.

Editorial note: This publication and Quirky Cotton Collective share an owner.

What I keep coming back to is the blank board. A mugshot board is usually a place for facts: name, date, booking number. Here it is empty, or at least unreadable in the observation. That emptiness is the joke’s engine. The bird has been processed, but the record is incomplete. The caption supplies the missing charge: too silly. The container is official; the content is absurd. And the viewer completes the form by laughing.

That is what a good format does. It gives you a place to put the joke. The bird shirt is a reminder that the container is never neutral — not in a mugshot, not in an email, not in a t-shirt. The next time you write a subject line, think about the board. It is holding more than you think.

The Dashed Circle and the Solid Ball: Reading the ‘I Had Potential’ Shirt as a Diagram of What Didn’t Happen

The shirt arrived as a flat image on a listing page, dated 14 October 2026: white capitals reading I HAD POTENTIAL above a white curved ramp. At the upper left ledge sits a dashed empty circle. At the lower right flat ledge rests a solid white ball. The ramp curves downward, not as a straight diagonal but as a gentle, accelerating slope. The phrase is past tense. The diagram is present tense. That mismatch is the whole joke, and it is worth taking seriously.

I am not here to sell you a shirt. I am here to read one. The object in question is the I Had Potential shirt from Quirky Cotton Collective, and what interests me is not the slogan but the drawing beneath it. The drawing is a physics diagram, or a cartoon of one: a ball on a ramp, a dashed circle where the ball used to be. The dashed circle is the ghost of the starting position. The solid ball is the resting place. The phrase above says potential, and the diagram shows what happened to it.

In physics, potential energy is stored energy — the energy an object has because of its position. A ball at the top of a ramp has more potential energy than a ball at the bottom. The higher the ledge, the more potential. The dashed circle at the upper left is not just an absence; it is a marker of where the energy was. The solid ball at the lower right is where the energy went. The shirt does not say the ball rolled down. It shows it. The phrase says I had potential. The diagram says and then gravity happened.

This is a more precise joke than it first appears. The common reading is sarcastic: the wearer is confessing that their potential has been squandered, that they have settled, that the dashed circle is the person they could have been. That reading is available, and it is funny. But the diagram complicates it. The ball is not broken. The ramp is not a cliff. The ball has simply moved from a position of higher potential to a position of lower potential, which is what balls do. The dashed circle is not a failure; it is a starting condition. The solid ball is not a disappointment; it is a result.

What I find interesting is the choice of a curved ramp rather than a straight diagonal. A straight diagonal would suggest a simple slide, a one-step decline. A curve suggests acceleration — the ball speeds up as it descends, which is what happens on a real ramp under gravity. The curve makes the diagram feel observed rather than generic. It also makes the descent look inevitable. The ball did not choose to roll. The ramp was shaped that way. The phrase I had potential becomes, in that light, not a confession of laziness but a statement about initial conditions. You can have potential and still end up at the bottom of the ramp. That is not a moral failure. That is physics.

The dashed circle is the most interesting element. It is empty, which means it is a placeholder for something that is no longer there. In a physics diagram, a dashed outline often marks a previous position or a predicted position. Here it marks the past. The solid ball marks the present. The shirt is a two-frame animation compressed into a single image: here is where it was, here is where it is. The phrase above supplies the tense. Had is past perfect. The potential is over. The ball is still rolling, or has stopped, but the potential is gone.

I keep thinking about the word potential as it is used in ordinary life. We say a student has potential. We say a manuscript has potential. We say a newsletter has potential. The word is almost always forward-looking, a prediction about what something might become. The shirt uses it in the past tense, which is a small act of violence against the word’s usual direction. I had potential means the prediction has been settled. The dashed circle is the prediction. The solid ball is the settlement. The shirt is a diagram of a closed question.

There is a version of this shirt that would be merely sad. The dashed circle would be a ghost, the solid ball a failure, the phrase a confession. But the drawing is too clean for that. The ramp is a single white line. The ball is a single white circle. The dashed circle is a single white outline. There is no shading, no debris, no sign of damage. The diagram is neutral. It does not mourn the dashed circle. It simply records it. That neutrality is what makes the shirt funny rather than bleak. The joke is not that the ball fell. The joke is that the fall was diagrammed.

I am aware that I am overreading a t-shirt. That is the job. The shirt is a piece of visual language, and visual language rewards attention. The phrase I had potential is a common enough sentiment, but the diagram beneath it is specific. The dashed circle at the upper left, the solid ball at the lower right, the curved ramp between them — these are choices. A different designer might have used a straight arrow, or a dotted line, or a stick figure. This designer used a physics diagram. That choice makes the shirt a small essay about determinism, or about the difference between what is stored and what is spent.

The shirt is also, incidentally, a useful reminder for anyone who writes for a living. Potential is a starting condition. It is not a guarantee. The ball on the ramp has potential energy, but it also has a slope, and the slope will win. The dashed circle is where you began. The solid ball is where you are. The phrase above is the story you tell about the difference. You can tell it as a confession, or you can tell it as a diagram. The shirt does both.

Editorial note: This publication and Quirky Cotton Collective share an owner.

The Boundary Line You Never See: Reading MIME’s Multipart Container as an Editorial Decision

There is a line in every HTML newsletter you have ever received that you have never read. It looks like this:

--=_Part_84721_1938475620.1698765432100

It appears again between the parts, and once more at the end with two trailing hyphens. Your mail client strips it out before rendering. Most senders never look at it. And yet that line — the MIME boundary — is the seam at which the plain-text-or-HTML decision actually gets made. Everything upstream of it is a template setting. Everything downstream is a rendering outcome. The boundary is where the writer’s intention is either declared or defaulted.

RFC 2046, published in November 1996, is the document that gave us this structure. It is not a style guide, and it was not written for people who compose newsletters. But read as a writer’s document, it says something useful and slightly uncomfortable: the container disciplines the content. If you want to make deliberate format choices rather than inherit them, it helps to know what the container is actually doing.

What RFC 2046 actually specifies

The specification defines multipart as “data consisting of multiple entities of independent data types,” and among its initial subtypes it names alternative “for representing the same data in multiple formats” (RFC 2046, §3). That is the whole of the mechanism in one sentence. A message can carry more than one rendition of the same content, and the container declares which renditions exist.

Two other definitions in the same document matter for anyone who writes. First, text/plain is described as “plain text containing no formatting commands or directives of any sort,” intended to be displayed “as-is,” requiring “no special software … aside from support for the indicated character set” (§4.1). Second, the default character set, assumed when no charset parameter is given, is US-ASCII (§4.1.2).

Those two facts together explain a great deal of what goes wrong in the inbox. A plain-text part is not a degraded version of the HTML part; the spec treats it as a complete, self-sufficient rendition. And a message that does not declare its character set is, by the letter of the standard, claiming to be US-ASCII — a claim that most contemporary newsletters cannot honestly make.

The container is recursive, and that is the point

RFC 2045, the companion document published the same month, notes that the definitions of message, entity, body part, and body are “clearly circular,” and that this is “unavoidable, since the overall structure of a MIME message is indeed recursive” (§2.6). A part can contain parts. A newsletter with a plain-text body, an HTML body, and an inline logo is not one thing with attachments; it is a tree of containers, each with its own declared type.

This is where platform defaults become visible. When a sending tool decides on your behalf that your message is multipart/alternative nested inside multipart/related nested inside multipart/mixed, it has made three editorial decisions for you: that the text and HTML versions are alternatives to each other, that the images belong to the HTML document rather than standing alone, and that anything else is an independent attachment. Those are reasonable defaults. They are still decisions, and you can read them in the headers.

The practical audit is simple. Open the raw source of a message you have sent — most clients offer a “show original” or “view source” command — and read the Content-Type lines from the top down. Each one names a container and its boundary. The nesting you see is the structure your tool chose. Whether it matches the structure you intended is a separate question, and one only you can answer.

Why the boundary disciplines the content

Here is the constraint that makes the boundary an editorial device rather than a technical formality. The boundary string must not appear inside any of the encapsulated parts. If it does, a parser will split the message at the wrong place, and the reader will see fragments of markup or truncated prose.

This is a structural argument, not a quoted rule from the passages above, but it follows directly from how delimiters work: a delimiter that can occur in the data cannot reliably delimit the data. The consequence for a writer is that you cannot compose the parts in isolation and hope they fit. You have to know the whole message before you write any part of it. The container asks you to hold the entire piece in view — what it says, what it shows, what it carries — and then to divide it deliberately.

That is the opposite of how most newsletter tools work. They invite you to write in a visual editor, then generate a plain-text version by stripping tags. The plain part becomes a residue of the HTML part. The spec permits this. The craft does not recommend it.

Writing the pair, not the fallback

If the plain-text part is written first and written completely, the HTML part becomes an enhancement of an already-finished piece. If the HTML part is written first and the plain part generated from it, the plain part is whatever survived the stripping. Both are legal MIME. Only one of them treats the reader who sees plain text as a reader rather than a failure mode.

A workable sequence, offered as recommendation rather than as anything the RFCs prescribe:

  1. Draft the plain part as the argument. Write it as you would write a letter. Complete sentences, real paragraphs, links written out in full where they carry meaning. If the piece does not work here, it does not work.
  2. Treat the HTML part as a second setting of the same text. Headings, emphasis, and layout should clarify the argument, not replace it. If a sentence only makes sense next to an image, the sentence needs rewriting.
  3. Declare the character set explicitly. RFC 2046 makes US-ASCII the default in the absence of a charset parameter (§4.1.2). If your text contains anything outside that range — an em dash, a curly quote, a name with an accent — the default is a false statement about your content. RFC 2049 requires conformant agents to be able to send at least text/plain messages “with the character set specified with the charset parameter if it is not US-ASCII” (§2). Declaring it is a small act of editorial responsibility: it tells the reader’s software what you intended instead of asking it to guess.
  4. Keep the tree as shallow as the message needs. RFC 2045 records that the working group favored “compatibility … over elegance” (§1). That is a useful disposition for a writer, too. A two-part alternative is often enough. Nesting earns its place only when the message genuinely has independent parts — an attachment that stands alone, an image that belongs to the HTML document.

What the history suggests about restraint

MIME was not invented in 1996. RFC 1521, published in September 1993, redefined message bodies “to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information,” and its authors note that MIME “was first defined and published as RFCs 1341 and 1342,” with RFC 1521 a “relatively minor updating” intended to supersede RFC 1341 (RFC 1521, §1). The 1996 documents are a revision of that work, not a fresh start.

What the revision added was not new ambition but clearer structure: the media type system, the conformance criteria in RFC 2049, the explicit statement that the mechanism was designed to be extensible and that the set of types and parameters would “grow significantly over time” (RFC 2046, §1). The designers expected the container to be stretched. They built it to stretch without breaking.

That expectation is worth holding onto. The multipart container is not a constraint to be worked around; it is a structure that anticipates variety. The question for a writer is not whether the format can hold what you want to say, but whether you have chosen the shape deliberately or accepted the one your tool supplied.

The seam is the decision

RFC 5322, the current Internet Message Format specification, is careful about its own scope: it “specifies a syntax only for text messages” and “makes no provision for the transmission of images, audio, or other sorts of structured data,” leaving the MIME series to describe those mechanisms (RFC 5322, §1.1). The header section and the body are separated by an empty line; everything above it describes the message, everything below it is the message. MIME lives in the headers, which means the format decisions are made before the first word of the body is read.

This is the quiet discipline of the container. The boundary line is invisible to readers, but it is the place where the writer’s choices about what the message is made of become fixed. A writer who can read a Content-Type header can see what a sending tool has decided on their behalf. That visibility is the precondition for making a deliberate choice instead of inheriting one.

The inbox is a site of editorial independence, but only for writers who know what their container is doing. The boundary is where that independence is either exercised or defaulted — one line, repeated between the parts, closing with two hyphens at the end.

Questions writers ask

Do I have to send both plain text and HTML?

No. RFC 2046 defines multipart/alternative as a way to represent the same data in multiple formats; it does not require that you use it. A plain-text-only message is a complete message. The choice is yours, and the spec does not rank the options.

What happens if my plain-text part is just a stripped version of the HTML?

Technically, nothing breaks. The message is still valid MIME. But the plain part will read as fragments — headings without context, links without destinations, sentences that referred to a layout that is no longer there. The reader who sees it is reading a residue, not a rendition.

Why does my character set matter if my client handles it automatically?

Because the default is US-ASCII (RFC 2046, §4.1.2), and a message that relies on the default while containing other characters is making a claim about itself that is not true. Declaring charset=utf-8 explicitly removes the ambiguity. RFC 2049 treats explicit charset declaration as part of conformance for non-US-ASCII text (§2).

How do I see what my sending tool actually produced?

Send yourself a test message and use your client’s “show original” or “view source” command. Read the Content-Type headers from the top. The nesting and the boundary strings you see are the structure your tool chose. Compare that to the structure you intended.

Is a deeper multipart tree better?

No. Depth should follow from the message’s actual parts, not from a template’s ambition. A shallow tree that matches the content is easier to read, easier to audit, and less likely to produce the kind of malformed nesting that confuses parsers.

The Cat in the Middle: Reading the ‘Cat Daddy’ Shirt as a Three-Part Sentence

The native garment preview for the Cat Daddy Feline Father Lover Pet Owner Funny Tee, observed on 14 October 2026, shows a dark shirt with light lettering arranged in two registers. On the upper line, a C and a T flank a cat silhouette. Beneath them, centered, sits the word Daddy. That is the whole design. No slogan, no secondary graphic, no date or location. The shirt is sold under the brand Quicky Cotton Collective, and the listing title calls it a feline father and pet-owner tee. The visual observation is narrower than the title, and the gap between them is the interesting part.

What the preview actually gives you is a rebus. The letters C and T are not abbreviations for anything the viewer has to look up. They are the first and last letters of the word cat, and the silhouette between them is the missing middle. Read across the top line and you get C–cat–T. Read down and you get Daddy. The shirt is not printing the phrase Cat Daddy so much as asking you to assemble it. The joke is completed by the viewer, not by the garment.

This is a small piece of typographic craft, and it is worth taking seriously as such. A three-letter word has been split into its two consonants and its vowel replaced by a picture. That is a very old move — the rebus predates movable type — but it is also a very specific one. It assumes a reader who will do the work. The shirt does not explain itself. If you glance at it and see C [cat] T without connecting the top line to the Daddy below, you get a fragment. If you read the two registers together, you get a phrase. The design rewards the second look.

I want to be careful about what that phrase means, because the retail title and the printed artwork are not the same claim. The title says feline father and pet owner. The artwork says C [cat] T Daddy. The phrase cat daddy is a term of endearment a person applies to themselves or accepts from someone else; it is not a statement about biology, custody, or household arrangement. The shirt does not depict a human father, a birthday, or a family role. It depicts a cat and a word. The rest is the wearer’s to supply, and the design leaves room for that supply.

That is a different kind of garment from the ones that announce an occasion. A Father’s Day shirt usually prints a date, a title, a list of names, or a joke about lawnmowers. It tells you what day it is. This shirt tells you what word you are. The distinction matters for how the object behaves in a wardrobe. An occasion shirt has a season; a phrase shirt has a register. You can wear C [cat] T Daddy on a Tuesday in February without explaining a holiday. The design’s compression is what makes that possible. It has no calendar in it.

The layout is doing more work than it first appears. The C and T sit at the same height as the cat’s ears, roughly, and the word Daddy is centered beneath the silhouette rather than beneath the whole top line. That centering is what makes the vertical reading possible. If Daddy were left-aligned under the C, the eye would read a column and the phrase would break. Because it is centered, the eye drops from the cat’s body to the word, and the two registers lock. The design is a small diagram of how a phrase can be held in two dimensions.

I have written before about shirts that use a period as a full stop and shirts that use an arrow to point at an accomplice. This one belongs to the same family of objects: a garment whose meaning is a piece of punctuation or a piece of layout rather than a sentence. The cat is a letter. The letter is a picture. The picture is a word. The word is a name. That chain is the whole design, and it is short enough to read in a mirror, which is the only test a shirt graphic really has to pass.

There is a temptation to overread the cat. I am not going to tell you what the cat is feeling, because the silhouette does not have a face. It is a shape — ears, head, body, tail — chosen to sit between two letters at a readable scale. That is a design constraint, not a characterization. The shirt is not about a specific cat, and the preview does not show one. It is about the word cat and the space where its middle should be. The silhouette is a placeholder that happens to be adorable, which is a useful property in a placeholder.

The phrase cat daddy itself is worth a note on register. It is affectionate and slightly self-mocking. It does not claim authority the way father might; it claims a relationship with an animal and a willingness to be a little silly about it. The shirt’s typography matches that register. The letters are light on dark, plain, not ornate. The cat is a silhouette, not an illustration. Nothing is shouting. The design is confident enough to leave the joke half-finished, which is the opposite of a novelty tee that explains itself twice.

If you are the kind of reader who keeps a notebook of type and layout, this shirt is a page from it. It is a demonstration of a principle: a phrase can be compressed into a diagram, and a diagram can be worn. The Cat Daddy Feline Father Lover Pet Owner Funny Tee is the object in question, and the design is the argument. The argument is that a word can lose its middle and still be legible, if the middle is replaced by something the reader already knows how to see.

What I like about it, finally, is that it does not ask the wearer to perform a role. It asks the wearer to be a reader. The shirt is a small test of whether you will connect the top line to the bottom line, and the reward for passing is a phrase that sounds like a name someone might actually call you. That is a better transaction than most garments offer. It is also, I think, the reason the design works as a piece of correspondence between the shirt and the person looking at it: it leaves a blank, and the blank is the point.

Editorial note: This publication and Quicky Cotton Collective share an owner. This is not an independent review.