Subject: Re: editing status of 821bis, draft -10.

From: Maurizio Codogno <[email-masked]>
Date: Mon, 1 Feb 1999 11:20:21 +0100 (MET)

:From: John C Klensin <[email-masked]>

:	 (iv) Upper bound on "seconds" has been changed to 60
:	 (not 61), per list discussion.  Years are still
:	 four-digits and will stay that way unless the list
:	 discussion converges on something else.  The increase
:	 to 60 seconds includes an explicit note about leap
:	 seconds.

I have a question about this.

Does anybody know why time_t allows a double leap second, and 
whether a date 10:00:61 can actually be produced?
Given that for any implementation the work required to check for 60 or 61
is the same, I'd be for allowing 61 too.

(OTOH, I don't understand why having a 5-digit - and not a 6-digit...
year number improves things)

:Finally, a general observation, which has been made before.
:821bis, like every other internet standard (or documents heading
:in that direction) is designed to specify standard behavior
:under normal, on-the-internet conditions.  We could clearly
:insert "unless the network crashes mid-operation" or "unless the
:disk crashes" or "assuming the sun doesn't go nova" in every
:specification-statement, but it wouldn't add much and would make
:already-too-complex documents much harder to read. 

Couldn't you put a note at the beginning of the document, remembering
it explicitly?

As for the formulation

>  message data MUST NOT be sent unless a continuation reply
>  (i.e., one of the form 3yz, normally 354) is received.

Me five (six? I lost the count)

ciao, .mau.

---

From: Robert Elz <[email-masked]>
Date: Mon, 01 Feb 1999 21:59:58 +1100

Date:        Mon, 1 Feb 1999 11:20:21 +0100 (MET)
    From:        Maurizio Codogno <[email-masked]>
    Message-ID:  <[email-masked]>

  | Does anybody know why time_t allows a double leap second, and 
  | whether a date 10:00:61 can actually be produced?

Sometime in the past someone misinterpreted a statement along the lines
of "it is possible to have at most two leap seconds a year" as suggesting
that a double leap second could occur, when what was really meant was
that there could be one at the end of June, and one at the end of December.
60 is the max that can occur (unless the time standards are changed
again of course, then anything is possible).

  | >  message data MUST NOT be sent unless a continuation reply
  | >  (i.e., one of the form 3yz, normally 354) is received.
  | Me five (six? I lost the count)

And I.    A client that sends data in response to a 200 reply (and from
the way it was expressed, apaprently even a 100 reply) is horrendously
broken.

True, a server which sends a 200 reply is also broken, that doesn't excuse
broken clients.

Imagine you're talking to a client that gets DATA, says
	 200 No data needed or permitted to send to that address
and returns to command mode, whereas the broken client sees this
is not a 400 or 500 reply, and goes ahead, and sends the data.   Then
also imagine that the data just happens to look like a series of SMTP
commands...

	MAIL FROM:<...>
	RCPT TO:<...>
	DATA

for whatever reason.   Might not the server cause mail to be dispatched
to some entirely inappropriate addresses in that scenario?   Sending the
message data must (MUST) be prohibited unless the server has indicated that
it is ready for the data, which means by sending a 300 reply.

kre

---

From: "Michael Quinlan" <[email-masked]>
Date: Mon, 1 Feb 1999 07:02:28 -0700

>From: Maurizio Codogno [mailto:[email-masked]]
>

That was a mistake by the ANSI C committee. No, time 10:00:61 can never be
produced.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 1 Feb 1999 17:00:28 -0000

> 	 200 No data needed or permitted to send to that address

You admit that this imaginary server is blatantly violating RFC 821, so
why do you blame the client for subsequent problems? Absurd.

> A client that sends data in response to a 200 reply (and from

No. You are inventing requirements that don't appear in RFC 821. There's
no reason that qmail and zmailer should change their behavior here.

Jon Postel understood the difference between _sending_ syntax extensions
(prohibited) and _accepting_ syntax extensions (allowed). Why don't you?

---Dan

---

From: Russ Allbery <[email-masked]>
Date: 01 Feb 1999 16:34:25 -0800

> why do you blame the client for subsequent problems? Absurd.

I have had the experience, primarily when talking to Windows NT machines
or other platforms with a somewhat iffy TCP stack implementation, of
having the sender and receiver in a network conversation get desynced to
the point of losing the command/response interplay.  I do not consider it
beyond the realm of possibility that this could happen between e-mail
servers.

If the server just sent a 200 in response to DATA, it's obviously highly
confused about the current state of your conversation with it.  Starting
transfer of e-mail to a system that has *demonstrated* that it's highly
confused is a bad idea.  Not only is the system not going to be in a state
where it can accept that e-mail, but chances are quite high that it will
end up trying to interpret the e-mail as commands.  With possibly nasty
results depending on the content of the e-mail, and with a non-zero
possibility of compromising whatever marginal privacy e-mail has by
dumping the contents of the e-mail message into an error log somewhere.

It's not a question of blame; it's the question of appropriate action in a
failure scenario.

I don't find the argument that just looking for 4xx and 5xx returns is
simpler to implement than always looking for 3xx returns persuasive; in
fact, looking for 3xx first is a (*very* minor) simplification of the
logic flow for the common case.

-- 
Russ Allbery ([email-masked])         <URL:http://www.eyrie.org/~eagle/>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Feb 1999 04:00:28 -0000

There's an installed base of MTAs delivering millions of messages a day
through SMTP clients that treat 2xx just like 3xx.

Declaring those MTAs non-compliant, and demanding that they be changed,
means punishing the users.

What's the benefit? Interoperability with imaginary servers that violate
the existing standards and that are unable to receive mail anyway?

Russ Allbery writes:
> the point of losing the command/response interplay.

Then that TCP stack is a disaster, and it has to be fixed. Checking for
354 in response to DATA doesn't solve the problem.

> logic flow for the common case.

If the code is read as an integer then

   code < 400

is simpler than

   code / 100 == 3

with the advantage that it works the same way for MAIL, RCPT, and DATA.
If the code is read as an ASCII string then

   code[0] < 52

is just as simple as

   code[0] == 51

with the same advantage. Notice that zmailer's code_to_status() converts
2xx and 3xx to EX_OK without knowing what command it's dealing with.

---Dan

---

From: Russ Allbery <[email-masked]>
Date: 01 Feb 1999 20:54:39 -0800

> What's the benefit?

Okay, that's a fair point.  The only reasonable answer that I personally
have to that is that there is also an installed base of MTAs that do all
sorts of really broken things, allow all sorts of really broken things,
and regularly mangle mail or create interoperability disasters because of
it.  Those are often *different* MTAs than the ones you're referring to,
agreed.  But there is something to be gained *for the user* in making it
crystal clear in the standard that obeying the standard means actually
*looking* at one's SMTP conversation, not just checking for heuristics
that catch the responses you're expecting to see.

I'm biased.  I'm a paranoid programmer, and a paranoid administrator.  I'd
much rather see return codes mean what they say they mean, and have
obvious implementation errors be rejected rather than allowed to live on
via liberal acceptance policies.  There are just too many times when
something that looked safe to allow turned out to cause a nightmare down
the road when some other part of the standard could have been improved.

So I have *no* specific argument to defend my stance on this particular
case.  I will grant you that without question.  My stance is more from the
perspective of the way I think protocol-complaint software should be
written, namely reading and interpreting the wire protocol and performing
the action that makes sense given as full of possible understanding of the
response, not the action that is indicated by the simplest working
heuristics.

If the protocol is so complicated so as to make this an unnecessary burden
on the implementor, the protocol should be fixed.  But fixing the protocol
by ignoring intended differentiation in its return codes just bothers me.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 2 Feb 1999 09:56:43 +0100

>through SMTP clients that treat 2xx just like 3xx.

    Just because they're delivering mail doesn't mean that they're not
broken, it just means that they're not so heinously broken that they
completely fail to function when connected with sufficiently flexible
servers on the other end.

    IMO, the standard should be strong and crystal clear in this regard,
and specify levels of compliance with regards to returning a 3xx code as
a MUST, as well as specifying that the sender MUST NOT transmit mail if
they get anything other than a 3xx code.

    It is up to the implementors of zmailer, etc... to read the new
standard, understand it, and implement it.  If they don't like what they
see, they are free to join the DRUMS WG and propose alternative changes.

    IIRC, the proposal on the table wouldn't outright break zmailer (or
any other MTA that I know of), it would simply declare them "broken". 
Now, there's a difference between being technically "broken" and being so
broken that you fail to function at all.  It would be up to the
implementors of the MTAs to fix their code so that they are no longer
"broken".

-- 
  These are my opinions -- not to be taken as official Skynet policy
 ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin   Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
                The Sky is no longer the limit

---

From: [email-masked]
Date: Tue, 2 Feb 1999 12:28:54 +0200 (GMT)

Brad Knowles wrote:
( on topic of some systems treating 2xy and 3xy as 'OK, go ahead' without
  regard of state.. )
> see, they are free to join the DRUMS WG and propose alternative changes.

	I am here.
However that part of the smtp client has existed long before I became
de-factor maintainer of the ZMailer.
 
(degrees of "brokennes")

Yeah, making the smtp-client more strict in what it accepts as replies
from the servers will get priority only when some *BROKEN* smtp-server
sends back wrong responses.  Such server would be in trouble anyway,
so likely they would not exist except spodarically.

In the "internet way" I am writing clients and servers which try to
be flexible in what they accept, but strict in what they send.
Some parts of the system can be tuned to be extremely strict in what
they accept, too..

> |o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|

/Matti Aarnio <[email-masked]>

---

From: "Barry Leiba" <[email-masked]>
Date: Fri, 5 Feb 1999 14:04:36 -0500

> means punishing the users.

[I'm not picking on this particular response; this was just a convenient
quote in relation to which to ask my question.]

I need a clarification in this regard:  What is our goal?  Is it
(1) to document existing behaviour, and, in the process, to tighten up the
spec -- with the stipulation that any implementation that was technically 
compliant with RFC821 will be technically compliant with RFC821bis -- or
is it
(2) to document what the intended and desirable behaviour is, taking existing
behaviour into account, but accepting that implementations that met the letter,
but not the intent, of RFC821 might not be technically compliant with RFC821bis?

I think our goal *should be* (2).  If, in fact, our goal is (1), then perhaps
the various arguments stating, "You can't change [this] because the change would
make [some implementation] technically non-compliant," are correct.  OTOH, if
our goal is (2), then perhaps it's a Good Thing to say, "We know that this
makes some implementations technically non-compliant, but, in the interest
of being absolutely clear about the intent of [this issue], it is important to
clarify the matter and to suggest that implementors meet the letter of this
clarification.

> the existing standards and that are unable to receive mail anyway?

The benefit is that one cuts one's losses.  As has been said, if a server
responds with something completely unexpected and out of spec, the server
is clearly confused.  It's unlikely to be useful to send message data at 
that point, and it's possible (and even likely) to be a very bad idea.

No, one is not likely to encounter this situation.
That doesn't mean it shouldn't be planned for.

Suppose there's a program that asks, "Do you really want to wipe your
hard drive?  (Reply 'y' or 'n'.)"  Would you be pleased if that program
responded to the answer 'm' by assuming you meant 'y'?  I know I wouldn't.

Barry Leiba, Multimedia Messaging   ([email-masked])
http://www.research.ibm.com/people/l/leiba

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Feb 1999 21:41:35 -0000

Barry Leiba writes:
> implementations that met the letter, but not the intent, of RFC821

Jon Postel said that

   * it was inexcusable to _generate_ syntax extensions but
   * it was nice to _accept_ syntax extensions.

For example,

   * servers MUST NOT use codes other than 354 to accept DATA but
   * clients are allowed, even encouraged, to handle other codes.

A simple client could treat 200 the same way as 354; or the same way as
421; or the same way as 554. It is entirely the server's responsibility
to avoid using this extension.

_That_ is the letter and spirit of RFC 821. You're insulting the memory
of Jon Postel when you claim that RFC 821 intended to impose useless
requirements.

> The benefit is that one cuts one's losses.

Those losses do not exist. You're talking about an imaginary situation.

---Dan

---

From: [email-masked] (WJCarpenter)
Date: Fri, 5 Feb 1999 13:59:56 -0800

djb> A simple client could treat 200 the same way as 354; or the same
djb> way as 421; or the same way as 554. It is entirely the server's
djb> responsibility to avoid using this extension.

That would be a semantic difference, not a syntax extension.
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 06 Feb 1999 01:09:01 +0300

>    * it was nice to _accept_ syntax extensions.

I agree.

>    * servers MUST NOT use codes other than 354 to accept DATA but

Right

>    * clients are allowed, even encouraged, to handle other codes.

Right. But the question is HOW they should handle them.

> to avoid using this extension.

IMHO, standard should be precise about handling "unexpected" codes.

Dan, IMHO, your interpretation is wrong (the majority of people disagreed with
you).
Evil server, may try to use this to crash client/MTA. (I am not talking about
particular implementation. The situation is theoretical, but possible. Bugs in
IE or Netscape Communicator come to mind. Authors didn't deal with evil servers
and everybody knows what happened).

My opinion is that not only server should be strict in what it sends, but client
also should check for garbage.

> Those losses do not exist. You're talking about an imaginary situation.

Yes, we do.

--
Best Regards,
Alexey Melnikov
+----------------------------------------------------+
|SMTP/POP3/IMAP4/ACAP  | Epsylon Technologies, Russia|
|servers creation team |     http://www.taxxi.com    |
|----------------------------------------------------|
|Imap Development Kit (my own product)               |
|http://194.87.43.111/homerus/mail/idk/index.htm     |
|----------------------------------------------------|
|Fax (in San Diego, California): 1 (619) 8393837     |
+----------------------------------------------------+

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Feb 1999 06:55:11 -0000

Alexey Melnikov writes:
> Evil server, may try to use this to crash client/MTA.

Irrelevant. The clients under discussion don't crash. They merely treat
2xx and 3xx the same way.

(A high-quality implementation won't crash under any circumstances. This
is what ``be liberal in what you accept'' is referring to, according to
RFC 1123, section 1.2.2.)

---Dan