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

Hector Santos <hsantos@isdg.net> Mon, 04 January 2016 18:33 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23241A0390 for <ietf-822@ietfa.amsl.com>; Mon, 4 Jan 2016 10:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.301
X-Spam-Level:
X-Spam-Status: No, score=-99.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LACN1pm4aGY8 for <ietf-822@ietfa.amsl.com>; Mon, 4 Jan 2016 10:33:32 -0800 (PST)
Received: from secure.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C29A11A038C for <ietf-822@ietf.org>; Mon, 4 Jan 2016 10:33:31 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3134; t=1451932403; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=trpnCxKA8ET1EJFou6TWlbLb4dg=; b=QKbtYtxNFbHrckcJnejg8/ovMS2kZ1ouboUhCS9wZg5kA8mhsy3F7WuO9FFitf dTCv6MyDyUome2sUHvrawiUEymsZoti+vrqv1PEgDUB9Y8DgUGWwr3gaMQnZZKWQ I/8iJr0EZfmxkulItJ/6OsGk88dTcH9aw9AA1vOZ0JY+U=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for ietf-822@ietf.org; Mon, 04 Jan 2016 13:33:23 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 91595612.4.3352; Mon, 04 Jan 2016 13:33:21 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3134; t=1451932397; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RohN2Cr 42Vp2wNutVT+7KiZBfkLAVpgOua9+J0BsUK8=; b=dy9f0sFqxBHj2WwYtOIy6Er GKwKbnRVH7DnWjsD9L0Je56R/4ArGpCBU53oe+EuTRT8UIO9C6BCqW8zvBTnpqge rh5kU6AF2UGsvHPo6otGw2FJgDQy4n9ETANgdkbfkHslJJ2tSwBXC7LUhzyNply5 R7Du/9Tb0Ead2Ie3lIE8=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for ietf-822@ietf.org; Mon, 04 Jan 2016 13:33:17 -0500
Received: from [192.168.1.2] ([99.121.4.202]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 91681203.9.548; Mon, 04 Jan 2016 13:33:16 -0500
Message-ID: <568ABAEE.5040407@isdg.net>
Date: Mon, 04 Jan 2016 13:33:18 -0500
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: Jacob Palme <jpalme@dsv.su.se>, "Murray S. Kucherawy" <superuser@gmail.com>
References: <D6D98A12-74D5-45CB-86AD-3BDE6A931CFF@dsv.su.se> <87vb7bwv7n.fsf@hope.eyrie.org> <CAL0qLwYRTvLFwEZPNFbaNybGwj+e_g33kZQkFeLN4YTsZ=KSZg@mail.gmail.com> <86B20CD4-A452-4FA3-BBAF-D2BE99104BA9@dsv.su.se>
In-Reply-To: <86B20CD4-A452-4FA3-BBAF-D2BE99104BA9@dsv.su.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-822/Cj20HLDxoQdqNOIWTHlH4gmKUL0>
Cc: ietf-822@ietf.org, Russ Allbery <eagle@eyrie.org>
Subject: Re: [ietf-822] "--" first in lines to indicate start of signature
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jan 2016 18:33:35 -0000

On 1/4/2016 8:39 AM, Jacob Palme wrote:
>
> 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.
>

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