Subject: [lemonade] Future Release Discussion

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 3 Jul 2006 07:46:14 -0500

I have collected the following discussion comments (praphrased) and proposed resolutions.  I plan to submit a revised ID with these changes after the current posting embargo lifts.

Greg V.

Francis Dupont via Brian Carpenter: .
----------------------------------------------------

Various editorial nits, all accepted

Radia Perlman via Russ Housley
-----------------------------------------------

  1) Need error code indicating that required authorization has not been performed prior to use of this extension.

	- SMTP-Submit itself requires authorization.  This authorization be be performed by a number of in-band or out-of-band protocol mechanisms including address filtering, or pop before submission.  It is not the intention of this draft to raise the authentication requirements for submission. 

	Suggested change:  Clarify that the MUST requirement level is re-itterating the requirement for submission in general.  If the client cannot authorize, the full submission service is unavailable.

   2) Need an error code indicating system quota exceded but user quota is still available.  

	Suggested change:  Add the suggested error code.

Yoshiko Chong
-----------------------

IANA registration questions

    1) Registration of HOLDFOR and HOLDUNTIL mail from parameters.

Suggested change:  Modify the IANA request to exclude registration of these parameters. It has not been common practice to register specific parameters separately from the service extensions themselves.  While it is increasingly valueable to collect in a single registary the various RCPT TO and MAIL FROM parameters, I suggest this is an independent action from the approval of this specific extension. 

    2) Registration for new status codes.  Status codes are extended only by standards track document.  As with the handful of previous status-code extension documents, this document is the sole registration for these new codes. 

Suggested change:  None.  It is reasonable for IANA to add a registry for status codes for ease of reference, but I suggest that this document not be held up for such.  

Lars Eggert (two messages)
-----------------

Need to ensure accurate time for HOLDUNTIL to avoid unanticipated premature or late release, a security-related side-effect.  Why not just use HOLDFOR?

The inclusion of both HOLDUNTIL and HOLDFOR in this extension was made after very extensive discussion on the LEMONADE mailing list.  There are good arguments for the HOLDUNTIL variant, and while security risk associated with an inaccurate server clock was not raised, I don't believe we can easily reach agreement to drop this option.

   Suggested Change:  Author will augment security considerations section to describe the additional risks of the HOLDUNTIL option as well as include pointer text in the description of the HOLDUNTIL option.

   2nd Suggested Change:  Add text that a submission server SHOULD only offer futurerelease if it has accurate time.  There is no mechanism for indicating support of HOLDFOR only in the current proposal.

   Editorial change s/trivally/triviallly/ accepted.

Magnus Westerland:  
------------------------------

  1) ABNF for max-future-release-date is incompletely or incorrectly specified.  2) Missing definition for internet-style-date-time-utc.  Request for a collected grammer.

Suggested change:  Delete the -utc from the attribute name yielding the following text.

     The max-future-release-date-time is a timestamp, normalized to
      Universal Coordinated Time (UTC), indicating the most remote date
      and time in the future until which the MSA will hold messages for
      future release.
      
      Using ABNF [n2], the syntax of this parameter is as follows:

         max-future-release-date-time = Internet-style-date-time

      where the format of Internet-style-date-time is defined in [n10].

Suggested change:  Collect the grammer in a new section.
 
  3) Section 6 comment.

Suggested change:  Modify the text to indicate that IANA will add this extension as part of the document approval and publishing process and leave out the incorrect detail.

Sam Hartman, reply comment by Bell Fenner
---------------------

Uncomfortable with binding of this extension to submission port.  

No change.  This is not an SMTP extension, but an extension to SMTP-Submit which is defined to execute on a particular port. There are greater distinctions between submission and relay than simply the alternate port number. This is one of several such submit-only extensions including recently approved and published BURL (RFC 4468)

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 3 Jul 2006 15:55:08 +0200

Vaudreuil, Greg M (Greg) writes:
>    2nd Suggested Change: Add text that a submission server SHOULD only 
>    offer futurerelease if it has accurate time. There is no mechanism 
>    for indicating support of HOLDFOR only in the current proposal.

I've a bad feeling about this; it confuses the implementer, software and 
sysadmin.

The implementer of an SMTP SUBMIT server does not know whether the 
software will run on hosts with reliable time (except in rather special 
circumstances), so it's unreasonable to make this demand of the 
implementer.

The software can't easily tell whether it's running on a host with 
reliable time. If it tries hard enough, it can, but I think it's 
unreasonable to ask SMTP server software to try that hard.

The sysadmin is IMO all too likely to act overconfidently, and assume 
that the server will have reliable time. (Example: Buy a typical PC 
motherboard in a 19" case, install linux, set up ntpd, never check that 
the motherboard clock is within ntpd's sanity limits.)

I'd just as soon drop this SHOULD, it's not going to do anything, and 
just have some general prose on the importance of accurate time.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Mon, 3 Jul 2006 08:06:13 -0700

With regard to this part of the issue:

Your suggestion implies that future release is prohibited in SMTP and only 
permitted in SUBMISSION.

I have no objection to this prohibition; but I can come up with no 
particularly compelling reason for it.  If we wish to go this route, we 
need to provide this reasoning.

Also, what if the SUBMISSION client authenticated with ANONYMOUS?

Just flesh out these details, and I think that we're good to go.  Once 
again, I don't see a compelling need for future deliver with SMTP or with 
ANONYMOUS authentication, but Radia is correct in observing that we need 
an error code saying that this transaction is not authorized (which can be 
a reference back to the submission document).

On Mon, 3 Jul 2006, Vaudreuil, Greg M (Greg) wrote:
>  1) Need error code indicating that required authorization has not been 
> performed prior to use of this extension.
> 	- SMTP-Submit itself requires authorization.  This authorization 
> be be performed by a number of in-band or out-of-band protocol 
> mechanisms including address filtering, or pop before submission.  It is 
> not the intention of this draft to raise the authentication requirements 
> for submission.
> 	Suggested change:  Clarify that the MUST requirement level is 
> re-itterating the requirement for submission in general.  If the client 
> cannot authorize, the full submission service is unavailable.

-- Mark --

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

---

From: Tony Finch <[email-masked]>
Date: Mon, 3 Jul 2006 16:11:14 +0100

On Mon, 3 Jul 2006, Mark Crispin wrote:
>
> Your suggestion implies that future release is prohibited in SMTP and
> only permitted in SUBMISSION. I have no objection to this prohibition;
> but I can come up with no particularly compelling reason for it.  If we
> wish to go this route, we need to provide this reasoning.

I would have thought that this kind of restriction would be an operational
matter rather than something required for standards-conformance.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SHANNON: SOUTHEAST ROCKALL NORTHERLY 4 OR 5, OCCASIONALLY 6 IN SHANNON.
FAIR. GOOD.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 3 Jul 2006 08:25:12 -0700

> matter rather than something required for standards-conformance.

If it is an operational matter, then the error code is definitely needed. 
The only way that we can avoid it (as Greg advocates) is to have a 
standards level restriction.

I don't particularly care either way.

-- Mark --

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Jul 2006 10:24:27 -0400

>>>>> "Arnt" == Arnt Gulbrandsen <[email-masked]> writes:

    Arnt> Vaudreuil, Greg M (Greg) writes:
    >> 2nd Suggested Change: Add text that a submission server SHOULD
    >> only offer futurerelease if it has accurate time. There is no
    >> mechanism for indicating support of HOLDFOR only in the current
    >> proposal.

    Arnt> I've a bad feeling about this; it confuses the implementer,
    Arnt> software and sysadmin.

During IESG discussion on the telechat, it seemed fairly clear that we
wanted such a restriction as operational advice, not as a standards
level restriction.  "Don't enable future release unless your server
has accurate time," provided as operational advice.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Jul 2006 10:25:28 -0400

>>>>> "Mark" == Mark Crispin <[email-masked]> writes:

    Mark> With regard to this part of the issue: Your suggestion
    Mark> implies that future release is prohibited in SMTP and only
    Mark> permitted in SUBMISSION.

    Mark> I have no objection to this prohibition; but I can come up
    Mark> with no particularly compelling reason for it.  If we wish
    Mark> to go this route, we need to provide this reasoning.

The draft makes it clear the future release is prohibited for SMTP
already.  I found that odd, but it's already in the text.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 08 Jul 2006 14:59:39 +0100

>   2) Need an error code indicating system quota exceded but user quota is still available.
Hi Greg,
I have a clarifying question: How is this new error code to be used? Is 
its purpose to signal to the client that even though the future release 
request failed this time, it may succeed in the future?

---

From: Ned Freed <[email-masked]>
Date: Sat, 08 Jul 2006 20:28:49 -0700 (PDT)

> request failed this time, it may succeed in the future?

That's my understanding of its purpose at least.

> >	Suggested change:  Add the suggested error code.

I have no objection to adding the error code, but I have to say that if past
experience with similar error codes in email protocols that suggest a further
action to take is any indication the chances of clients actually taking
advantage of this information is remote in the extreme.

				Ned

---

From: Lars Eggert <[email-masked]>
Date: Sat, 8 Jul 2006 15:09:05 +0200

> has accurate time," provided as operational advice.

Right, my DISCUSS on this was sloppily phrased. The intent was  
exactly what Sam has expressed above. (Sorry for jumping in late,  
working through my email backlog after a vacation.)

Lars
-- 
Lars Eggert                                     NEC Network Laboratories