Stef,
The correct address for subscriptions is
ietf-ack(_at_)ics(_dot_)uci(_dot_)edu(_dot_)
Hmm... can I assume you mean ietf-ack-request(_at_)ics(_dot_)uci(_dot_)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