Subject: [ietf-822] "--" first in lines to indicate start of signature

From: Jacob Palme <[email-masked]>
Date: Sat, 2 Jan 2016 20:50:46 +0100

A common convention is that e-mail messages contain a short description of the author, called "signature" and the start of this is indicated by a line only containing the two characters "--".

Is this convention recommended or discused in some IETF standard? I cannot find it in rfc5322.

This convention is very commonly used, but somewhat controversial. Some mail program assume that text after a line with only "--" in it are signatures, which are by some mail programs shown, when displaying incoming mail, in a special signature format. And it is a common mistake by message writers to write a line with just "--" in it for other purposes than starting a signature. Every mail writer is not an expert on such e-mail conventions. If IETF describes this convention in some way, IETF should maybe recommend some kind of warning to people who write single lines containing only "--" when this is not start of a signature.
--
Professor emeritus Jacob Palme <[email-masked]> (Stockholm University)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: Richard Clayton <[email-masked]>
Date: Sat, 2 Jan 2016 20:48:36 +0000

In message <[email-masked]>, Jacob Palme
<[email-masked]> writes

>A common convention is that e-mail messages contain a short description of the 
>author, called "signature" and the start of this is indicated by a line only 
>containing the two characters "--".

no ... it's two dashes then a space

>Is this convention recommended or discused in some IETF standard? I cannot find 

it comes from Usenet -- see RFC3676 #4.3

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Russ Allbery <[email-masked]>
Date: Sat, 02 Jan 2016 13:02:52 -0800

Jacob Palme <[email-masked]> writes:

> A common convention is that e-mail messages contain a short description
> of the author, called "signature" and the start of this is indicated by
> a line only containing the two characters "--".

The full, "correct" convention is actually the three characters "-- " with
the trailing space.  Obviously, this causes all sorts of problems in
practice, and a lot of software is tolerant of the space being removed.
But that was originally the standard to try to avoid issues with the other
uses of -- on a line by itself.

> cannot find it in rfc5322.

I believe, although am not certain, that this convention originated in the
netnews world.  It is documented in RFC 1849 (aka "Son of 1036"), a highly
influential draft that was never formally published as an RFC until the
USEFOR work, during which it was published directly as historic.

   Early difficulties in inferring return addresses from article headers
   led to "signatures": short closing texts, automatically added to the
   end of articles by posting agents, identifying the poster and giving
   his network addresses, etc.  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).  Posting agents SHOULD limit the length of
   signatures, since verbose excess bordering on abuse is common if no
   restraint is imposed; 4 lines is a common limit.

      NOTE: While signatures are arguably a blemish, they are a well-
      understood convention, and conveying the same information in
      headers exposes it to mangling and makes it rather less
      conspicuous.  A standard delimiter line makes it possible for
      reading agents to handle signatures specially if desired.
      (This is unfortunately hampered by extensive misunderstanding of,
      and misuse of, the delimiter.)

      NOTE: The choice of delimiter is somewhat unfortunate, since it
      relies on preservation of trailing white space, but it is too
      well-established to change.  There is work underway to define a
      more sophisticated signature scheme as part of MIME, and this will
      presumably supersede the current convention in due time.

      NOTE: Four 75-column lines of signature text is 300 characters,
      which is ample to convey name and mail-address information in all
      but the most bizarre situations.

So far as I know, it was never documented as part of a standards-track
RFC.  It probably would have been mentioned in the USEAGE document that
USEFOR considered taking up (draft-ietf-usefor-useage-01), but the working
group ran out of steam before that work got very far.

-- 
Russ Allbery ([email-masked])              <http://www.eyrie.org/~eagle/>

---

From: Russ Allbery <[email-masked]>
Date: Sat, 02 Jan 2016 13:05:00 -0800

Richard Clayton <[email-masked]> writes:
> Jacob Palme <[email-masked]> writes

> it comes from Usenet -- see RFC3676 #4.3

Oh, I had completely forgotten that it made it into the text/plain format
definition.  Thank you!  I'll add that to my page of Usenet article
reference information.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 2 Jan 2016 15:05:42 -0800

> uses of -- on a line by itself.

What other uses of "--" on a line by itself are there?  The only thing I
can think of is ASCII art.

-MSK

---

From: Russ Allbery <[email-masked]>
Date: Sat, 02 Jan 2016 15:38:37 -0800

> can think of is ASCII art.

Some people use it as a break between several thoughts.  This has probably
grown since Markdown started using three hyphens to indicate a horizontal
rule.  The distinction between two hyphens and three hyphens is the sort
of thing that people don't always get right.

That being said, the more common problem is software recognizing -- at the
start of a line as being the start of a signature even if it's followed by
other text, which runs into issues with em-dashes as represented in ASCII.

---

From: Jacob Palme <[email-masked]>
Date: Mon, 4 Jan 2016 14:39:19 +0100

On 3 jan 2016, at 00.05, Murray S. Kucherawy wrote:

> What other uses of "--" on a line by itself are there?  The only thing I can think of is ASCII art.

I have used "--" to separate sections in a longer plain text document. I have learned to not use it in that way in mail messages, and use "==" instead of "--". But it is a simple mistake to make if you are not aware of its special meaning in mail messages. Which probably many mail users are, everyone is not an expert on mail protocols, as we who subscribe to this mailinglist are.

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Jan 2016 13:33:18 -0500

> I have used "--" to separate sections in a longer plain text document. I have learned to not use it in that way in mail messages, and use "==" instead of "--". But it is a simple mistake to make if…

Jacob, since the 80s, I've written a number mail reader/writers, 
a.k.a. MUAs, mail tossers, importers/exporters, gateways/mailers, etc 
for several networks and mail formats where each had its own technical 
relationship to body parts such as "tear lines" and "Origin" lines, 
and/or kludge lines.

For the old school Fidonet mail network, the Fidonet Technical 
Standards provided early guidelines.

http://ftsc.org/docs/
http://ftsc.org/docs/fsc-0043.002
http://ftsc.org/docs/fsc-0046.005

(I was looking for a specific one that also described the tear line 
with line information, I couldn't find it offhand.)

Many IETF folks has a history with Fidonet.   I recall FSC-0046 was 
JoHo's attempt to add "commercial tagging" using a PID (Product ID) 
kludge line because of the Tear Line and Tag line "Stripping Wars." 
The proposal tried to give some guidelines for mail product developers 
to follow at the time.  I recall the "Stripping Wars" when some 
product vendors began to add/strip/replace the tear line with "--- Not 
Registered" tags and other mail products and even operators stripped 
and replaced it with there own tags during the transport process.   In 
fact, to illustrate the problem, I added logic in a MUA to completely 
hide them and/or replace it with a "visual" change, not a physical 
mail storage change. Call it Visual Tampering!  It goes to show how 
young MUA technology is still is because it is ultimately the tool 
that people use to SEE the mail with.

Also, there are other "formats" for this, three dashes "---" and 
"Origin Line" style " * " that FSC-0043 describes.   Add the QWK tag 
line, its possible to see 2-4 lines:

--  User Line, maybe.
--- Mail Product Line
  *  Original Domain line

Look at the line that the iPhone and iPad adds to each message 
automatically.  There is no rule that says it has to remain there. :)

At the end of the day, we don't have control over the body nor what 
the MUAs wants the user to see.  But I agree, the Mail Creator, the 
MUA, should probably have some RFC5322 related guideline on what to 
use.  When the move was made to RFC 822/2822 several decades ago,  I 
wasn't aware of any "IETF guideline" for this.  There is probably some 
I-D or RFC proposal now or someone can come up with one but overall, 
if it begins to get exploited with overhead text, commercialization 
concepts, etc, its going to get stripped and "visually" hidden.  :) 
Just consider that new mail viewing devices doesn't have the real 
estate for such overhead.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Jan 2016 14:23:21 -0500

Hi Russ,

>> can think of is ASCII art.

I've written ASCII/ANSI/VT100 drivers and I don't recall a 
relationship other than some early body/text delimiter (ideal when you 
parse/read from the bottom, i.e. first delimiter encounter when 
reading up).

> of thing that people don't always get right.

As I recall it, there was a "stripping war" and people tried to hide 
their tags using different identifiers.  QWK was a popular mail reader 
and it used something like, if I recall the format:

  ...
   X  QWK brag line where X was an extended "block-looking" character.

and Sparky did it so that it didn't get recognized and stripped. QWK 
format didn't want to get involved any Fidonet "regulation." 
Overall, mailers can do what they want. A reader or mailer was going 
to add its tag no matter what so it was not uncommon to see a bunch of 
"tear/tag" lines lumped together.

Much of the IETF stuff came from Fidonet where we didn't have a HEADER 
block.  We had kludge lines (Control A lines) that can appear anywhere 
in the payload.  That was one of the beauties of going to a more 
flexible, text-structured RFC822 format where increasing hardware 
speeds made it more feasible.   The Tear line and well as the Origin 
line were important body text delimiters since kludge lines were 
normally in the top and bottom of message.

   ^aPID
   ^aMSGID
   ^aREPLY
   ^aOther kludges

    body text

    --- tear line
     ^APath Line(s)
     ^aSeen-by Nodes line(s)

So mail processor developers can imagine what would be the logical 
varying coding techniques.  You can start at the bottom, get your 
seen-by and path lines, if any, and get to that first "tear line" or 
start at the top and get to the last one, etc.

> other text, which runs into issues with em-dashes as represented in ASCII.

I don't like the idea of trying to standardize a "-- " tag although 
this character sequence seems to be popular among "some" IETF users, 
but not outside.  As you said, other formats such as "--- " also exist 
and you have other variations as well.   There should be some 
guidelines I think for MUAs to consider or document, but not fix them 
to any set, if we can avoid it.

Why dashes?  Why not underscores? or Equal signs or in a modern 
extended character set world, Line (xC4) characters?

___ HLS
=== HLS
─── HLS

They all look "cool" and maybe using an extended code MAY help delimit 
it better, coding wise.

-- 
HLS

---

From: Jacob Palme <[email-masked]>
Date: Mon, 4 Jan 2016 20:31:57 +0100

On 4 jan 2016, at 19.33, Hector Santos wrote:

> Jacob, since the 80s, I've written a number mail reader/writers, a.k.a. MUAs, mail tossers, importers/exporters, gateways/mailers, etc for several networks and mail formats where each had its own technical relationship to body parts such as "tear lines" and "Origin" lines, and/or kludge lines.

Standards are mostly optional. Particularly so in what we are discussing now, the "signature" notation at the end of messages. Implementors are usually not forced to agree with them. But implementors doing things that violently disagrees with standards may sometimes get into trouble in that users cannot do what they want with their products. Standards can be an aid to developers of new software, in order to get their products work better with each other.

The "signature" feature is violently disliked by some people. I find it useful when I need more information about the person behind a message I get. Since it is controversial, I have chosen to make my own signature short, and include in it a link to a web page, where people can get more information about me, if they so wish.
--
Professor emeritus Jacob Palme <[email-masked]> (Stockholm University)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Jan 2016 14:53:58 -0500

On 1/4/2016 8:39 AM, Jacob Palme wrote:
> I have used "--" to separate sections in a longer plain text document. I
>have learned to not use it in that way in mail messages, and use "=="
>instead of "--".

That will still get you in trouble. Overall, when you begin to depend 
on such ideas, you need ways to escape it as well.

> But it is a simple mistake to make if you are not aware of its special
> meaning in mail messages.

IMO, there is no "special meaning."  The idea of a 'Signature" may be 
traditionally at the bottom, but there is no real hard core rule you 
(a mail processor) can rely on.

The MUA software does not use normally this.  It is the USER with his 
optional signature fields and thats just added straight to the bottom. 
   The same software COULD check if the same block was already added 
but I don't believe it will add "-- " for you, well, at least my TBird 
doesn't.   I noticed that TBIRD can not tell the difference between 
the signature fields when you change your "From: " field in the MUA, 
so you have to clean that up yourself.

> Which probably many mail users are, everyone is not an expert on mail protocols,
>as we who subscribe to this mailinglist are.

Right, outside the tech forums, you generally don't see this in the 
user market unless the MUA has direct support for this where it works 
off a "standard delimiter" of some sort.

We had such logics in older Fidonet/QWK readers. When we began to use 
RFC based formats, it felt like we began to deprecate the idea. It 
wasn't a big thing anymore because the body text can have anything. 
The then "new" Internet Format brought on a new Democracy of mail 
where it can have anything.  I was more concerned with transport 
related network control lines.   The signature is not a network or 
mail control Line.  Offhand, I would not classify it as such.

I guess the point is unlike MIME block where we have distinct line 
delimiting logic to separate blocks of text lines with border lines, 
etc,  we don't have such a thing for signatures.   What would be the 
rules? Is there a MIME type for signatures?  Are there limits (length 
of line, # of lines) in what junk people can add?  Look at the extra 
stuff a few of the IETF guys add.

***
HLS

---

From: Jacob Palme <[email-masked]>
Date: Mon, 4 Jan 2016 21:00:22 +0100

> For the old school Fidonet mail network, the Fidonet Technical Standards provided early guidelines.

I have no experience with Fidonet. It seems like an interesting community, with lots of in-text special rules and procedures. IETF standards cannot adopt much of this, but some of it may be useful. I have tried to write some RFCs which are guidelines more than standards, but never got them finished enough to have it published as an RFC.

Examples of such un-finished documents, which I have written but never got ready for RFC status, are:

The IETF Golden rules: http://people.dsv.su.se/~jpalme/ietf/golden-rule/
Putting tables in e-mail messages: http://people.dsv.su.se/~jpalme/ietf/tables-in-email.html
Advice on implementing html-formatted e-mail messages: http://people.dsv.su.se/~jpalme/ietf/mhtml-info.html
--
Professor emeritus Jacob Palme <[email-masked]> (Stockholm University)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: Russ Allbery <[email-masked]>
Date: Mon, 04 Jan 2016 12:00:52 -0800

Hector Santos <[email-masked]> writes:

> I don't like the idea of trying to standardize a "-- " tag although this
> character sequence seems to be popular among "some" IETF users, but not
> outside.

Use of "-- " for a signature delimiter is ubiquitous on Usenet and has
been for decades, for whatever that's worth.  I suspect many of us who use
this convention in email are either old Usenet users or are using software
that understands both email and Usenet and treats them similarly (or both,
as in my case).

In email, it's also reasonably common as a delimiter for the footers added
by mailing list software.  I believe Google Groups uses it, for instance.

It's always been a wart, and it's certainly not the sort of thing that one
would design today in an intentional standard for a whole host of reasons,
but it has a *very* long established history.

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Jan 2016 18:13:42 -0500

> that understands both email and Usenet and treats them similarly (or both,

Of course.  Software that used all formats, like fidonet/echomail and 
internet/newsgroups all supported various forms and some even have 
user-definable signature fields.

But do they use "-- " automatically or is it user-defined (added)?

> but it has a *very* long established history.

I just did a quick sample of the last 10 people in the IETF list, 
counted at least 2 people with "-- " -- 20%, pareto's ratios.

Yes, the history is long there but also for other formats or even no 
"tag" formats at all, e.g.; just with a tab and name, perhaps.

	Hector

---

From: Russ Allbery <[email-masked]>
Date: Mon, 04 Jan 2016 15:33:54 -0800

> But do they use "-- " automatically or is it user-defined (added)?

Automatically.  You specify the contents of the signature (via various
ways), and the process of appending the signature coded in the client
automatically adds the "-- " delimiter line.

> "tag" formats at all, e.g.; just with a tab and name, perhaps.

I'm probably arguing with something you're not actually saying, so feel
free to ignore me if that's the case.

But I feel like you're misunderstanding the degree to which this is part
of the netnews article format.  This is not a random convention that just
some people use on the netnews side; it's built into every netnews client
I know of that supports signatures, and is very widely supported on the
reading side as well.  (For example, my client does syntax highlighting of
the signature block, greying it out, and supports automatically omitting
the signature from quoted follow-ups.)  It was commmon for people on
netnews to point out to others when the signature delimiter was mangled
(missing the trailing space, for instance), and there are netiquette
conventions for acceptable length and related issues.  (The Google search
term is "McQuary limit".)

It may be just one of many conventions in email.  It is an actual,
interoperable standard in the netnews world, albeit an ad hoc one rather
than a formalized one.  Insofar as mail and netnews share a common message
format, "-- " deserves a bit more special attention from the implementor
than, say, random examples of FidoNet conventions.  Proper handling is a
quality of implementation issue if you ever touch netnews.

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jan 2016 07:52:38 -0500

> quality of implementation issue if you ever touch netnews.

Russ, much of what was done during Fidonet carried on to the 
"internet" -- it was and still is pretty much all the same, 
Fido.Netmail == Inet.Email,  Fido.EchoMail == Inet.NewsGroups, etc. 
Mail is Mail.  You know that.  When you have support for all of them, 
including others, like UTI, QWK, you get a better integrated view of 
it all. Generally, "Netnews" would be just "mail conference type" 
option in a mail hosting product line.

I guess I will wait for an actual proposal. But it sounds more like a 
MUA product enhancement or a BCP for MUAs and End Users.  Why not 
include it with other MUA mail creation "common practices" suggestions 
such as the "> " quoting characters, by far, the most popular method 
across all mail platforms?

** HLS **

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 5 Jan 2016 14:29:26 +0100

> but it has a *very* long established history.

I can guess some of those reasons.  However, besides taglines, OpenPGP and
S/MIME provide for cleartext signing with signatures at the bottom of the text,
possibly not detached from it.  Foot positioning resembles traditional,
handwritten signatures.

DKIM differs in that its signatures live in the header --with the obvious
disadvantage of requiring two passes.  Drafts which inspired DKIM, [DK] and
[IIM], provide for storing signatures in the header too.

Out of curiosity, does anyone recall how this design decision came?

TIA
Ale

References:
[DK] https://tools.ietf.org/html/draft-delany-domainkeys-base-00 (May 2004)
[IIM] https://tools.ietf.org/html/draft-fenton-identified-mail-00 (June 2004)

---

From: Jim Fenton <[email-masked]>
Date: Tue, 5 Jan 2016 08:57:07 -0800

> Out of curiosity, does anyone recall how this design decision came?

DKIM, DK, and IIM signatures are all intended to be applied and verified
by the infrastructure, not by end users. If the signatures were added to
the body, many users would call their email providers and ask, "What's
this junk in my message?" The cost of fielding those calls alone would
be a significant barrier to deployment. Putting the signatures in the
header makes them invisible to end users who don't ask to see the
header, so it provides the right answer to the visibility problem.

The signatures are of a constrained size, so why not just store a copy
of the signature header field and do the verification at the end of the
message receipt rather than make another pass for verification? I agree,
though, that adding an Authentication-Results or similar header field
would require another pass.

-Jim

---

From: Randall Gellens <[email-masked]>
Date: Tue, 5 Jan 2016 17:17:26 -0800

RFC 3676 standardizes signature separators and quote prefixes.  In a 
text/plain; format=flowed MIME part, signatures and quote prefixes 
are standardized and hence may be handled in any way desired by the 
user agents (e.g., removing signatures from quoted text in replies, 
reformatting quoted paragraphs in displays).

If you want to standardize these elements in a non-format=flowed 
part, you could do so by just pointing to RFC 3676.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Programs that crash have been proven to be less useful than those
that don't.  --Apple Technical Note OV04 (formerly Technote #117)
                developer.apple.com/technotes/ov/ov_04.html