Subject: smtpupd-09 requires detailed reply code inspection

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Jan 1999 10:26:39 -0000

> message data MUST NOT be sent unless a 354 reply is received.

This requirement prohibits the behavior of many existing clients.

If a server (in violation of RFC 821) sends (e.g.) a 387 reply, these
clients will (as encouraged by RFC 821) treat 387 the same way as 354.

Fix: ``message data MUST NOT be sent if the reply to DATA begins with 4
or 5.''

---Dan

---

From: Brad Knowles <[email-masked]>
Date: Sat, 30 Jan 1999 12:49:19 +0100

>Fix: ``message data MUST NOT be sent if the reply to DATA begins with 4

    I can't believe that I'm actually agreeing with Dan, but the policy
has *long* been that anyone who paid any attention whatsoever to the
second and third digits of a response was being extremely foolish, and
that only the first digit had any real significance -- 4xx means a
temporary error, 5xx means permanent, etc....

    If DRUMS is now recommending that this policy be changed, I think
you're going to have a very long wait -- this is virtually the entire
world of Internet e-mail you're talking about, and it takes a few billion
years to stop the rotation of a planet and reverse it, and I suspect it
would take a few billion more to stop the revolution of a planet around
it's star and reverse that course.

-- 
  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: John Beck <[email-masked]>
Date: Sat, 30 Jan 1999 08:52:00 -0800

smtpupd-09> message data MUST NOT be sent unless a 354 reply is received.

Dan> This requirement prohibits the behavior of many existing clients.

Dan> If a server (in violation of RFC 821) sends (e.g.) a 387 reply, these
Dan> clients will (as encouraged by RFC 821) treat 387 the same way as 354.

Dan> Fix: ``message data MUST NOT be sent if the reply to DATA begins with
Dan>      4 or 5.''

Brad> I'm actually agreeing with Dan, ... the policy has
Brad> *long* been that anyone who paid any attention whatsoever to the second
Brad> and third digits of a response was being extremely foolish, and that
Brad> only the first digit had any real significance -- 4xx means a temporary
Brad> error, 5xx means permanent, etc....

I agree that that the 10s and 1s digits should not matter here; that a
general 3yz reply should be the key, not 354 specifically.

-- John

---

From: Tony Hansen <[email-masked]>
Date: Sat, 23 Jan 1999 02:59:43 -0500

> general 3yz reply should be the key, not 354 specifically.

Make this the magic fourth person nodding in agreement.

	Tony Hansen
	[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jan 1999 13:46:47 -0500 (Eastern Standard Time)

Tony,

Since you are the "magic fourth person", let me re-state the
question...

What you want is to have the text read something like:

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

is that correct?  Would you prefer

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

Obviously, I'm trying to state this narrowly, rather than as the
"no 4yz or 5yz" proposed by Dan.  I have no idea what a client
should do if it gets a response to DATA like
    200 Ok, I don't expect a body

But I'm pretty sure it should not start transmitting
information.  And I can even imagine wanting to do such a thing
in conjunction with some bizarre, but plausible, SMTP
extensions. 

Anyone significantly opposed (or having a strong preference
between the two options above, or preferring other text which
they will submit, or wanting to clarify why Dan's "no 4 or 5"
approach is better) please speak up.

     john

---------------------

---

From: John Beck <[email-masked]>
Date: Sat, 30 Jan 1999 10:51:05 -0800

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

I like this text.

-- John

---

From: Brad Knowles <[email-masked]>
Date: Sat, 30 Jan 1999 19:53:09 +0100

>  (i.e., one of the form 3yz, normally 354) is received.

    I like this one.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 30 Jan 1999 11:31:39 -0800

>Klensin> (i.e., one of the form 3yz, normally 354) is received.

Me too. It's much better to give a hint here.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Jan 1999 20:51:07 -0000

The reason that

   message data MUST NOT be sent unless the reply to DATA begins with 3

is worse than

   message data MUST NOT be sent if the reply to DATA begins with 4 or 5

is that it puts an unnecessary restriction on client implementations.

Real-world example #1 is qmail-remote, which handles codes as follows:

   (1) If code >= 500, stop with a permanent error.
   (2) If code >= 400, stop with a temporary error.
   (3) Proceed.

Real-world example #2 is zmailer; code_to_status() converts all 2xx and
3xx codes into EX_OK.

There's no reason for these clients to change. RFC 821 requires that
writers send correct syntax; it does _not_ require that readers reject
incorrect syntax.

---Dan

---

From: Russ Allbery <[email-masked]>
Date: 30 Jan 1999 17:38:56 -0800

>   (i.e., one of the form 3yz, normally 354) is received.

I would prefer the second form; the additional bit of information is
helpful.

Obviously no server should be sending a 2xx or 6xx or whatever reply to a
DATA statement, but if it does, it's almost certainly highly confused and
just going and sending a bunch of message data the wrong thing to do.

I think the complexity issue is arguable.  "If first digit is 3 then
proceed" is a simpler test than looking for 4 or 5, and checking for 4 or
5 if the first digit *isn't* a 3 is then in the realm of error handling
behavior.  Requiring a 3xx response therefore would seem to me to be
optimizing for the common case, from the perspective of client
implementation.

> But I'm pretty sure it should not start transmitting information.  And I
> can even imagine wanting to do such a thing in conjunction with some
> bizarre, but plausible, SMTP extensions.

Agreed.

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

---

From: Philip Hazel <[email-masked]>
Date: Sun, 31 Jan 1999 11:02:23 +0000 (BST)

>    (2) If code >= 400, stop with a temporary error.

A slightly different real-world approach. For the DATA command, Exim
handles codes as follows:

  (1) If first digit of code == 3, proceed.
  (2) If first digit of code == 4, generate a temporary error.
  (3) Generate a permanent error.  

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 01 Feb 1999 01:14:26 +0300

> >  (i.e., one of the form 3yz, normally 354) is received.

I like it as well.

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