Re: [ietf-smtp] [Editorial Errata Reported] RFC5322 (3400)

Pete Resnick <presnick@qti.qualcomm.com> Tue, 27 November 2012 23:02 UTC

Return-Path: <presnick@qti.qualcomm.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 34ED51F0425 for <ietf-smtp@ietfa.amsl.com>; Tue, 27 Nov 2012 15:02:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level:
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQXsRNKxGCYo for <ietf-smtp@ietfa.amsl.com>; Tue, 27 Nov 2012 15:02:18 -0800 (PST)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3907521F8452 for <ietf-smtp@ietf.org>; Tue, 27 Nov 2012 15:02:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1354056389; x=1385592389; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Sr/OwdsdDHWq3zXcAbcvue56w2GcUgeRt4X1SfhDBN8=; b=yb2F3p46QgeqTTcdP6fui+TBAXpVTaKQdinE8gkWZBoQAysb4AuIeVyV dJ2Mai/P2D2PbGVxWuSjmacYYlaw2TEf6oe90XSQRAQF0UQjVxezS9NRt F9Lv6R5Wqf+KZqjMVZ70EfDbcsJh8azqE0g/+o9VwccOmpDIoLxULgIiy 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="9380662"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 27 Nov 2012 14:46:13 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="374397697"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Nov 2012 15:02:02 -0800
Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 27 Nov 2012 15:02:01 -0800
Message-ID: <50B54668.4050006@qti.qualcomm.com>
Date: Tue, 27 Nov 2012 17:02:00 -0600
From: Pete Resnick <presnick@qti.qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: ietf-822@ietf.org
References: <20121107020448.E2B9BB1E003@rfc-editor.org>
In-Reply-To: <20121107020448.E2B9BB1E003@rfc-editor.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
X-Mailman-Approved-At: Tue, 27 Nov 2012 15:04:31 -0800
Cc: calestyo@scientia.net
Subject: Re: [ietf-smtp] [Editorial Errata Reported] RFC5322 (3400)
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 27 Nov 2012 23:02:20 -0000

[Bcc'ed to ietf-smtp@ietf.org; please discuss over on ietf-822@ietf.org.]

Folks,

The following erratum was posted for 5322. I'm inclined to reject it 
since this discussion actually took place during DRUMS (17-18 March 1998 
in a thread with a subject of "Small Clarification to msg-fmt-04" if you 
are inclined to look) and the consensus outcome as far as I could tell 
(as document editor) was that messages without a final CRLF were SMTP's 
problem. However, 5321 (and 2821) 4.1.1.4 says:

    The mail data are terminated by a line containing only a period, that
    is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is
    actually the terminator of the previous line (see Section 4.5.2).
    This is the end of mail data indication.  The first <CRLF> of this
    terminating sequence is also the <CRLF> that ends the final line of
    the data (message text) or, if there was no mail data, ends the DATA
    command itself (the "no mail data" case does not conform to this
    specification since it would require that neither the trace header
    fields required by this specification nor the message header section
    required by RFC 5322 [4] be transmitted).  An extra <CRLF> MUST NOT
    be added, as that would cause an empty line to be added to the
    message.  The only exception to this rule would arise if the message
    body were passed to the originating SMTP-sender with a final "line"
    that did not end in <CRLF>; in that case, the originating SMTP system
    MUST either reject the message as invalid or add <CRLF> in order to
    have the receiving SMTP server recognize the "end of data" condition.

Allowing the originating SMTP system to reject the message as invalid 
seems in conflict with 5322 on this point. So my rejecting this erratum 
will simply end us up with an erratum against 5321.

I'm inclined to hear opinions.

pr

> The following errata report has been submitted for RFC5322,
> "Internet Message Format".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5322&eid=3400
>
> --------------------------------------
> Type: Editorial
> Reported by: Christoph Anton Mitterer<calestyo@scientia.net>
>
> Section: 3.5.
>
> Original Text
> -------------
>     message         =   (fields / obs-fields)
>                         [CRLF body]
>
>     body            =   (*(*998text CRLF) *998text) / obs-body
>
>
> Corrected Text
> --------------
>     message         =   (fields / obs-fields)
>                         [CRLF body]
>
>     body            =   (*(*998text CRLF) *998text) / obs-body
>
> It is RECOMMENDED that message bodies are terminated by CRLF, though this is in principle not necessary (this does not apply to messages consisting only of a header section, as header fields are always CRLF terminated).
>
> Note however, that when transporting messages via SMTP the last lines of message bodies MUST be terminated by CRLF as specified int RFC 5321, section 4.1.1.4.
>
> Notes
> -----
> Hi folks.
>
> AFAIU, the definition of body allows message bodies (not header sections) that end without CRLF.
>
> RFC5321 section 4.1.1.4. however states: "The mail data are terminated by a line containing only a period, that is, the character sequence "<CRLF>.<CRLF>", where the first<CRLF>  is actually the terminator of the previous line".
>
> So SMTP forbids, what this RFC allows.
> I guess the SMTP RFC can't be changed here and it makes no particular sense to restrict RFC5322 on the other hand.
>
> My suggestion was to add this clarification.
>
> Perhaps a similar one should be added to RFC5321, telling that Internet Messages themselves wouldn't need the last CRLF.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5322 (draft-resnick-2822upd-06)
> --------------------------------------
> Title               : Internet Message Format
> Publication Date    : October 2008
> Author(s)           : P. Resnick, Ed.
> Category            : DRAFT STANDARD
> Source              : IETF - NON WORKING GROUP
> Area                : N/A
> Stream              : IETF
> Verifying Party     : IESG
>    

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478