(address list trimmed, ietf-smtp list added to close the loop
with the apparently non-working gmane gateway)
--On Friday, 20 April, 2007 18:33 +0300 Kari Hurtta
<hurtta+gmane(_at_)siilo(_dot_)fmi(_dot_)fi> wrote:
The following message is a courtesy copy of an article
that has been posted to gmane.ietf.smtp as well.
John C Klensin <john+smtp(_at_)jck(_dot_)com> writes in gmane.ietf.smtp:
--On Tuesday, 10 April, 2007 15:23 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
Second, there is no restriction in using it as part of a
continuation line. Example:
C: DATA
S: 352 Begin sending your data
[client uploads data]
S: 150-DKIM signature found!
S: 150-Please wait while we process your DKIM message!
S: 150-Waiting for trust server to respond...
S: 150-Still waiting for trust server to respond...
C: 550-Sorry, The DKIM POLICY has failed this
transaction C: 550 Please see
http://trust-r-us.com/msgid=123213123
Who knows? Is this not possible? It is out of the whelm of
real possibility?
No, it is is clearly not impossible. However, it raises two
issues in addition to the one about the codes all being the
same which, IMO (and in the text of 2821), arises from one of
them.
Perhaps off topic, but it seems that sendmail uses 0xx
with similar way if VERB command is given
EHLo xx
250-Hurtta06k.keh.iki.fi Hello localhost [127.0.0.1], pleased
to meet you 250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5
250-DELIVERBY
250 HELP
VERB
250 2.0.0 Verbose mode
MAIL FROM:<hurtta(_at_)localhost>
250 2.1.0 <hurtta(_at_)localhost>... Sender ok
RCPT TO:<root>
050 <root>... aliased to hurtta
250 2.1.5 <root>... Recipient ok
( Seems that http://www.iana.org/assignments/mail-parameters
lists VERB )
Well, this is, IMO, precisely on-topic because it illustrates
something else.
Note that, in this example, VERB is explicitly advertised as an
available extension in response to the EHLO command, then
invoked by a client-issued command. While there is no RFC
describing VERB, we can deduce that it (or one of the other
advertised extensions) explicitly authorizes several things that
are not permitted by 821/ 2821/ 2821bis-02 SMTP:
(1) Use "hurtta(_at_)localhost" in the MAIL command and
"root" in the RCPT command. Both are prohibited by
unextended SMTP unless this is a submission server
because they do not contain FQDNs. If it is a
submission server communicating with a local mailbox
(which I would guess is the case), then all bets are off
-- none of the rules that apply to SMTP on the public
Internet are required to apply here even though applying
them might well be a good idea.
(2) The use of at least some reply codes with first
digits that are not given clear definitions in 821 or
2821 is permitted. Here, 0yz is used, but the extension
could have authorized use of 1yz, or even 9yz or Ayz,
for its own purposes.
(3) Since 0yz is not being used as part of a
continuation, there are actually two separate replies
being returned in response to the RCPT command, the
second one asynchronously (without another command being
issued first). So the extension is either authorizing
asynchronous replies or, more likely, some class of
reply codes that are simply ignored, with the client
continuing to read reply lines, without issuing a new
command, until a standard reply code appears. An
extension could, of course, authorize either one.
The key in both cases (2) and (3) is that the server announces
that it is able to support the extension and the client
announces that it can support it and wants it.
That makes this a good example of how an extension can be used
to permit three-digit reply codes that are not specified in 2821
(or in 821) and how it can assign semantics to those codes that
are not specified in the standards. It also shows that
extensions of this type can be made to work and, indeed, that
they are fairly established practice (I'm aware of other
implementations of VERB, including that in one SMTP gateway I
worked on, but my memory doesn't extend to whether their
semantics are identical or interoperable with what seems to be
going on here).
It doesn't tell us a thing about the use of 0yz codes, 1yz
codes, or 9yz codes in the absence of any extension.
1xx was not selected for that usage. So 050 is really used,
but is 150 used on somewhere?
Doesn't make any difference, IMO. What this shows is that 050
is used _with an extension_. Clearly 150 could be used with an
extension, either this way (presumably as a code that is ignored
for command-buffering / turnaround purposes), or as a keep-alive
code in a multiline response, or otherwise. But, in this
context, only if there were an extension and the extension
definition specified it that way. Our disagreement, if we have
one, is about whether some or all of
(i) the use of 1yz, without specific authorizing
extensions, represents long-term common practice without
a "continue" command by the client to reestablish the
command-response pairing.
(ii) the use of 1yz responses at all without specific
authorizing extensions, represents common practice at
all.
(iii) multiline responses with different codes and
without specific authorizing extensions, (either in
general or if all of the codes are identical except for
zero or more 150 ones) represent long-term common
practice that does not cause SMTP-sender problems.
If they are not _all_ true, then we end up with either a
procedural or a technical difficulty with this conversation and
maybe with the document. Partially because it seems so obvious
to me that these uses of 0yz or 1yz codes should be supported by
an extension to be sure that the client and server are in
agreement about how to interpret what is being done, I continue
to believe that we have a communications problem here rather
than a substantive one, but I may be wrong and may not
understand what is being proposed and why.
In any event, (i) is problematic even if there were long-term
common practice because the only text in either 821 or 2821 that
discusses those codes appears to attribute fairly specific
semantics to them to preserve the command-response pairing.
Their use without the semantics is, IMO clearly, additional or
different functionality to what 2821 (and 821) specify.
Procedurally, such functionality cannot be added at this point
without bouncing 2821bis back to "proposed".
If we could get past (i), (ii) would require that the fans of
1yz codes demonstrate that their use was interoperably and
consistently implemented in a way that would be consistent with
the existing 2821 text. I haven't seen that claim made yet in a
way that would support an interoperability report for Draft
Standard. The fact that there is no RFC describing exactly how
they are used, to which an implementation can claim conformance,
makes such an interoperability claim doubly difficult but not
impossible: if there really are independent server, and
independent client, implementations out there that do the right
thing, are consistent with a clear definition in _some_
specification, and don't cause problems for other
implementations would, I think, be enough to get clarifying
words added to 2821bis. But, again, the issue of (i) would
have to be satisfied first, i.e., it would also need to be
demonstrated that this was existing functionality in (or at
least clearly consistent with) 2821 and not an innovate wrt that
document, no matter how broadly deployed.
The third issue has been discussed at length but, to identify a
personal perspective, language in 2821 (and 821) that says that
"in many cases" it is sufficient to look at the last code,
followed by a sentence that reads "The client will be able to
identify
these cases" (referring to the reply text) "from the current
context." neither proves nor disproves the "all codes must be
the same" theory. It is clearly sloppy work (mea culpa as far
as 2821 is concerned), both because the "in many cases"
terminology doesn't give a clue about how to identify the
_other_ cases (which presumably exist) but also because that
third sentence doesn't give a clue about how the client is to
figure out how to identify applicable cases in which the text
may be important enough that some of the lines can be ignored.
Application of the robustness principle as the usual
disambiguator of such things says that the server ought to send
homogeneous codes because that eliminates any sensitivity to
"first", "middle", "last" or "all". It may be that the receiver
side of the robustness principle should cause us to suggest that
the client better be ready to handle a mixture of codes but, if
we do that, I think we need to either figure out what "in many
cases" actually means or specify a rule about which one is
significant. If we make that "last" -- eliminating the "in
many cases" languages -- we had better be sure that there are no
"first" implementations out there (and I think we already have
evidence that there are) and we had better not be specifying new
functionality through the back door. I don't see a way to meet
those conditions, but perhaps that is just lack of imagination.
john