IETF Logo Mail Archive

Re: [ietf-smtp] Quoted-Printable-8bit

Ned Freed <ned.freed@mrochek.com> Tue, 30 March 2021 16:42 UTC

Return-Path: <ned.freed@mrochek.com>
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 88ED83A1AAA for <ietf-smtp@ietfa.amsl.com>; Tue, 30 Mar 2021 09:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
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 9auuPnnGznPB for <ietf-smtp@ietfa.amsl.com>; Tue, 30 Mar 2021 09:42:16 -0700 (PDT)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 32AC03A1976 for <ietf-smtp@ietf.org>; Tue, 30 Mar 2021 09:42:16 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RX9W6F88O000G767@mauve.mrochek.com> for ietf-smtp@ietf.org; Tue, 30 Mar 2021 09:37:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1617122232; bh=s1LnPer99PBDNFX9YyBEW0IryCVNSk+MF5XmgudAMR4=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=a1b5lOGjjyfsG7xl2YW3FH5QLGEaOhqh9DeiZmQDhnQirWgitynYn/atO4D9kveCP IaXF20WJPyNne+5+kWJVmaXVrJt2SVTRrmg4i8WnawnQU1S74pbQDy8gMleUMEop6e 5r6VyssbzQsJAwITt04ziH3PfsPT3p6rMlBws290=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"; format="flowed"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RX758ICMBK0085YQ@mauve.mrochek.com>; Tue, 30 Mar 2021 09:37:08 -0700 (PDT)
Cc: Ned Freed <ned.freed@mrochek.com>, ietf-smtp@ietf.org
Message-id: <01RX9W6C86LY0085YQ@mauve.mrochek.com>
Date: Tue, 30 Mar 2021 09:34:51 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 30 Mar 2021 12:00:40 -0400" <c23583b4-f69b-41c5-a74c-9aab697634dd@taugh.com>
References: <cone.1617061398.771367.57281.1004@monster.email-scan.com> <20210330010027.F13AD718E3C0@ary.qy> <01RX9R37H1CC0085YQ@mauve.mrochek.com> <c23583b4-f69b-41c5-a74c-9aab697634dd@taugh.com>
To: John R Levine <johnl@taugh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/mB1BRGs-deGDfo0DdF1rGxwFi94>
Subject: Re: [ietf-smtp] Quoted-Printable-8bit
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: Tue, 30 Mar 2021 16:42:21 -0000

> > Nope. MIME was carefully designed to support both 8bit and binary format. We
> > briefly considered defining the necessary transport - and in hindsight not doing
> > so was an error - but back when RFC 1521 and 1522 came out the situation
> > surrounding 8BITMIME was unclear, so we didn't pursue it.

> For binary parts you just scan for --delimiter\r\n ?  I guess that would
> work.

Having implemented it, I can say it works very well indeed.

> >> The advantage of BDAT over DATA for 8BITMIME is pretty modest, and can
> >> even be negative for the implementations that send small 8K BDAT
> >> chunks.
> >
> > Acutally, the advantages can be quite significant client-side, depending
> > on your implementation.

> I see how you could use sendfile() to blat a message to a socket if it's
> stored with \r\n line endings.  Is it more than that?

That plus pipelining.

				Ned

v2.23.0 | Report a Bug | By Email