

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

This came about from the inevitable solve-the-world's-problems conversation(s) that happen over beers.<p>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! :-)<p>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.<p>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.<p>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.<p>Technologies: Ruby on Rails 3; PostgreSQL; Linux.<p>http://www.commassure.com/
======
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.

------
ra
clickable: <http://www.commassure.com/>

I like the idea and you've found a great domain name for it.

