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

From: Randall Gellens <[email-masked]>
Date: Thu, 10 Feb 2005 16:31:55 -0800

At 3:03 PM -0500 2/10/05, Bruce Lilly wrote:

>  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?

Both the draft and RFC 2476 allow submission to use 25 instead of 
587, but state that "normally" 587 is used, and allow 25 to be used 
in order to accommodate implementations that are hard to configure. 
Both say that port 587 is reserved for submission.  So, 587 is the 
normal case for submission, and 25 is an exceptional case.

Please see the implementation report for the details, but I believe 
most implementations had various configuration options that allowed 
them to require authentication or not.

>
>  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]).

It is not the intent of either this draft or RFC 2476 to say that 
MSAs are always gateways; rather, the intent in both is to recognize 
the reality that organizations sometimes see a need to examine and 
potentially modify messages submitted using their servers, and to 
make a clear distinction between this case, and the 
examination/modification of messages being relayed.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Randall Gellens <[email-masked]>
Date: Thu, 10 Feb 2005 16:31:20 -0800

At 10:24 PM +0100 2/10/05, Harald Tveit Alvestrand wrote:

>>  This sounds like a change that requires recycling at proposed.
>
>  I could argue this both ways; every implementation that is valid 
> under the draft standard would also be a valid implementation under 
> the proposed one, but not vice versa; this is the same thing as 
> with every other standard where some choices are clarified or 
> restricted when moving to Draft.

All implementations known to the authors meet this change, thus 
remaining compliant.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 10 Feb 2005 16:41:42 -0800

>     some subtle change is not overlooked.]

I noticed this was missing, and added it to the revision for comments 
received during last call.  Here is what it says:

Appendix A: Changes from RFC 2476

* Support for [SMTP-AUTH] is now mandatory
* Message-ID changed from MAY to SHOULD

>  S: The table in section 7 omits MTRK (RFC 3885), probably others. At
>     minimum, the authors should review SMTP extensions and update that
>     table before publication.

This might be a good idea, although it will require more text in 
Appendix A.  Also, new SMTP extensions are supposed to indicate if 
they are valid with SUBMIT.

>
>  N: Use of "SMTP envelope" in place of "envelope" (3 places) would
>     avoid possible confusion.

OK, thanks for the suggestion.  It seems like a useful clarification.