HN Explorer

Ask HN: accepting submissions via email - usability/security concerns?

4 points by cullenking ↗ HN
I just put in place the ability for users of http://ridewithgps.com to email a GPX file to our site as a method of posting their file. I implemented it in the easiest way possible - a single email address for all uploads, and I determine the account based on the From field. In a service like posterous, this is an obvious security issue, since the From can be spoofed. I am not so worried in our service, since it's mostly a private record keeping system. However, I would like to add some security as long as it's not greatly inconveniencing.

I'd prefer to keep it a single upload email address rather than let the user set their own custom address, for simplicity/rememberability. Additionally, I am wary of a passphrase, though this isn't too bad.

What do you guys think of sending a confirmation email for the submission, and then processing/posting the submission when a reply to the confirmation email is made? Seems like the easiest for users, even though it's a two step process. Thoughts? Ideas? Suggestions?

8 comments

[ 5.1 ms ] story [ 38.4 ms ] thread
tarunkotia
You should create email template for users which should have a unique passphrase. Since most of the emails are sent over https, you should not have to worry about plain text passphrase. If there is no passphrase then you should send a conformation email or request user to verify his submission. I am implementing a similar process for the application I am working on. Would love to hear how you are managing this.
Travis
How are most emails sent over https? Emails are generally send SMTP (if you're lucky, your provider uses TLS, but there's no guarantees).
cullenking
The problem with the template is the use case - people will be using this primarily when they log a track using My Tracks on Android. The app has an option to email the resulting log file instead of saving to SD card. This way, the user can send the file directly to their RWGPS account instead of to their email address, then upload it from their home computer.

Keeps me from having to write an app for android, since My Tracks is a great logging utility! That, and other developers can easily integrate with our site using this option.

notmyname
The confirmation email isn't a bad idea. I wouldn't mind it too much.

Perhaps a simpler idea though is to make sure the users can easily delete data or routes that are sent in via email. It doesn't really solve the "spam" routes that could be added to an account, but it does make it easy for a customer to clean it up.

Perhaps require confirmation if many routes are uploaded in a short amount of time.

Perhaps require a secret key hash to be included in the subject of the message.

cullenking
I may do the secret key, but I'll probably only resort to it if there is indications of abuse.
Travis
Seems to me there's two questions here: 1) do I need to secure this / does it matter if people get spammed? 2) how do I secure this

I'd proceed until apprehended with #1. As long as it's simple to delete.

I like the confirmation idea, but which is more pleasing to the user (when a spam message is spoofed/sent in): to see dozens of emails coming in, or to see dozens of places suddenly added?

If it were me, I'd just implement a secret address code. If you're using gmail or something to host the email (and connecting via your web app), just use the '+' notation to extend a single email account. So submissions@app.com could be travis+submissions@app.com and go to the same mailbox (I'd change "travis" to a secret code... but the idea is the same)

cullenking
I am not worried about spam since there isn't really any avenue for it. If there isn't a GPX/TCX/KML geo file attached to the email, the upload isn't processed. As a result, I don't expect this to be abused.

I think I may just proceed and handle it if it becomes an issue, probably with a simple passphrase in the subject field.

I am not using gmail, I actually setup a postfix transport layer, which runs a simple ruby script that just pipes the email through a unix socket to a r receiving server - the server has Resque loaded up and queues up jobs to be handled by my resque workers.

_b8r0
A two step process seems like more effort than different email addresses per user. Thankfully you can use the from header as long as addresses are suitably unique (hey, it works for flickr, wordpress and countless other sites that host much more sensitive data, why not yours?)

Assign each user an email address that's based on (and I'm sure the likes of cperciva or tptacek can improve on this) an email friendly encoding of an scrypt or bcrypt derived function to generate a unique email address.

This can then be added to the user's address book under an alias for your service. You then store this value and the username in your app. When the email is received, you look up the unique source address and translate it to the user. Problem solved.