Dash, Dash, Space: A Short History of the Email Signature Delimiter
Look at the bottom of almost any plain-text email or forum post with a signature attached, and just above the name and title there’s a small, easy-to-miss line: two hyphens and a space, sitting alone. It looks like a typo, or a stray fragment of markup. It is neither. It’s one of the oldest still-functioning conventions on the internet, and — unusually, for something this old and this informal-looking — it has a precise, documented origin that can be traced through specific standards documents, decades apart, written by named people.
This is a short companion to our longer history of the email signature, which covers the broader arc from .signature files to corporate brand assets. This piece is narrower: it’s about that one delimiter line, where it came from, and why it took an unusually strange route to becoming an official standard.
TL;DR: The -- (dash, dash, space) line that precedes most email and Usenet signatures was first formally specified in RFC 1849, an IETF document written by Henry Spencer in 1994 — but RFC 1849 wasn’t actually published as an RFC until March 2010, sixteen years later, by which point it had already been superseded by newer standards. In the meantime, it had become so universally adopted that the RFC Editor’s office itself described it as “the best-known Internet Draft (n)ever published.” The convention was formally folded into email’s text/plain format standard, RFC 3676, in 2004, where it’s defined precisely enough that the trailing space is not optional. The whole sequence is a small but genuine piece of internet history.
Before the delimiter: Usenet’s original standard had no rule for this
Usenet — the distributed bulletin-board system that predates the World Wide Web — got its first formal article format standard in December 1987, in RFC 1036, written by Mark Horton and Rick Adams. RFC 1036 standardised how Usenet messages were structured: headers, line lengths, character sets. It’s the document that made it possible for different newsreader software, running on different systems, to interoperate.
What RFC 1036 does not contain is any specification for a signature delimiter. By the early 1990s, plenty of posters were appending a few lines of personal sign-off to their messages, and a rough convention — two hyphens followed by a space, on a line by itself, immediately before the signature — had started to spread informally among newsreader authors. But it existed the way most internet conventions of that era existed: as something people copied from each other’s software, not something written down anywhere official.
RFC 1849: the best-known Internet Draft never published
The document that actually nailed the convention down was RFC 1849, “Son of 1036”: News Article Format and Transmission, drafted by Henry Spencer as a successor to RFC 1036. It states the rule plainly:
“If a poster or posting agent does append a signature to an article, the signature SHOULD be preceded with a delimiter line containing (only) two hyphens (ASCII 45) followed by one blank (ASCII 32).”
Spencer’s draft goes on to acknowledge, with evident resignation, that the choice of delimiter wasn’t ideal — it depends on software correctly preserving a trailing space, which is exactly the kind of thing that gets silently stripped by text editors and mail transport software — but that it was “too well-established to change” even then.
That last point is the interesting part. Spencer circulated “Son of 1036” informally starting in 1994. It was never submitted for formal RFC publication at the time, yet newsreader and mail client developers adopted it anyway, because it was the clearest available specification of how Usenet software was actually supposed to behave. It picked up the nickname “Son of 1036” and became the de facto reference for an entire generation of Usenet tooling — while remaining, technically, just an expired Internet-Draft sitting outside the official standards track.
It eventually was published — as RFC 1849, in March 2010, sixteen years after it started circulating, by which time it had already been formally obsoleted by RFC 5536 and RFC 5537 (2009), the standards that superseded it. The RFC Editor’s own announcement captured the oddity of the situation neatly, describing it as “the best-known Internet Draft (n)ever published.” Few standards documents can claim to have shaped a generation of software while officially not existing.
RFC 3676: the delimiter gets a formal home in email
While RFC 1849 was specifically about Usenet news articles, the same -- convention had long since spread into email, where MIME-aware mail clients faced their own version of the problem: how do you know where a message ends and a signature begins, especially in a quoted reply thread?
RFC 3676, the Text/Plain Format and DelSp Parameters specification, published in 2004, gave the convention its first formal home inside an actual email standard, rather than a Usenet-specific one. Section 4.3 addresses it directly, noting that there is “a long-standing convention in Usenet news which also commonly appears in Internet mail of using -- as the separator line between the body and the signature of a message” — and then specifies exactly how compliant software has to treat it: a line consisting of dash, dash, space is never to be treated as part of a flowed paragraph, and a generating mail client must never end an ordinary paragraph with that exact sequence by coincidence, because a receiving client is required to treat it as a signature boundary regardless of intent.
That requirement is precisely why the trailing space matters. -- on its own, with no space, doesn’t trigger the rule. The exact three-character sequence does. It’s also why some mail clients, to this day, use that line to decide where to stop including content when you reply to a message — strip everything from the first -- line onward, on the assumption that it’s signature, not substance.
An even older precursor: finger, .plan, and .project
The impulse behind the email signature — leave a small, persistent, semi-public note about who you are — predates both Usenet conventions discussed above. The finger protocol, formalised in RFC 1288 in 1991, let one networked user query basic information about another, including the contents of two specially named files in their home directory: .plan and .project. Users were free to put whatever they liked in a .plan file, and many filled it with the same mix of status updates, jokes, and personal trivia that would later show up in .signature files and, eventually, in email footers. It’s a reasonable case for the earliest digital ancestor of the modern email signature — a voluntary, self-authored, persistently-displayed personal footer, just attached to a different protocol entirely.
A handful of adjacent conventions worth knowing
None of these have quite the same documented standards history as the delimiter itself, but they were the social context it existed in, and Article 16 covers them at greater length:
- The four-line rule. RFC 1855, the IETF’s 1995 Netiquette Guidelines, advised keeping a signature to no more than four lines, largely because bandwidth was scarce and metered.
- ASCII art and sig quotes. Once a delimiter existed to mark where a signature started, people used the space behind it for everything from elaborate character-based line drawings to a favourite quotation, with predictably mixed results.
- The “sigmonster.” Informal slang for a signature so long it had become a problem in its own right — usually one that ignored the four-line rule by a wide margin.
Why a detail this small is worth knowing
The -- delimiter is a useful reminder that a lot of the conventions holding the internet’s plumbing together were never centrally designed — they were observed, written down after the fact by someone paying close attention, and only formalised once enough software already depended on them that not formalising them had become the riskier option. RFC 1849’s sixteen-year gap between informal adoption and formal publication is an extreme case of that pattern, but it’s not a unique one.
It’s also, in a small way, a nice piece of trivia to have on hand the next time someone asks why their reply quoting tool keeps cutting their message off at a seemingly random line.
SigHQ is part of the next chapter — an add-in-first approach to email signature management built for the way Microsoft 365 organisations actually work. Join the waitlist.
Frequently asked questions
Is the -- signature delimiter still relevant today?
Yes, in two practical ways. Some mail clients and quoting tools still look for it to decide where to truncate a quoted reply, and many plain-text mailing list and forum conventions still rely on it to separate body from signature. It’s largely invisible in modern HTML-formatted corporate signatures, but the underlying convention never went away in plain-text contexts.
Why two hyphens and a space specifically, rather than some other marker?
There’s no deeper technical reason — it was simply the pattern that happened to spread through early Usenet newsreader software before any formal standard existed, and by the time RFC 1849 documented it, it was already, as Henry Spencer put it, “too well-established to change.”
Does the trailing space actually matter, or is it just a quirk of the original wording?
It matters under the formal definition in RFC 3676: the rule specifically describes the sequence as two hyphens followed by one blank character, and compliant software is required to treat that exact line as a signature boundary. Many text editors and some software historically stripped trailing whitespace, which is part of why Spencer’s draft flagged the choice as “unfortunate” even while defending it as unavoidable at that point.
Was RFC 1849 an official internet standard while it was unpublished?
No — for sixteen years it existed only as a circulated, expired Internet-Draft with no formal standards-track status, despite being the de facto reference most Usenet software developers actually built against. It was finally published as RFC 1849 in March 2010, by which time RFC 5536 and RFC 5537 had already formally superseded it.