Nits from Gen-ART review by Francis Dupont:

- the "MSA" abbrev is never introduced (I suggest to both explain what
   it stands for and to put a reference to n3)
 - (in 6) standards-track -> Standards Track
 - I can't parse the first statement of 7 (where is the verb "who"
   is the subject?)
 - (in 9) Jauuary -> January)

I'm uncomfortable with the claim that this extension can only be
offered over the submission port.  I can see the reason you don't want
it offered over the smtp port.  However I'm going to be really annoyed
if I try to set up a test server on some random port and it ends up
offering a different feature set because of the port I used.

  Two comments from the SecDir review Radia Perlman:

  Under security considerations, it says "an MSA that supports future
  message release MUST also support at least one of the authorization
  mechanisms."  That is, the MSA may not require the client use it.
  If this is true, then there needs to be an error that indicates
  that the MSA could not accept your future-release message because
  authentication will be required.

  There is an error for a user exceeding his own quota.  Assuming that
  the MSA is willing to overbook and there are a lot of users using
  this feature, the total shared storage might be exceeded.  Should
  there be a separate error for "you didn't exceed your own quota,
  but I still don't have any room left for your future-release
  message".

Section 6:
   According to the IANA website, this extension will be added to the
   list of SMTP extensions on the Mail Parameters webpage once this
   draft becomes a Standards Track RFC.

Although I don't think this will be missunderstood by IANA, I think it is a bit incorrect to say that the registration will not happen until it becomes a Standards track RFC. Normally IANA do the registration upon the approval of the document by the IESG and before the publication as an RFC. I think one normally simple request that IANA performs the registration without being explicit about which phase.