|
Re: Last Call: 'Message Submission' to Draft Standard
2005-02-15 16:37:35
At 8:48 PM -0500 2/11/05, Bruce Lilly wrote:
> Date: 2005-02-10 19:09
From: Randall Gellens <randy(_at_)qualcomm(_dot_)com>
At 3:03 PM -0500 2/10/05, Bruce Lilly wrote:
> 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.
But as written, section 4.3 specifies that when acting as an MSA,
authentication MUST (emphasis in original) be used, regardless of
port.
Section 4.3 says "unless it has already
independently established authentication or
authorization (such as being within a protected
subnetwork)." It's not uncommon for
organizations to deploy MSAs that treat all
internal connections as authenticated, even if
they allow travellers to connect in using port
587 and in that case require authentication.
> 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.
Again, "or not" is not allowed by the draft as written; implementations
with an "or not" provision would fail to comply with the "MUST" (they
would comply with a "SHOULD", however).
My understanding is that implementations are
permitted to have configuration options that
allow sites to deploy them in ways that violate
the RFCs, as long as they can be operated in a
conforming manner. For example, it is not
uncommon for POP implementations to have options
to have timeouts shorter than mandated, or to
enter UPDATE state on abort.
There are several implementations which have
default configurations which do comply with 4.3,
even if they have non-default configurations
which do not comply. Likewise, there are other
implementations which have a default
configuration which does not comply, but can be
configured to comply.
Aside: based on my understanding of the implementation report, there
are no two implementations which simultaneously comply with all of
the draft (or 2476) provisions, failing the "two independent
implementations" test for advancement to Draft Standard status.
From my understanding of the requirements, there
are multiple implementations which comply. This
is based on two points: (1) implementations can
be compliant even if they have options which
permit non-conformance; and (2) there must be at
least two implementations for each feature, but
it is not required that any individual
implementation meet every SHOULD. I believe
Message Submission meets the criteria on the
basis of either of these points; the fact that it
meets it on both is nice but not required.
> 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.
Well, there's an unresolved incompatibility with RFC 2821.
Following up on a disturbing sense of déja vu, I checked my records
and found the following commentary on RFC 2476 -- I believe that the
issues remain largely unaddressed by the draft:
---------------------
Date: Sat, 17 Apr 2004 22:54:44 -0400
From: Bruce Lilly <blilly(_at_)erols(_dot_)com>
Reply-To: blilly(_at_)erols(_dot_)com
Organization: Bruce Lilly
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
X-Accept-Language: en-us
MIME-Version: 1.0
To: John C Klensin <klensin(_at_)jck(_dot_)com>,
Randy(_at_)Qualcomm(_dot_)Com
Subject: Comments on RFC 2476 (Submission protocol)
X-Enigmail-Version: 0.83.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
X-UID: 407
X-Length: 3072
Hello,
First, the reason that I'm sending this
directly rather than to ietf-submit is that
I'm not subscribed to that list and in a few
hours I'll be on an airplane on a
business trip, and I may be incommunicado for a
week or so. By all means feel free
to forward my comments to the list and/or to
Chris Newman (whom I see has made some
list contributions about a month ago;
unfortunately the list archive on the IMC web
sit only displays "Chris Newman <Chris(_dot_)Newman(_at_)xxxxxxx>" and the
corresponding
mailto link is the useless
"mailto:Chris(_dot_)Newman(_at_)DOMAIN(_dot_)HIDDEN").
Following are my comments, in the order as presented in the RFC:
section 3.2, last NOTE:
Of course the MSA, in order to "properly handle
delayed bounces" will have to be
able to accurately determine the source, which
s probably only possible is some
authentication mechanism is used.
section 3.4 enhanced status codes:
This is the biggest problem that I see: the
basis is RFC 1893 (superseded by RFC
3463) status codes, which specifically address
only issues related to hard errors
in delivery. For example, there is no
standardized extended status code to address
the situation where an email address is not valid but a forwarding address is
available. 3463 does address the situation
where such a forwarding address is NOT
available (5.1.6), but not the situation corresponding to SMTP response 251.
2.1.6 might be an appropriate extended status code, but RFC 3463 specifically
states that X.1.6 " is only useful for permanent failures", i.e. 5.1.6.
One might hope that some unified set of
extended status codes might be developed
that could be used for multiple protocols.
Unfortunately, there seems to be an
inconsistency even within the mail protocols.
RFC 2476 lists extended status code
5.6.2 as "Bad domain or address", whereas RFC
3463 (and 1893) list that code as
"Conversion required and prohibited". That is very confusing, since RFC 3463
provides a range of extended codes (x.1.0 through x.1.8) for address/domain
errors.
It is also notable that RFC 2476 (e.g. section
4.1) provides no extended status
codes for transient failures or for success;
only class 5 -- permanent failure.
Another example of the extended status issue
shows up in RFC 2476 section 5.1,
which again addresses only permanent failures, not temporary failures (e.g.
DNS transient failures). It also doesn't distinguish between syntax errors
and address semantic errors.
Best regards,
Bruce Lilly
----------------------------------
There does seem to be a disconnect between the
meaning of 5.6.2 in the Message Submission
documents and the Extended Status Codes
documents, and this should be fixed in this
revision, perhaps by deleting specific extended
response codes from this revision, at least those
that overlap or conflict with those already
specified elsewhere.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
All generalizations are false, including this one.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|