HN Explorer

Show HN: Add FedEx-like tracking to email with CommAssure

2 points by cbpowell ↗ HN
This came about from the inevitable solve-the-world's-problems conversation(s) that happen over beers.

I'd heard time and again how email could "never cut it" for "real" business communications because it was so unreliable, especially in the face of increasingly fervent anti-spam measures. The whole "I never got that message" trick has happened to us all; we've all had emails disappear and require re-sending. (People also lie and abuse that excuse when it's convenient for them! :-)

I decided to see if I could code up a solution that would be everyman-accessible and seamless to use, and integrate into existing workflows.

Commassure is my new SMTP-based service that automatically adds tracking, delivery confirmation and integrity verification to all your outgoing email. After a brief configuration step you use your SMTP-compatible client just like you always did. iPhone, iPad, Thunderbird, Apple Mail, etc. are all compatible.

I'm interested to see if this gains any traction at all. If there's demand, I'll continue to expand the service with new features to address whatever good suggestions come my way. Any constructive criticism is welcome.

Technologies: Ruby on Rails 3; PostgreSQL; Linux.

http://www.commassure.com/

5 comments

[ 2.0 ms ] story [ 18.7 ms ] thread
veyron
"CommAssure keeps a complete record of the email." -- the problem is that the email may contain confidential information. Using FedEx, you are reasonably sure that FedEx envelopes and packages aren't opened by the courier service.

And the comment "We hold the same ethical standards as other email services such as Yahoo Mail, GMail, etc." doesn't really cut it for extremely confidential messages. You can tell, for example, if FedEx opened an envelope, read the contents, and put it back.

cbpowell
A good point, and I understand. I tried to anticipate this concern: there is a user preference that purges message body info after the message has been sent. The relevant confirmation data remains, but the body is wiped.
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.