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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 2 Nov 2004 07:34:05 -0600

On point 3, Future delivery is used only with the SMTP-Submit profile, not general SMTP. The Submit profile is the place to address whether authorization without authentication is sufficient for submission services.  I think it would be a diservice to have future delivery as a extension available only in a sub-set of valid submission cases.  My take is that if submission is permitted, and future delivery is advertized as supported, then future delivery should be permitted.

Greg V.

-----Original Message-----
From: White, Gregory (Gregory)** CTR ** [mailto:[email-masked]]
Sent: Monday, November 01, 2004 8:58 PM
To: [email-masked]'
Subject: FW: [lemonade] WG last call on future delivery

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

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 2 Nov 2004 15:15:12 +0100

so, if I understand it correctly,

1) 1*9DIGIT stays. (Fine with me - I like consistency.) The special case 
0 is then superfluous. It's the same as 999999999.

2) Is also OK.

3) The AUTH requirement goes.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Nov 2004 14:31:30 +0000

Arnt Gulbrandsen wrote:

> 1) 1*9DIGIT stays. (Fine with me - I like consistency.) The special 
> case 0 is then superfluous. It's the same as 999999999.
>
> 2) Is also OK.

The document must state that it is using RFC 2119. Just having it in the 
References section is not sufficient.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 2 Nov 2004 15:46:13 +0100

Alexey Melnikov writes:
> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Nov 2004 15:24:57 +0000

> then unauthenticated submission with future delivery should also be.

If a feature is liable to abuse because of the lack of authentication, 
than the document must say so.
When I say "authentication", I don't necessarily mean SMTP AUTH. IP 
verification is authentication as well.

RFCs can't force implementations to comply, but it is important that 
they emphasize important issues.

> If not, then not. No additional "must not" is necessary.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 2 Nov 2004 16:47:26 +0100

> than the document must say so.

Well, I don't see that it is open. I see that unauthenticated message 
submission is, of course.

(I don't think every extension should repeat the base security 
considerations merely because the basic problems are still there when 
the extension is used.)

Arnt

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 02 Nov 2004 15:51:42 -0800

--On 2004-11-2 3:46 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

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

I can authorize without using AUTH. On my MSAs, any messages
received via the loopback interface (127.0.0.1 and ::1) or through
named sockets (/var/run/submission) are implicitly authorized
by the nature of the injection mechanism. You cannot mandate
AUTH as a pre-requisite to using AFTER. Instead we need to describe that
MSA policy might require AUTH before allowing use of AFTER (e.g. to 
enforce
a policy restricting AFTER to specific users), and describe how the 
client
should deal with this scenario.

We should be enumerating specific error status codes for the failure
modes. I suggest the following:

530 5.7.8 Requested facility requires authentication

  Issued when the MSA requires explicit client authentication before
  permitting use of AFTER.

  The 530 reply is defined by RFC 2554.

  NOTE:
  5.7.8 is a proposed new enhanced status code. It is issued when an 
SMTP
  command requests the use of an optional facility for which the server
  requires the session be authenticated. Specifically, it indicates the
  command should succeed (barring policy restrictions) if the client
  re-issues the command after a successful authentication.
  Alternatively, the client could re-issue the command
  without requesting the optional facility. (Of course its chances of
  knowing which facility to drop are marginal, unless only one facility
  was requested.) I believe this code is generally useful, therefore it
  should be defined in a way that makes it easy for other specifications
  to use normatively. I think this means updating RFC3463, or maybe
  just writing a one-page RFC to define the new code?

501 5.5.4

  AFTER requested an interval greater than what the server advertised.

501 5.5.4

  AFTER requested an interval greater than the associated DELIVERYBY 
time.

452 4.3.1

  The number or size  of messages queued on the server for future 
delivery has
  exceeded quota.

Of these responses I believe the '530 5.7.8' is a MUST, and the
rest are SHOULDs.

Next, some silly-state issues.

If <max-future-delivery-interval> is zero the server enforces no upper
bound. But the protocol only allows the client to specify up to 
999999999
seconds. The special semantics attached to zero should be removed. In
this scenario the server should just advertise the maximum permitted by
the protocol. Since a delivery interval of zero now makes no sense we
should specify a minimum interval of one second.

Advertising FUTUREDELIVERY without a <max-future-delivery-interval> 
doesn't
make any sense to me. Surely the server knows this value. What purpose 
is
served by not advertising it? What is a client supposed to do if the 
server
reject the message due to the interval being too great? Guess? 
Advertising
the maximum interval must be mandatory.

Here's an updated grammar:

after-parameter          = "AFTER=" after-time
after-time               = %x31-39 *8DIGIT
                           ; Integer in the range 1-999999999
futuredelivery-parameter = after-time

In security considerations we need to mention another DOS scenario. A 
client
might inject a large number of messages with a very low <after-time>
(say, one second), with the intent of causing the MSA to perform extra 
work
by placing the message into a deferred queue, only to have to 
immediately
move it to an active queue. For this reason the server might want to
enforce an explicit minimum bound on the deferral time, or defer any
further processing of a FUTUREDELIVERY message until the next regularly
schedule queue run.

The references need to be split into normative and informational 
sections.

The reference to RFC2822 should be removed.

The remaining references are -- I believe -- all normative.

Some wordsmithing issues.

Section 1, the second paragraph should read:

  This extension uses the SMTP submission protocol [3] to allow
  a client to submit a message for delivery at a future time.

Section 3 discusses what I consider to be implementation-specific
details:

   MSAs in receipt of a valid future-
   delivery-interval parameter are expected to convert the parameter
   into a locale-specific absolute time called the future-delivery-time.
   This is done by adding the future-delivery-interval to the locale-
   specific message receipt time.   The MSA is expected to assume that
   the transmission time of the MAIL command is instantaneous.

All we need to say is that the <after-time> specifies a delay relative
to the time the MSA received the message. Technically, this would be
time the MSA issued the 2XX reply after completion of the DATA command,
but I don't think we should call it out in this level of detail.

   If the MSA accepts a message with a future-delivery request, then the
   MSA delivers/relays the message after the MSA's system clock passes
   the future-delivery time.

should be changed to:

   Upon receipt of a message with a future delivery request, the MSA 
MUST
   NOT forward or deliver the message until after the requested delay
   period has passed.

--lyndon

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 02 Nov 2004 16:42:17 -0800

--On 2004-11-2 3:51 PM -0800 Lyndon Nerenberg <[email-masked]> wrote:

> For this reason the server might want to

Let me clarify this. First, change 'explicit' to 'implicit'. And what I
mean by enforcing a minimum bound is that the server might choose to
silently enforce a minimum <after-time>. I.e., if the client says
AFTER=5 and the server has an implicit lower bound of 60 seconds, it
would still accept the message, but defer forwarding for a minute.

I think a more realistic scenario would have the minimum deferral time
be bounded by the queue run interval. I.e. if the MSA processes the 
future
delivery queue every five minutes, the implicit minimum bound will be
a value between 0 and 300.

--lyndon

---

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 3 Nov 2004 14:31:52 -0500

Another technique that might in the future be acceptable as 
"authentication" in this context is payment, either by actual money or 
by computational challenges.  That is, it might be acceptable/desirable 
for a future entrepreneur to offer anonymous email submission for cash, 
so long as the cash barrier is set high enough to deter true spammers.  
Similarly, it might be acceptable/desirable for a human rights 
organization to operate an anonymous submission service in which the 
client has to pay with computational cycles (enough to make it 
uneconomic for spammers) in order to obtain untraceable delivery of 
sensitive messages.

Actually, I think the use of the term "authentication" should really be 
discouraged in this context (and at the upcoming FTC summit) in favor 
of something that doesn't preclude such alternatives -- perhaps 
"authorization" or "credentialing."  -- Nathaniel

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 03 Nov 2004 11:51:30 -0800

--On 2004-11-3 2:31 PM -0500 Nathaniel Borenstein <[email-masked]> 
wrote:

> Actually, I think the use of the term "authentication" should really
> be discouraged in this context (and at the upcoming FTC summit) in
> favor of something that doesn't preclude such alternatives -- perhaps
> "authorization" or "credentialing."

I'm glad you made this point. I wasn't very comfortable with using the
term "authentication." I realized last night that what I really meant
here was "authorization" and was planning to send out another 
clarification
today, but you beat me to it.

I do think the draft should be re-worded to use the term 
"authorization."
AUTH would still be used as the example of the most common form of
authorization.

--lyndon

---

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 3 Nov 2004 15:58:57 -0500

> AUTH would still be used as the example of the most common form of

Yes, it would be even better, IMHO, if it explicitly called out a few 
alternate possibilities for authorization. I think it important that we 
do what we can to make it clear that anonymity need not be sacrificed 
for spam control.  -- Nathaniel

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 06 Nov 2004 16:19:39 +0000

Lyndon Nerenberg wrote:

>  5.7.8 is a proposed new enhanced status code. It is issued when an SMTP

Actually, section 5 of draft-siemborski-rfc2554bis-03.txt (SMTP AUTH
revision) already has:

    530 5.7.0 Authentication required

    This response SHOULD be returned by any command other than AUTH,
    EHLO, HELO, NOOP, RSET, or QUIT when server policy requires
    authentication in order to perform the requested action and
    authentication is not currently in force.

If you think a more specific enhanced status code is needed, than I
think it still belongs to
draft-siemborski-rfc2554bis.

Alexey