Re: [ietf-smtp] [Proposal] confusing parts of the mail system, was 250-MARKDOWN

valdis.kletnieks@vt.edu Thu, 10 January 2019 21:49 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 DFBAE131275 for <ietf-smtp@ietfa.amsl.com>; Thu, 10 Jan 2019 13:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LDK9xXRybJ9g for <ietf-smtp@ietfa.amsl.com>; Thu, 10 Jan 2019 13:49:08 -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 22574131273 for <ietf-smtp@ietf.org>; Thu, 10 Jan 2019 13:49:08 -0800 (PST)
Received: from mr2.cc.vt.edu (mr2.cc.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 x0ALn6dK007685 for <ietf-smtp@ietf.org>; Thu, 10 Jan 2019 16:49:06 -0500
Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by mr2.cc.vt.edu (8.14.7/8.14.7) with ESMTP id x0ALn03K020396 for <ietf-smtp@ietf.org>; Thu, 10 Jan 2019 16:49:05 -0500
Received: by mail-qt1-f197.google.com with SMTP id z6so13133530qtj.21 for <ietf-smtp@ietf.org>; Thu, 10 Jan 2019 13:49:05 -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:date:message-id; bh=5gG5hLF/79ihsrRNBQF5pdhDZfxye9BTAFXxe0KC2Hs=; b=K5JYVyRik8g+/Rp3c8pIx4P6y143IyzyK5J5fWcMpZRmTqpqQlr3Qss4pk2GUVVETD 4m36VRt+eIZMMSXinV+CxzxsxXzVcJYziHjLfe3x6ybDyCGagcNa16tYicm1leZFIjww diOZFIRnAGT2dWm74ZMj08JO4TLjJLC+wjc/99gSyRfg7t+eMQViX5iTIsQZOWQUUqwi BiL+nKJwsjpUH72tJIzuVe10l9bQrci6eBY/3uEzp+SvbQ+He9IY/RIVphWWaHSLHeIi +wrXOJKKBJVyF2p7GJ9E+7+Y0ScbkOImf7qGpeU+f/Ng1n+1ien3kBfdEQVSuLpezk+Z WQnw==
X-Gm-Message-State: AJcUukfsjHzeUmG2R9Avo4EG1zJ5+oOojcgISjJNqi/ji2oyB9USgFv+ MDjug26enE0Do4uB+PnSWxk9+do5Vo5dB5zp7iDWDjwcqoq/IclvS07+h+b76onPVpo/x7h0A8j U4nNcIAgYozdQnzEJ/a0o6Q==
X-Received: by 2002:ac8:1b82:: with SMTP id z2mr11522948qtj.321.1547156940039; Thu, 10 Jan 2019 13:49:00 -0800 (PST)
X-Google-Smtp-Source: ALg8bN4hEOufKxaPoY3FSj57ZTve7fzysj7UtUPCqTFBeCIB0KcocoGsJd2WNbtWhgNMRhDebycgLQ==
X-Received: by 2002:ac8:1b82:: with SMTP id z2mr11522936qtj.321.1547156939820; Thu, 10 Jan 2019 13:48:59 -0800 (PST)
Received: from turing-police.cc.vt.edu ([2601:5c0:c001:4341::359]) by smtp.gmail.com with ESMTPSA id k16sm10189855qkj.38.2019.01.10.13.48.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 10 Jan 2019 13:48:58 -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: John Levine <johnl@taugh.com>
cc: ietf-smtp@ietf.org
In-reply-to: <20190110210727.8878F200C85075@ary.qy>
References: <20190110210727.8878F200C85075@ary.qy>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 10 Jan 2019 16:49:23 -0500
Message-ID: <18810.1547156963@turing-police.cc.vt.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/x3KW3v2F22dFdVvEm7Y6PGgr7vw>
Subject: Re: [ietf-smtp] [Proposal] confusing parts of the mail system, was 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: Thu, 10 Jan 2019 21:49:10 -0000

On 10 Jan 2019 16:07:27 -0500, "John Levine" said:

> The theory is that you submit the whole message to Google and it
> probes the recipients before it accepts the message, but now you have
> the added issue of how to report back that receipient A can handle it
> but recipient B cannot.

That will teach me to reply before caffeine. ;)  I was discussing the MUA-MSA
interaction. And you'd think that somebody like me would know that stuff :)

You can receive a RCPT TO, and probe before returning a 250/550. You can cheat
a bit if you turn on PIPELINE, then you can accept up to the DATA, and do
probes in parallel with accepting the next RCPT before feeding back all the 2xx
Recipient OK and 5xx Won't Work replies.

That of course just kicks the can back up the road, as the new problem is "OK,
so knowing that, what does the MUA do *now*?"

This is the point where the software engineer looks at the e-mail from the project
manager that shows the ship date, and says "Screw it" and puts in code to
just base64 the damned thing :)

> I'd really rather the duct tape be applied to make external-body work
> better.

Agreed.  The last time I looked at this (admittedly quite some time ago), the
biggest missing parts were an RFC-standard way to denote an expiration time
("this URL good until <datestamp>") and a secure way to pass an indication of
what credentials are needed to access the object.