Keeping Email Addresses From The Spambots

Here’s an interesting approach to the problem of making your email address easily available to people but not spambots – hide the page with the mailto: link behind a form POST. See comment #2 in that discussion for the most slick method – return the mailto: link as the location in the response headers. For extra points, you could disguise the submit button to look like a URL…

My personal attitude is that spam is a price you have to pay for being contactable. You’ll find my email addresses, unobfuscated, all over the web.

Oh, and I’ve updated the newsgroups list. Please have another look and see if the changes are to your liking.

21 thoughts on “Keeping Email Addresses From The Spambots

  1. Spam is *not* a price one has to pay for being contactable. I don’t get any spam. Here’s how I do it:

    1. I don’t put any of my private email addresses on the web. Ever.
    2. If I have to register to a site or a service, I use spamgourmet.com disposable addresses.
    3. If the service or site requires that my address will be displayed out in the open (e.g. bugzilla.mozilla.org), I use a free challenge/response service called bluebottle.com. Unlike disposable addresses, a CR address is still valid for non-spammers, as long as they respond to a one-time challenge. IF they are against the concept of CR, then tough. I’m not going to put my private addresses on the web to please them.
    4. If an address does get “burned” (known to spammers), I configure it so that it only receives mail from unknown senders. Last time I did this was three years ago, for my hotmail.com account.
    5. Even for private correspondences, I sometimes use addresses that are configured in the format of sub-domain@alias (e.g. gerv_blog@prognathous.an_alias_of_my_email_service.tld)
    6. To filter out spam spoofed as mailing lists I subscribe to, I use a Sieve script that checks the headers, detects the spoofing and throws the spam in the trash.

    Bottom line: I’m fully contactable, yet I get zero spam :-)

    Prog.

  2. mozilla.dev.tech.mathml n.p.m.mathml
    mozilla.dev.tech.svg n.p.m.svg
    mozilla.dev.tech.xforms –
    mozilla.dev.tech.xml n.p.m.xml
    mozilla.dev.tech.xslt n.p.m.layout.xslt

    would it not make sence to have mdt.xml.{mathml,svg,xslt,general,xforms} or such?

  3. As Doron hinted… I think there are a few too many. IMHO considering how little traffic quite a few will get… it’s rather cumbersome going through them all.

    I’d look at consolidating a bit. That way people actually see everything without a trillion+2 clicks.

  4. I just thought of something too.

    Why not create a little PHP script like this:

    And link to that script with some HTML:
    Email Me

    And clicking on that link would launch your email client.
    This wouldn’t work though if the spambots checked the HTTP headers.

  5. I guess this blog allows HTML :)

    PHP script is
    <?php
    header(‘Location: mailto:artooro@gmail.com’);
    ?>

    HTML is
    <a href=”emailme.php”&gtlEmail Me</a>

  6. mozilla.dev.proj.mozilla-suite –
    mozilla.dev.proj.seamonkey –

    how do these differ?

  7. The trouble with redirecing to mailto: URLs is that they only work for people who have their browsers configured to do this.

    Some of the places where I regularly use ‘Firefox’ I haven’t set this up set. To do this on one of my computers I’d need to do something like: install the MozEx extension; Google for the magic about:config settings cos MozEx is pre-extension-manager and it’s gui config got lost somewhere; work out how to provoke MozEx into SSHing to the computer with my mail on and invoking ‘Mutt’ with the appropriate arguments, which would possibly involve writing a script that takes a simple argument from MozEx, cos otherwise the shell quoting gets too hard.

    Admittedly my life would be slightly more convenient if I did the above, but I don’t mail people I don’t know that often, and at the moment the process only involves right-dragging upwards on the mailto: link to activate the RadialContext gesture for ‘copy e-mail address to clipboard’, then switching to my ‘Mutt’ window, pressing m to start a new mail then pressing Shift+Ins to insert the address copied from ‘Firefox’ — so putting effort into automating the whole thing hasn’t yet seemed worth it.

    But if the mailto: link isn’t on the page then I can’t do that. I’d have to actually follow the script link to get the e-mail address, and if that comes back as a header, is it easily available to me? Getting a pop-up window saying “mailto is not a recognized protocol” isn’t usefull; even if the pop-up box included the address, I’d still have to carefully read it and type it, because text isn’t selectable and copyable from alert boxes.

  8. Prog, it depends on what you mean by “fully contactable”. You’ve merely made a trade-off between your own inconvenience of having to filter for spam and the inconvenience of other people having to jump through hoops to contact you.

    Sometimes if I’m mailing somebody in an attempt to help them with something, I can’t be bothered with challenge-response: I don’t see why I should have to do the hoop-jumping for something that benefits them. This particularly annoys me when my mail that got blocked was in reply to a mail that they sent me! They know who I am, and my mail contains an In-Reply-To: header that contains a valid message ID of a mail they sent me: there is absolutely no grounds at all for thinking that mail might be fake.

    Also, as a mailing list admin I never bother if list subscription confirmations bounce back wanting challenge-response effort: having to make a human do that completely defeats the purpose of an automated mailing list sign-up system.

    I used to use lots of different addresses at my domain for different purposes, but I found this caused a little confusion for people. It’s more convenient for them if I have one address, it’s short, and it’s the same for each of my friends (especially important to be the same for friends who are likely to mail me plus each other in the same mail).

    Some people go for web forms intead of giving out their addresses. But I find typing into a gecko textarea considerably more hassle than typing into my mailer’s editor; also I don’t easily get to keep a record of what I’ve said.

    There’s a difference between “anybody can get in touch with you if they needed to”, and “it’s convenient for people who should be able to get in touch with you to do so using their normal way of sending mail”.

  9. Smylers basically said what I was going to say to Prog :-) Inconveniencing others to protect yourself from spam is, IMO, a selfish trade-off.

    As for other ideas, I currently use a script-based one on my website, falling back to a page where people have to type the address in by hand. But the disadvantage of that is that it requires script for the most convenient effect. The reason I like this new proposal is that it doesn’t. No-one has “form submission” turned off in their browser :-)

    And, for those for whom this idea gives “mailto: is not a registered protocol”, then your machine is incorrectly configured. (Of course, if it’s not possible to configure it correctly, then we either need to fix a bug in Firefox, or you need a new OS.)

  10. Implemented right, C/R can be problem-free for both sides. Read this: http://www.templetons.com/brad/spam/challengeresponse.html

    Anyway, I wouldn’t really care if my C/R address isn’t “fully contactable”. I only use it when I know my address is going to be displayed on the web (e.g. in bugzilla.mozilla.org or in blogs that enforce it). Can you suggest anything else that would meet the following needs:

    1. Allow all b.m.o mail through
    2. Be completely unaffected by harvesting
    3. Still allow (at least) some mail from third party non-spammers through

    The only option I can think of is to use a separate address and block everyone but bugzilla.mozilla.org, but this fails requirement #3

    Any alternatives?

    Thanks,

    Prog.

  11. <span id=”idMail”></span>

    <script type=”text/javascript”>
    window.onload = main;
    function main()
    {
    var to = ‘user’ + String.fromCharCode(64) + ‘host’ + ‘.org’;
    var a = document.createElement(‘a’);
    a.appendChild(document.createTextNode(to));
    a.href = ‘mailto:’ + to;
    document.getElementById(“idMail”).appendChild(a);
    }
    </script>

  12. Ok, some comments to the newsgroup list :) (i already thought about this some month ago and saved my changes on harddisk):
    1. .general vs. .misc: In some hierarchies there is only a misc group and in some only a general group. Maybe the catch-all group should have the same name across all hierarchies (normally that’s misc, but general is ok, too)?
    2. There are two newsgroups with .rdf at the end of the name, mozilla.dev.tech.rdf and mozilla.web-developers.rdf (which is bad). Maybe we could come up with a better solution for that?

  13. mozilla.dev.proj.mozilla-suite –
    mozilla.dev.proj.seamonkey –

    how do these differ?

    One’s for 1.7.x development, one’s for the new seamonkey project. The idea is that each project has a group for development issues specific to that project.

    2. There are two newsgroups with .rdf at the end of the name, mozilla.dev.tech.rdf and mozilla.web-developers.rdf (which is bad). Maybe we could come up with a better solution for that?

    That’s why the groups have other parts to their names :-) That said, I’m not sure how much web developers use RDF.

  14. “That’s why the groups have other parts to their names”

    Well, yeah, but it can still be an issue, given what the other parts are. Are you asking people to choose the group according to how they classify themselves (thus assuming that everyone is in either one group or the other, but not neither or both)? Or is there a distinction between RDF as used by “developers” (however that’s defined) and web developers (however they are defined)?

    Assuming people can figure out the distinction, I’m not sure there’s enough discussion of RDF from the web development point of view to make it necessary to have a separate group – the odd thread in .general would probably be fine.

    Better to start with fewer groups and add ones as need becomes apparent than to start with groups which end up having no useful content. Adding later is easier than removing later.