stef > The ESMTP extensions were designed to allow for the ACK information to
stef > be carried with each RCPT-TO.
tim > This is a good thing. By handling the ACK's in this way, it should be
tim > possible to obtain more meaningful NACKS's if they are detected by ESMTP.
stef > This strongly implies that it cannot be carried via non-ESMTP
stef > conformant SMTP MTA relays.
This is where I have a big problem. ... 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.
One possibility for accomplishing
end-to-end service an ESMTP relay would have to convert
the ACK request from the envelop to the message header. On going from
SMTP to ESMTP the inverse can be done. Otherwise, one will need a
complete ESMTP path from sender to each receipient.
But what if final delivery is to a SMTP agent. Or to a string of SMTP
relays. How would an ESMTP relay know to be responsible for issuing
an ACK-so-far?
Best.../Ed