Re: ACKs/Return Receipts...

[kehres@xxxxxxx (Tim Kehres)]

Stef,

> The correct address for subscriptions is ietf-ack@ics.uci.edu.

Hmm... can I assume you mean ietf-ack-request@ics.uci.edu?    :-)

Thanks for confirming the ietf-ack list is still alive - I'll continue
this thread in just that forum.

> There has also was some private discussion of this issue in connection
> with the ESMTP development, to the effect that the ACK request
> information has to per carried in the ESMTP envelope on a per
> recipient basis, in the ESMTP envelope, and not in the RFC822
> envelope.
> 
> The ESMTP extensions were designed to allow for the ACK information to
> be carried with each RCPT-TO.

This is a good thing.  By handling the ACK's in this way, it should be
possible to obtain more meaningful NACKS's if they are detected by ESMTP.

> This strongly implies that it cannot be carried via non-ESMTP
> conformant SMTP MTA relays.

This is where I have a big problem.  If we are looking at the ESMTP work
as a mechanism that will help convey more meaningful reports in certain
situations, then great.  If on the other hand, we are mandating that a
message travel from originator to recipient *only* via ESMTP links, then
I think that this approach is badly broken.  Delivery ACK's and return
receipts are basically end to end services, and I don't believe that users
will find it acceptable that this functionality breaks every time a message
travels over a non-ESMTP link.

> So, to deal with all this, we are going to have to do some interesting
> thinking about how to enable ESMTP upgrading without forcing an flash
> cutover of all SMTP relay servers in the extended Internet EMail
> network.

I view the ESMTP upgrading as a totally separate issue.  A good place to
start is to define exactly what *user* requests are to be supported, and
them come up with a mechanism where this can be implimented so that two
end points that are compatible with the new mechanism can sucessfully
interoperate.  In the process, we should make sure that what we come up
with will map well to the new ESMTP facilities.  To do things the other
way around will, IMHO, result in a solution that very few people will want
to use.

Best Regards,

Tim Kehres