Re: Last Call: 'Message Submission' to Draft Standard

Bruce Lilly <blilly@erols.com> Thu, 10 February 2005 20:11 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01682; Thu, 10 Feb 2005 15:11:27 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzKz0-0004GN-Dg; Thu, 10 Feb 2005 15:32:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzKbh-0004By-1o; Thu, 10 Feb 2005 15:08:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzKZ2-0002i5-Su for ietf@megatron.ietf.org; Thu, 10 Feb 2005 15:05:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00997 for <ietf@ietf.org>; Thu, 10 Feb 2005 15:05:23 -0500 (EST)
Received: from smtp05.mrf.mail.rcn.net ([207.172.4.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzKt7-0004AF-Ks for ietf@ietf.org; Thu, 10 Feb 2005 15:26:09 -0500
Received: from 65.105.220.34.ptr.us.xo.net (HELO mail.blilly.com) (65.105.220.34) by smtp05.mrf.mail.rcn.net with ESMTP; 10 Feb 2005 15:05:24 -0500
Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id j1AK4R50000914(8.13.1/8.13.1/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Thu, 10 Feb 2005 15:04:52 -0500
Received: from localhost (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id j1AK41cF000913(8.13.1/8.13.1/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Thu, 10 Feb 2005 15:04:17 -0500
From: Bruce Lilly <blilly@erols.com>
Organization: Bruce Lilly
To: ietf@ietf.org
Date: Thu, 10 Feb 2005 15:03:59 -0500
User-Agent: KMail/1.7.2
References: <E1CuZjb-0007Wr-00@mx05.mrf.mail.rcn.net> <200501292256.02100.blilly@erols.com> <74b3ec79c496ca83c31481e610eada47@guppylake.com>
In-Reply-To: <74b3ec79c496ca83c31481e610eada47@guppylake.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200502101504.00644.blilly@erols.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: 7bit
Cc: Nathaniel Borenstein <nsb@guppylake.com>
Subject: Re: Last Call: 'Message Submission' to Draft Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit

On Thu February 10 2005 10:42, Nathaniel Borenstein wrote:
> On Jan 29, 2005, at 10:56 PM, Bruce Lilly wrote:
> 
> > Q: Is there a list of changes from RFC 2476? [As the request is to
> >    advance to Draft status, it would be nice to know if any changes
> >    are of such scope and substance as to warrant remaining at
> >    Proposed.  Such a list would also aid reviewers, to ensure that
> >    some subtle change is not overlooked.]
> 
> I don't have an exhaustive list, but the key change that led me to 
> originally request an update to this RFC can be found in Section 4.3:
> 
> > 4.3.  Require Authentication
> >
> >     The MSA MUST issue an error response to the MAIL FROM command if 
> > the
> >     session has not been authenticated using [SMTP-AUTH], unless it has
> >     already independently established authentication or authorization
> >     (such as being within a protected subnetwork).
> 
> The idea here is to establish that port 587 submission ALWAYS requires 
> authentication.  By differentiating it in this way from port 25, the 
> hope is that ISP's who block port 25 will not feel a similar need to 
> block port 587, thus streamlining the configuration of message 
> submission for roaming but authenticated users.  -- Nathaniel

There are some differences between what the draft says and that
description:
1. the draft explicitly permits operation on port 25
2. the draft section 4.3 doesn't mention port.

Specifically regarding the 4.3 MUST quoted above and the reply code,
and the necessary two independent implementations required for
advancement to Draft Standard status, do the implementations supporting
the request to advance to Draft in fact unconditionally require
authorization (i.e. independent of whether port 25 or 587 is used, and
regardless of administrative configuration other than specifying that the
implementation is to act as an MSA), and reply with code 530 (unspecified
extended response code) if authorization is lacking?

Reply code issues are what I had in mind when asking my question;
unfortunately my notes from my initial review of the draft don't
specifically indicate what I thought might have changed.  A comparison
of the draft to RFC 2476 is hampered by minor formatting differences.

However, from my notes on differences between various protocols...

On another matter, admittedly unchanged since RFC 2476, there seem to
be some undesirable discrepancies between submission and non-submission
ESMTP regarding extended response codes.  Draft section 3.4 states that
extended status code 5.6.2 means "Bad domain or address", whereas
RFC 3463 assigns that code the semantics "Conversion required and
prohibited" [RFC 3463 section 3.7].  The corresponding RFC 3463
extended response code for domain/address issues would be in the
5.1.XXX range [RFC 3463 section 3.2].  The draft specifies (sect. 5.1) use
of 5.6.2 with 554 for message header field address issues when an error
is reported after DATA.  SMTP (RFC 2821) does not require examination
of message header address field content except in the particular case
of a gateway [RFC 2821 section 3.8].  If the intent is that MSAs are
always to be considered to be gateways, then the draft should explicitly
say so (the term "gateway" does not appear anywhere in the draft).
[that would be a novel use of the term "gateway" in Internet mail; a
gateway usually has one side in a non-SMTP environment]
Conversely, if MSAs are not always to be considered as gateways, then
returning errors in response to message content is:
1. explicitly counter to the SHOULD NOT of RFC 2821 section 3.4 (bottom of
   page 18)
2. inappropriately associated with "conversion" semantics where no
   conversion is in fact required (indeed, other than adding trace fields,
   tinkering with message data by non-gateway SMTP receivers is disallowed
   [RFC 2821 section 2.3.8]).



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf