Subject: [lemonade] WG last call on future delivery

From: "Glenn Parsons" <[email-masked]>
Date: Mon, 25 Oct 2004 09:08:09 -0400

Folks, 

A two week last call period is open until midnight EDT Nov 7th on: 

   SMTP Submission Service Extension for Future Delivery
   <draft-ietf-lemonade-futuredelivery-00.txt> 

Please forward any comments on this document to the WG mailing list. 

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 25 Oct 2004 16:15:59 +0200

> Please forward any comments on this document to the WG mailing list.

Three points, all fairly minor.

1. Why 1*9DIGIT? Doesn't that mean that the delay is limited to 
999999999 seconds? What makes this limit better than, say, 99999999 or 
9999999999?

I'd prefer not to have that limit unless there is a particular reason 
for it, so I suggest changing to 1*DIGIT.

2. In section 3, first paragraph, the document says that «SMTP clients 
will not use Future Delivery on this MSA». I suggest using SHOULD NOT 
or MUST NOT. Either is fine with me.

3. The document apparently intends that only authenticated clients can 
use future delivery. It doesn't say so. What it says is that the AUTH 
command must succeed. But RFC2245 lists one way to have AUTH succeed 
without really being authenticated, and (in theory) there may be other 
ways in the future.

One way to reword would be to talk about SASL authorization IDs. «The 
server SHOULD accept MAIL...AFTER only when the SMTP client has been 
tied to a known SASL authorization ID.»

But I wonder - why is this necessary? The document does not offer much 
of a rationale for this requirement. The mentioned security concern 
could be handled using a quota for anonymous/unauthenticated users.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2004 15:27:21 +0100

I have few comments on draft-ietf-lemonade-futuredelivery-00.txt, mostly 
editorial:

1). In section 3:

 >   An MSA that supports Future Delivery also supports the Authorization

Authentication (here and in few places below, however "authorization 
parameter" below is fine)

 >   service extension [4].  An MSA that advertises support for Future
 >   Delivery also advertises support for Authorization in the same EHLO
 >   reply.  An MSA that advertises support for Future Delivery without
 >   advertising support for Authorization is error, and SMTP clients will
 >   not use Future Delivery on this MSA.

This document has a reference to RFC 2119, however it doesn't officially 
state that it uses it and MUST/SHOULD language is not used in section 3 
of the document.

[...]

 >   The SMTP client then issues a MAIL command containing a future-
 >   delivery-interval parameter and an authorization parameter.

Putting a reference to SMTP AUTH here would be helpful, IMHO.

This sentence is also problematic, because authorization parameter is 
not required by SMTP AUTH ("MAY be specified"), while the 
future-delivery-interval parameter is required ("MUST be specified"). 
This also affects section 3.2.1, bullet # 3.

 >  If the
 >   authorization parameter is invalid, the MSA rejects the MAIL command.
 >   If the value of the future-delivery-interval parameter is greater
 >   that the MSA's advertised max-future-delivery-interval, or is
 >   otherwise invalid, the MSA rejects the MAIL command.  If both
 >   parameters are valid, and there are no other errors on the MAIL
 >   command, the MSA accepts that command.

2). I would suggest merging section 3.2 with section 3.1, because SMTP 
AUTH is required.

3). In section 3.2.2

 >   3) When an MSA receives a MAIL command containing a future-delivery-
 >      interval parameter, and the MSA has not yet authenticated the
 >      client via the AUTH command mechanism described in [4], then the
 >      MSA MUST reject the MAIL command for security reasons as described
 >      in [5].

The server should also be able to reply with "530" (Authentication 
required) as described in [4].

4). Section 6. ("References"): this section should be split into 
Normative and Informative references.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2004 15:35:08 +0100

> 999999999 seconds? What makes this limit better than, say, 99999999 or 

If this change is done, the document should say that any compliant 
server should use at least 32 bit unsigned integers to store such values.

Alexey

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 25 Oct 2004 07:43:34 -0700

--On 2004-10-25 4:15 PM +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

> 999999999 seconds? What makes this limit better than, say, 99999999
> or 9999999999?

Because 1*DIGIT is an unbounded value. What's a reasonable upper limit 
a server should accept? And therefore, what can a client expect a 
server to support?

999,999,999 seconds is 31.7 years. Live with it :-)

--lyndon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 25 Oct 2004 16:59:34 +0200

> server should use at least 32 bit unsigned integers to store such 

And if it's not done, the text about 0 can go away, because 999999999 
has exactly the same meaning.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 25 Oct 2004 17:11:15 +0200

> a server should accept? And therefore, what can a client expect a 

The server announces its upper limit. The document does not specify a 
minimum value for that upper limit, so so the client cannot currently 
expect the server to support anything. (Perhaps it should?)

> 999,999,999 seconds is 31.7 years. Live with it :-)

What makes 31.7 years better as a limit than 317 years or 3.17 years?

Alle of them are practically unbounded, so I'll be writing conditions 
and error handling that'll never be used, and test cases for ditto. Not 
very sensible.

Hm. I do see one possible rationale - the length of the mail command. 
(Page 4, first line.)

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Mon, 25 Oct 2004 12:25:18 -0700 (Pacific Daylight Time)

On Mon, 25 Oct 2004, Alexey Melnikov wrote:
>> 1. Why 1*9DIGIT? Doesn't that mean that the delay is limited to 999999999 
>> seconds? What makes this limit better than, say, 99999999 or 9999999999?
>> I'd prefer not to have that limit unless there is a particular reason for 
>> it, so I suggest changing to 1*DIGIT.
> If this change is done, the document should say that any compliant server 
> should use at least 32 bit unsigned integers to store such values.

Should it be "at least" or simply be specified as such.  Off the top of my 
head, 2^32 seconds is about 136 years.  I don't see much call for a 
136-year email delay; and it would make implementations easier if they can 
assume that they won't ever encounter more then 2^32 seconds.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 25 Oct 2004 16:26:18 -0700

> The server announces its upper limit.

Okay, I was asleep the first time I read the draft.

> Hm. I do see one possible rationale - the length of the mail command.

And that was the reason. 1*9 is really there as a stupidity filter.

--lyndon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 26 Oct 2004 10:03:34 +0200

> And that was the reason. 1*9 is really there as a stupidity filter.

Okay, I'll accept that.

My other two points stand. (And IMO, this one was the smallest of my 
three small points ;)

Arnt