Right? This is the one I switched to after getting fed up with FormMail. It was self-hosted and runs on PHP instead of CGI, whohoo! Pratically magic for 2001. http://regretless.com/scripts/scripts.php#dodosmail
You either download the CGI script and host it yourself or you pay the formmail.com people to host it. In the olde days there were free ones where you specified the destination in the form, but spam put paid to that.
That's how my very first website worked, which let users vote for Coke or Pepsi. I would get emails during the week and then update the count on the site manually. Horribly inefficient, but as a kid I thought it was pretty great.
When you submit a form with a "mailto:" action, the browser opens the mailto protocol handler, which is the user's email client. So you hit submit on the form and then see a draft email filled out with your form responses.
If the user doesn't have an client-side email client setup (eg, they use Gmail/Hotmail via the browser) a box will pop up prompting them to setup an email account.
Even if they do have one setup up, most users will immediately dismiss the email, so you'll never get it.
This is different to serverside email, where the client submits a form to the server, and the server sends you an email.
Unlike the "mailto:" method, the second method will actually get you some responses.
Another option is to host your static site on BitBalloon (https://www.bitballoon.com) - we make the forms on the site work without any backend programming.
This doesn't leave your email in the HTML and we also do spam filtering on the form submissions (get a bit of traffic and your contact form will get lot of spam).
People are looking to static sites more and more for a couple of reasons:
1. speed - you can't beat an optimized static sites hosted on a CDN. In part I suppose the increased focus on speed i driven by mobile traffic.
2. Github - front-end developers have now gotten really used to having everything under version control. Dumping the most important content into an unversioned database just doesn't feel as good as having everything as Markdown in Github
3. Jekyll - or rather build tools and static site generators in general. The combination of GitHub and Jekyll and flag ship projects such as the Obama Campaign platform [1] definitively played an essential role in the growth of static site generators we're seeing now.
Our clients range from beginners launching their very first HTML site, over agencies with really cool flows built around Middlemand/GitHub/Draft/Similar services, to companies that are integrating site publishing into their products in various forms.
One of the cool examples is a startup doing a site builder for progressive candidates running for national campaigns. They use our API to handle the publishing, and use our form feature for gathering volunteer submissions and contact mails.
In general I think publishing a website with a form on it, is one of the most basic features of the web. Making it faster, easier and better is a pretty obvious plus for a lot of people.
Basically, I build static sites for some small businesses in the area. They want to be able to choose where everything goes, to the pixel, so it's easiest to work with just html and css. Then I can upload to BitBalloon and everything works exactly as it did on my laptop. Forms work, everything gets optimized, and setting up my own domains is super simple. And it's cheap.
I could use S3 or something else, and it would be cheaper, but deploying in a half second really is useful. Everything is done right with no effort on my part other than building the site itself.
I also built a site just for fun and host it there. 750,000 page views in the last couple weeks, didn't worry for a second. http://gallerrit.com/ It has also been very easy to push updated versions with no down time.
Great idea. I'm not sure about the pricing though. I'd expect anyone who reaches 1000 submissions per month to probably make the effort to get their own form handler. I'd make it 100/month or maybe 1000 submissions total until you have to pay. Then make it an annual fee so that customers think "OK, I'll pay $X not to have to deal with this for another year."
I'd advise against making it a total submissions limit. I would not bother attempting to use a service that is guaranteed to blow up on me one day even if the site remains low traffic.
I've been using SimpleForm(http://getsimpleform.com/) for my static site forms, It's quite easy to set up and you can add some spam prevention with Akismet.
This project looks interesting because there no need to register unlike SimpleForm.
Or more importantly, to stop someone sending an email to N different emails just 1 time?
EDIT: Okay, I missed the part where the email must be registered with them. Assuming no one is interested in spamming with the confirmation email, which seems fair.
Cool idea -- what kind of spam protection can it offer though?
I'm not worried about the email address being in the open, but my original contact page form was getting hundreds (thousands?) of spam submissions a day until I implemented some simple javascript 'traps' to filter out the bots.
I've still not worked out why a bot wants to fill in a contact form with spam anyway, seems like a real waste of time.
Best and simplest trick I've found for this is having a CSS hidden honeytrap field, something like <input name="message_body" type="text" class="hideme" />
Bots will put something in the field but humans should never see it, so if the server sees anything in there it can safely toss the whole thing.
Two pitfalls: 1) You should add some text to indicate to people using screen readers that this field should remain blank. 2) You should make sure to name the field something unlikely to be autofilled. There are browser toolbars out there that will happily autofill even hidden fields and trigger your spam filter.
But other than that, I agree that this is extremely effective against the common sort of drive-by spam bot. (And, obviously, completely useless against any sort of advanced or targeted attack.)
Good point. My javascript solution uses two hidden fields with very similar names. One that the script fills in and one that it doesn't.
Bots will either hit both or neither and get rejected. Screen readers/toolbars may be an issue, though the names would be hard to think what to autofill with. It has never come up in practice -- the reject message tells people to email us directly
If you have javascript turned off, you'll need to email directly too -- and the site won't work so there probably isn't much lost!
As many have asked, at least for now there's no real spam protection. Asking you to confirm email for every email/referer pair prevents me from adding your email to zillion sites (although confirmations could also get annoying at that point :) and spamming, but of course that doesn't still prevent bots from filling out your form.
I think in a way it's a tradeoff between ease of use, both for you and the visitor. Alternatively we could do heavier registration process and/or let you configure some running on our server, but then setting things up wouldn't be as easy and you might as well just run your own backend. For the visitors forms provide an easy (than, say just email) way to reach out. I guess the question is, do you prefer false positives (spam) or false negatives (folks not reaching out) :)
Regarding having clear text emails in the source, I'd argue (based on nothing but anecdotes) it doesn't matter, much. As throwawaymsft said elsewhere, bots are pretty good at figuring out what "you (at) email (dot) com" means, so in most cases you'd anyway be getting much spam. We considered a token-based approach instead, but decided to go all-in for simplicity. Also, since we're using forms anyway, they're more likely source of spam than some bot crawling just for addresses.
Regarding the issue of having your email address in the open. This could easily be solved by requiring registration and generating an encrypted URL for each email address that a user associated with their account. I know this highers the barrier for entry, but putting an email address in the open is foolish and making it too easy for the dumbest of email harvesters.
This is what I was thinking as well. An account isn't even necessary, just have a two step process on Formspree.
1. Enter your e-mail address. Click next.
2. Copy the generated code, //api.formspree.com/Kn2JanlPkZ into your form as the action. Obviously this code and e-mail combination is then stored in the Formspree database.
I'm thinking he means registering an account on the formspree site. So your form's `action` attribute doesn't require the inclusion of a plain e-mail address. Instead it gets some encrypted string, which is uniquely tied to your formspree account.
Alternatively, formspree could publish a public key which you could use to encrypt your email address. To make it easy, they would just have a form on their website which does the encryption for you, giving you the opaque string to use in your form.
The UX for the user is the same if Formspree were to just generate a random token and store in their DB mapping it to an email, but this way Formspree doesn't need to store anything in their DB.
Originally, I did just that with my service. The problem is when you need simple information like "What browser and version are you using" when someone says something "isn't working". Capturing User Agent during form submission takes an otherwise painful step out: asking a non-technical person to find out what version of Internet Explorer they are running. There are still people who think "The Internet" is "the Blue E on my computer". Similarly adding required fields like "What's your site's address" when you run a multi-site service. All valuable things to have specified so that you can answer any questions with the first response rather than having to ask a pile of followup questions when customers don't provide enough info.
I was recently looking for a nice simple implementation of this for a client. Didn't really find any that I liked so we decided to build this ourselves. Now we have the flexibility of either emailing them the results or storing in our local database for later processing. This looks really nice though.
This kind of service will stay low on the radar compared to how many people write their email in plain text on web pages. It's quite unlikely that someone is going to crawl the web and harvest formspree "ACTION" fields when they can simply harvest regular email and get a million more.
I don't know who would want this. Is it really a demand from people? It is programmers who love static sites who use this? Or the non-coders everywhere?
Edit: http://www.formmail.com/ still seems to be going, in fact.