[brk]

The problem is that working off of the current email protocols you have no way to guarantee that the message got any further than the MX for the end recipient. You can't even guarantee that MX didn't immediately route the message to /dev/null after accepting it from your server. So you could have a user that utilizes a spam filtering service like Postini, where an MX will accept the message, but then NOT deliver it to the end user. Your records would show that message as being verifiably delivered when it actually wasn't.

Sure, you can put tacking bugs in the email, but there is no way to guarantee the client will load/access those bugs as expected. I know of several organizations (banks, etc) that would likely immediately bla Khios your server IPs if they became aware of someone trying to utilize this to send emails into their organization.

So, this becomes a scenario where you can guarantee a message was delivered when everything cooperates, but can never conclusively prove a message was NOT delivered.

[cbpowell]

That's all true, and I concur. Delivery confirmation is certainly the weakest link in the whole equation and may never get solved with the current SMTP protocol.

The other pieces, however, retain their merit (I hope) -- a neutral and accessible 3rd-party that can prove you sent something, when you sent it, and to know that it at least got accepted by the recipient's MX.