Subject: FW: [lemonade] WG last call on future delivery

From: "White, Gregory (Gregory)** CTR **" <[email-masked]>
Date: Mon, 1 Nov 2004 19:58:22 -0600

Hi all,

Please accept my apologies for not responding to the list sooner...

This letter responds to the issues raised in Arnt's posting on 10/25 (attached to this letter):

1)  I have read all of the commentary on the 1*9DIGIT vs 1*DIGIT, and to be honest, I didn't put as much thought into it as everyone else has.  I picked 1*9DIGIT because that is how it is done in RFC 2852 (Deliver By SMTP extension), which Greg V. instructed me to use as a starting place for this draft.  Both the by-value (value of BY parm on the MAIL command) and min-by-time (value supplied with DELIVERBY keyword in EHLO response) are 1*9DIGIT.  Also, I note that RFC 3885 (MTRK SMTP extension) defines mtrk-timeout (an optional part of the MTRK parm of the MAIL command) as 1*9DIGIT.  

So, my thought was to keep similiar things consistent across all of the SMTP extensions.  What I got from the the discussion was that is was OK to leave the affected values in this draft as 1*9DIGIT;  is this still true?

2)  I agree;  however, my choice is "should not" (not CAPITIALIZED by design).  Note that there is no use of capitialized requirement terminology in Section 3.   My intent of this section is to describe, in a "prose-y" way, how an SMTP session using FUTUREDELIVERY would flow.  The behavior section uses the capitialized terminology.  I believe that paragraph 1) of section 3.2.1 makes the same statement as the first paragraph of section 3 (although 3.2.1.1 is written in terms of MUST instead of MUST NOT). 

How does this sound to everyone?

3)  You are correct;  the intention is that only authorized clients are allowed to use future delivery, and I see your point re. anonymous authorization.  This was added at Greg V.'s behest, and the related security concerns are the only reason I can think of, off the top of my head, to have the requirement.

I should defer to Greg V. on this issue....Greg, do we absolutely need the AUTH extension?

Greg White

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]]
Sent: Monday, October 25, 2004 9:16 AM
To: [email-masked]
Subject: Re: [lemonade] WG last call on future delivery

Glenn Parsons writes:
> 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.

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

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

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

---

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 2 Nov 2004 09:21:28 -0600

That's my point as well....  the must not should be tagged to submission, not future delivery. 

I don't want the plethora of states that say "can submit, can't future delivery, can DSN, Can BURL, can't delivery-by if authorized but not authenticated"

Greg V.

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]]
Sent: Tuesday, November 02, 2004 9:46 AM
To: [email-masked]
Subject: Re: [lemonade] WG last call on future delivery

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> 3) The AUTH requirement goes.
>
> That is fine, as long there is a security consideration in the 
> document stating that unauthenticated use of this feature must not be 
> allowed.

I disagree. If unauthenticated submission is permitted (heaven forbid!), 
then unauthenticated submission with future delivery should also be. If 
not, then not. No additional "must not" is necessary.

Arnt