Subject: [lemonade] comments on draft-ietf-lemonade-futuredelivery-01

From: Philip Guenther <[email-masked]>
Date: Mon, 21 Mar 2005 12:54:21 -0800

In section 3:
 - I suggest putting the numbers in parens to match the majority of
   already existing SMTP extension RFCs
 - ditto for putting the name of the extension (the second paragraph)
   as item (1) in the list and moving the others down one
 - in what's currently item (3), change "required parameter" to
   "optional parameter"

Section 4.1.1, item 1 seems redundant; if you want to use the
extension, you have to use the extension.  Or maybe this is a
statement that a client that uses some other mechanism to access
this capability in the MSA is not compliant with _this_ spec?  That
would make this statement a ban on other classes of extensions,
which seems out of scope or inappropriate for an RFC.  Would this
make a client that supports a prestandardization version of this
extension non-compliant?  Item 3 also seems unnecessary; if the
server isn't advertising this extension, than use of the 'AFTER'
parameter is not bound by this extension but rather the base doc,
RFC 2821.  Indeed, I can find no other SMTP extension that states
such a requirement on clients.

Section 4.1.2, item 2 seem redundant as well: isn't it implicit in
the fact that this extension is via the extension mechanism in 2821?
If an MSA doesn't support the 2821 extension mechs, then it isn't
non-compliant to support Future Delivery, it's *impossible*!

For section 4.1.2, item 3, what would it mean for an MSA to support
Future Delivery without advertising it?  I.e., what server behavior
is this 'MUST' banning and does such behavior really endanger
interoperability such that a 'MUST' is in order?  (I would just
drop this item)

Regarding section 4.2, should there be a note that a DSN from a
message submitted with the Future Delivery extension won't include
the Future-Delivery-Date: field and might not include the Arrival-Date:
field if the MDN wasn't generated by the MSA?  For example, clients
cannot depend on those fields being present as a replacement for
use of the envelope-ID via the DSN ENV parameter.

Regarding section 6 (IANA), isn't the registration process for SMTP
extensions exactly that a Standards Track RFC describing the extension
has been published?  At least that's how I read RFC 1869 and RFC 2821.

Philip Guenther
[email-masked]

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 30 Mar 2005 22:21:22 +0100

Philip Guenther wrote:

>[...]
I suggest something like the following text to address the issues raised 
by Philip:

      An SMTP client wishing to use Future Delivery MUST check that the
      MSA advertises the FUTUREDELIVERY keyword in a reply to the EHLO
      command. The client signals that it requires Future Delivery by 
including a
      future-delivery-interval-param with the MAIL command, the value of the
      future-delivery-interval-param MUST be less or equal to the value 
of the
      max-future-delivery-interval  advertised with the FUTUREDELIVERY
      keyword in the MSA's reply to the EHLO command.

>non-compliant to support Future Delivery, it's *impossible*!
I agree.
[...]

Additional comments:

 >4.3.2 MSA interaction with DELIVERBY
 >
 >   1) If an MSA supports Future Delivery and Deliver By, and receives
 >      a MAIL command containing a future-delivery-interval-param    
 >      whose value is greater than or equal to the value of the by-time
 >      parameter, the MSA MUST reject that MAIL command.

I suggest that an appropriate enhanced status code is mentioned here.

 >4.4.1 SMTP client interaction with MDN
 >
 >   1) An SMTP client MUST NOT request Future Delivery when sending an
 >      MDN to the MSA.

Is there any justification for this requirement?

Alexey