[ietf-822] Q: Space stuffing (RFC 3676)
Alessandro Vesely <vesely@tana.it> Mon, 18 July 2016 08:53 UTC
Return-Path: <vesely@tana.it>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2822112D191 for <ietf-822@ietfa.amsl.com>; Mon, 18 Jul 2016 01:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.589
X-Spam-Level:
X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it
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 2nBxlXKK6o7U for <ietf-822@ietfa.amsl.com>; Mon, 18 Jul 2016 01:53:35 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6AB12D09F for <ietf-822@ietf.org>; Mon, 18 Jul 2016 01:53:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1468832011; bh=buvwrSoveXFaQRuX3Tq9b4zc2JzgDgHr+sY8oWPoEGk=; l=725; h=To:From:Date; b=bjwa7t9+/iCHLLyDpLexMbMReOQqaED3DvqmYaAk//zD1l1oW//5X8ZQaH7pbzxJg QGmD2EX0mYCnx9Edmo9jT2JHbSu9o+nbeJ3GCk2R/RU6jEB+VQ7/7yBo3W1aNJQ0Jq 1XYG+PHSz0TEkvVovgdvxuM5fn5YVp4ZQ9Uh31S4=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 18 Jul 2016 10:53:31 +0200 id 00000000005DC050.00000000578C990B.00007DD5
To: ietf-822@ietf.org
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <e15a5fae-6e53-103d-f960-f1f385099e38@tana.it>
Date: Mon, 18 Jul 2016 10:53:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-822/JdGz69-kLgvDVp3bJSJMQ8N1PTI>
Subject: [ietf-822] Q: Space stuffing (RFC 3676)
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.17
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, 18 Jul 2016 08:53:36 -0000
Hi all,
Section 4.4 of RFC 3676 says:
On generation, any unquoted lines which start with ">", and any lines
which start with a space or "From " MUST be space-stuffed. Other
lines MAY be space-stuffed as desired.
What does "as desired" mean? If lines are treated at random, it is obviously
impossible to tell stuffed spaces from original indentation. (By comparison,
SMTP leaves no ambiguity on whether or not a line has to be dot-stuffed.)
My question is how is that extra leeway to be interpreted. What are the best
practices for space-stuffing? Let me recall that those ">From "s break many a
DKIM signature, so supporting RFC 3676 is de rigueur for mailers committed to
email authentication.
Ale
- Re: [ietf-822] Q: Space stuffing (RFC 3676) Alessandro Vesely
- Re: [ietf-822] Q: Space stuffing (RFC 3676) Tony Finch
- [ietf-822] Q: Space stuffing (RFC 3676) Alessandro Vesely