Subject: [lemonade] Re: Question about BURL document

From: Alexey Melnikov <[email-masked]>
Date: Sat, 15 Apr 2006 12:58:04 +0100

One more question:

In section 6 ("Response Codes"):

 >   554 5.3.4 Message too big for system
 >
 >      The message (subsequent to URL resolution) is larger than the per-
 >      message size limit for this server.

Shouldn't this be 552 5.3.4? RFC 2821 says:

      552 Requested mail action aborted: exceeded storage allocation
      554 Transaction failed (Or, in the case of a connection-opening
          response, "No SMTP service here")

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Apr 2006 12:06:54 +0100

RFC 3030 (CHUNKING) says:

   The BDAT command
   takes one required argument, the exact length of the data segment in
   octets.  The message data is sent immediately after the trailing <CR>
   <LF> of the BDAT command line.  Once the receiver-SMTP receives the
   specified number of octets, it will return a 250 reply code.

While BURL says:

   354 Waiting for additional BURL or BDAT commands

      A BURL command without the "LAST" modifier was sent.  The URL for
      this BURL command was successfully resolved, but the content will
      not necessarily be committed to persistent storage until the rest
      of the message content is collected.  For example, a Unix server
      may have written the content to a queue file buffer, but not yet
      performed an fsync() operation.  If the server loses power, the
      content can still be lost.

I thought that BDAT and BURL should behave almost identical. Differences 
such as this one will not help implementors, as it is so easy just to 
cut & paste BDAT code and modify it to support BURL.

There are currently no examples in BURL showing multiple BDAT/BURL, so 
the 354 response code doesn't appear in any example.
Can we change the BURL spec to return 250 in this case, to be the same 
as RFC 3030?

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 15 Apr 2006 12:58:04 +0100

One more question:

---

From: Ned Freed <[email-masked]>
Date: Sun, 16 Apr 2006 14:44:25 -0700 (PDT)

> Can we change the BURL spec to return 250 in this case, to be the same

I thought we had already noted this as needing fixing, since in addition to the
mismatch with BDAT it is a semantic mismatch with how 3yz statuses are used in
DATA (the next thing the client sends with DATA is the the remainder of the
current command, not a new command).

I further note that the description of intermediate replies in both RFC 821
and RFC 2821 is poor and could use some wordsmithing.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 16 Apr 2006 14:49:45 -0700 (PDT)

>           response, "No SMTP service here")

Yes, it should be 552. The one exception is a size error in reponse
to RCPT TO, which needs to be something other than 552 to work around the
bug in RFC 821.

				Ned