Re: [ietf-smtp] [Proposal] 250-MARKDOWN

valdis.kletnieks@vt.edu Wed, 09 January 2019 08:30 UTC

Return-Path: <valdis@vt.edu>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95F5128766 for <ietf-smtp@ietfa.amsl.com>; Wed, 9 Jan 2019 00:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Zr7frWiD_Nwh for <ietf-smtp@ietfa.amsl.com>; Wed, 9 Jan 2019 00:30:25 -0800 (PST)
Received: from omr1.cc.vt.edu (omr1.cc.ipv6.vt.edu [IPv6:2607:b400:92:8300:0:c6:2117:b0e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E29E130D7A for <ietf-smtp@ietf.org>; Wed, 9 Jan 2019 00:30:25 -0800 (PST)
Received: from mr2.cc.vt.edu (mr2.cc.ipv6.vt.edu [IPv6:2607:b400:92:8400:0:90:e077:bf22]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id x098UNa7005732 for <ietf-smtp@ietf.org>; Wed, 9 Jan 2019 03:30:24 -0500
Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by mr2.cc.vt.edu (8.14.7/8.14.7) with ESMTP id x098UIek010559 for <ietf-smtp@ietf.org>; Wed, 9 Jan 2019 03:30:23 -0500
Received: by mail-qt1-f200.google.com with SMTP id n50so6063113qtb.9 for <ietf-smtp@ietf.org>; Wed, 09 Jan 2019 00:30:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=HDHWfx6nw3TH/Ryv4C7AUNP2cmkAZM8YBlXLawPc5AQ=; b=IO9lCNn8jKbQC5JtT9ltNUPfjN/HNGWK69LHWEIhSemBDi64Rh+N8PQBH1XVppJghX jteEDpU5nHSKwHycG5M33NFl5IVtVPaohPl6/BNLCZDopyQVQJwTKZ8nUoJxDW4Csxt8 nS6ea4aItrW5vyz9HMgLTsSPLGpMo9evel4HF1LaoaWYIz3k8k2LWBDVsgv0YOe9HPA4 9lnKYohsirr5RDk2sqwdIG0vSkPUcbPw25sU+CF7q1MmKmD9YYInx8OEIa8ICF7mWdZ2 2ZOjlL1lKt3gIHQLu5HgjgC5uMP6zqAjXAH3MbsIxxQRZS4gMyatSSR0mUO2BI2Qpg/i Gwew==
X-Gm-Message-State: AJcUukcNvoFgG06oR+Sv9pulTRVpteIRJfa2jg4orOfMKN/CoLXMi3IW Es1S0AAhe6x/eulGzzklNQc0CHeA5RnBxtJ7T/EBr2/fhKufCY21uSgx5+8GhQs3LVfwDSmYg8H CAlAy6q/7N4Qa5UFRlphIgw==
X-Received: by 2002:a37:bcc1:: with SMTP id m184mr4411284qkf.286.1547022616742; Wed, 09 Jan 2019 00:30:16 -0800 (PST)
X-Google-Smtp-Source: ALg8bN6Yn7c3b1+ulbld4mfazr3bbnhdMY0bE2qbixNzZQhU/IivBagqJkA9RUCalvAP+bAmu1dD4A==
X-Received: by 2002:a37:bcc1:: with SMTP id m184mr4411273qkf.286.1547022616490; Wed, 09 Jan 2019 00:30:16 -0800 (PST)
Received: from turing-police.cc.vt.edu ([2601:5c0:c001:4341::359]) by smtp.gmail.com with ESMTPSA id h35sm37744969qth.59.2019.01.09.00.30.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 09 Jan 2019 00:30:15 -0800 (PST)
Sender: Valdis Kletnieks <valdis@vt.edu>
From: valdis.kletnieks@vt.edu
X-Google-Original-From: Valdis.Kletnieks@vt.edu
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
To: Viruthagiri Thirumavalavan <giri@dombox.org>
cc: Gilles Chehade <gilles@poolp.org>, ietf-smtp@ietf.org
In-reply-to: <CAOEezJTakEcxq7MtYXTjjRAPCM8uGcfzMUHetRPY6enn-Bb10w@mail.gmail.com>
References: <CAOEezJRwe9iSbGyBfyHNPn8=2avo6bAoFY56++HLY5+FZHhWgw@mail.gmail.com> <144aafd5-7468-4d55-a7b7-bead5cc67e1e@email.android.com> <CAOEezJTakEcxq7MtYXTjjRAPCM8uGcfzMUHetRPY6enn-Bb10w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 09 Jan 2019 03:30:14 -0500
Message-ID: <8152.1547022614@turing-police.cc.vt.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/d-U55zz9eCb9HcB0eRBOK2wggEI>
Subject: Re: [ietf-smtp] [Proposal] 250-MARKDOWN
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2019 08:30:27 -0000

On Wed, 09 Jan 2019 13:25:43 +0530, Viruthagiri Thirumavalavan said:

> Ok what am I missing here? When a server says that "I recognize markdown
> format", then the client gonna send markdown messages as it is. I
> understand a session can transport multiple messages. But why do you think
> it won't work?

OK. 129 people at 37 different .coms that are all hosted on Office365 or
whatever Microsoft is calling that product now send e-mails to 217 people at 94
different .coms that are hosted by Google.

Microsoft bundled all 217 mails into one stream and connects to Google. Google
says "I do markdown".  Microsoft squishes 217 emails from a multipart/
alternative that contains dual text/(plain,html) down to text/markdown,
breaking any PGP or S/MIME signatures on the multipart/alternative that just
got squished into one body part.

Google now has 217 e-mails to deliver to users - and of the 94 domains, 37 of
them use a corporate email product that doesn't understand text/markdown and
they really wanted a multipart with plain,html.  Another 12 of them are
complaining that Google broke the S/MIME on an e-mail that *needed* to be
digitally signed because it was confirmation of a purchase that involved real
money (nevermind that it was Microsoft that did the squishing, the users always
complain to their own vendor, not the guilty party.  And even though the
complaining users *do* understand e-mail enough to say "I can't act on a
purchase confirmation that's not digitally signed and has a big red X on it
because the signature is bad", they don't understand that multiple servers
handled it along the way.

What does the Google server do now?

And as others will confirm, I'm not making this sort of issue up - these sorts
of problems crop up all the time.  And no matter how clear you thought you
wrote the RFC, you'll find some vendor who had a crack-addicted chimpanzee
writing code that manages to Get It Totally Wrong.

Consider this snippet from my .procmailrc that I had to put in to be able to
open e-mails from IBM:

# Lotus Notes is a boil on the buttocks of e-mail.,...
:0 hwf
*^X-Mailer:.*(IBM|Lotus) Notes
| sed -e 's/boundary="=_alternative  /boundary="=_alternative /' -e 's/boundary="=_mixed  /boundary="=_mixed /' -e 's/boundary="=_related  /boundary="=_related /'

Not only did they put blanks in the boundary separator for multipart, but they
had *two* blanks in the declaration in the RFC822 message headers, but only one
blank in the actual separators between body parts in the mail body.

And this was a problem for me because the emails that wouldn't open were from
an IBM support team working on a Sev 1 (system is totally down) issue with a
server of mine on a $1.2M project.

I never understood how that product managed to interoperate with the rest of
the world with that bug in it.