Re: [Shutup] [ietf-smtp] Compressing SMTP streams

Brandon Long <blong@google.com> Fri, 29 January 2016 21:14 UTC

Return-Path: <blong@google.com>
X-Original-To: shutup@ietfa.amsl.com
Delivered-To: shutup@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212501B344A for <shutup@ietfa.amsl.com>; Fri, 29 Jan 2016 13:14:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 pxFYsQZkbgTD for <shutup@ietfa.amsl.com>; Fri, 29 Jan 2016 13:14:08 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F056F1B3438 for <shutup@ietf.org>; Fri, 29 Jan 2016 13:14:07 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id d63so85238702ioj.2 for <shutup@ietf.org>; Fri, 29 Jan 2016 13:14:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C7Dsrb8DnlWk/qMqM3lSztMVppFjxPl/uSJryC0MZ1E=; b=pqLWUNmGmsPFTnABE6dGTJ0p7tL7U5ULPg6+mGR7dQOYYHqhW6FCU1QKj4O6HFCqHK wAumGZwuk07el1k2vqh8Xr84lAtSjAjbxPtmI9rYlmklb1ucA5+aTw5qwhsZDPBVUx1h N/oFuWu1F9OyANvpYJUul5DH7qM7gbAtG9wbY1NRrJvXNLTIv+7BKOXFbP8NQ7BtmOkT hoj1y8AuBsIRL9ZlanBRx4+S1bE2FvigLe+jYRER6AlVv5ObRRMsEzvuJ7WJc0RdCtPA TrP+q/Jb9J6YYtTDc66dLl/DWZM5Clg/+8Y1yWwnocaQme59VACViQoSFhRW7DloI5A5 Basg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=C7Dsrb8DnlWk/qMqM3lSztMVppFjxPl/uSJryC0MZ1E=; b=A4X6zPxCG1M6R3sZq4sby+K+w6gyJgE3/Rbz/Ov2x5gclrUXeOWd8Eng97/3oKQbdr +Lt0hFvYExa22k9mU8i1d42mGrcwIVlXBr36qeGXHLYS5SRudiyRdN0kp9UbnoafqvdC AWsJr06gSKyjtMM2xq0oFk2cnbr0tMjL+dTP6nD+HvjxGNpZsDGFlvHwO8qJ9Bfa/K0l MjhC6tro+V0GAcKvHI5Jx9P/U4QV2ux0vikzBBrKKY8hh3ABtE6IdEiioi01l3JMx2rv 7QXtr6fCmAzeSLV++rnjQ9heslfxy3pz7VhA52YGRQjceWO9LF55Mx2YAGhPfM8IfWvE 4ECQ==
X-Gm-Message-State: AG10YOQasKqv+F2qZQ+Bic2o0WlvMb0tUNda93fYzXNa1uZD2dljaD4gBKkwC0gyoc59CNzrlUTTPv4rQUficceZ
MIME-Version: 1.0
X-Received: by 10.107.159.7 with SMTP id i7mr11408867ioe.29.1454102047175; Fri, 29 Jan 2016 13:14:07 -0800 (PST)
Received: by 10.64.62.194 with HTTP; Fri, 29 Jan 2016 13:14:06 -0800 (PST)
In-Reply-To: <56ABD3DA.70203@alameth.org>
References: <20160129180713.51570.qmail@ary.lan> <56ABD3DA.70203@alameth.org>
Date: Fri, 29 Jan 2016 13:14:06 -0800
Message-ID: <CABa8R6vOrt6UDTTLk2EepEFetj2CR8rqQZzuDmsnYZRBJb0SYg@mail.gmail.com>
From: Brandon Long <blong@google.com>
To: "Carl S. Gutekunst" <csg@alameth.org>
Content-Type: multipart/alternative; boundary=001a1141bf06fdc0dd052a7f8371
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/6ehTel_zsX-goQxEmXrL5oZgbx0>
Cc: shutup@ietf.org, John Levine <johnl@taugh.com>, ietf-smtp <ietf-smtp@ietf.org>
Subject: Re: [Shutup] [ietf-smtp] Compressing SMTP streams
X-BeenThere: shutup@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <shutup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shutup>, <mailto:shutup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/shutup/>
List-Post: <mailto:shutup@ietf.org>
List-Help: <mailto:shutup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shutup>, <mailto:shutup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2016 21:14:09 -0000

On Fri, Jan 29, 2016 at 1:04 PM, Carl S. Gutekunst <csg@alameth.org> wrote:

> Well, in that case, here's a straw man proposal.
>>
>> The extension name is COMPRESS, the EHLO keyword is COMPRESS and is
>> followed by a space-separated list of compression schemes, currently
>> consisting only of DEFLATE (RFC 1951.)
>>
>> There's one new command, COMPRESS which takes as an argument the type
>> of compression to be used.  If you want to do both STARTTLS and
>> COMPRESS, the results of doing COMPRESS before STARTTLS are
>> aggessively undefined.
>>
>> The responses to COMPRESS are:
>>
>> 500 compress not supported
>> 501 compression scheme unknown
>> 220 go ahead
>>
>> After a 220 response, subsequent traffic is compressed.
>>
>
> Yes, order must be STARTTLS, then AUTH, then COMPRESS.
>
> We assume that binary MIME (ala RFC 3030) is dead.
>
> Alternative: Is there any benefit to compressing the envelope? With
> pipelining, probably; otherwise no. If we don't compress the envelope, then
> we could make compression an option on the DATA command. Now we have
> something that starts to look like RFC 3030, but without the assumption
> that the sender should not use Base64 (with its attendant and DKIM-breaking
> content transfer encoding conversion at each hop).


1000 recipients at ~30 bytes each with each domain likely the same... maybe
sometimes.

If you're only compressing the data, what's the interaction with RFC 1870?
Do you use the compressed size or the original, and if you use the
compressed size, does that mean the server will accept larger uncompressed
messages?

And I'd think it's an alternative to BDAT, same thing, but compressed?
Unless we extend the BDAT syntax for compression...

Brandon