Re: [WSG] Encoded mailto links
On 17/10/07 (13:55) I, myself, said: can anyone tell me what is the best accessible way (if any) of encoding a mailto: link? I want to make the email addresses on a site usable to screen reader users, but don't want them harvested by spambots. Javascripted solutions seem like they would create a headache for screen readers, and any plain text equivalent presented in the name of accessibility would simply be harvested instead. And I prefer to avoid jscript if I can anyway. Is there a way out what seems, to my inexperienced eyes, like a catch-22 situation? Just by way of an update on this issue, there was an interesting related article on A List Apart a couple of days ago by Roel Van Gils. http://www.alistapart.com/articles/gracefulemailobfuscation -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links (and accessibility)
On 10/23/07, Moira Clunie [EMAIL PROTECTED] wrote: On 10/19/07, Michael MD [EMAIL PROTECTED] wrote: not much good for someone using a device without sound From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Or Golan I'm guessing that a person who uses a screen reader has sound on his device. Not necessarily - screen reader software can output to synthetic speech and/or to refreshable braille. Some people use a screen reader with a refreshable braille display and no sound. Moira Is there a place I can read about that technology (screen readers with refreshable braille)? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Encoded mailto links (and accessibility)
On 10/19/07, Michael MD [EMAIL PROTECTED] wrote: not much good for someone using a device without sound From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Or Golan I'm guessing that a person who uses a screen reader has sound on his device. Not necessarily - screen reader software can output to synthetic speech and/or to refreshable braille. Some people use a screen reader with a refreshable braille display and no sound. Moira *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 10/19/07, Michael MD [EMAIL PROTECTED] wrote: not much good for someone using a device without sound I'm guessing that a person who uses a screen reader has sound on his device. I'm not saying use only sound, but more like using a gif that has your email in it, and when you click on it sound comes out. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links - and mail sender
Designer, I'd advise you to use some comprehensive PHP mailing libraries (classes): * PHPMailer (http://phpmailer.sourceforge.net/) * Swift mailer (http://www.swiftmailer.org/) Regards, on 10/19/2007 01:43 PM Designer said the following: Ray Leventhal wrote: Patrick H. Lauke wrote: my approach is usually not to put the email address on there and instead provide a contact form, one major annoyance of contact forms for me: as a sender, i don't have a copy of the email in my email client's sent items folder. depending on the complexity of what i'm emailing, this can be quite annoying. P Good point, Patrick. I'll certainly consider offering a checkbox as a UI option for 'send me a copy of the contents of this form'. ~R I'd certainly be interested if this could be done in php by assigning the user's mail address as a string, then posting to it. Anyone done that? -- Abdulrahman Al-Otaiba *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links - and mail sender
Ray Leventhal wrote: Patrick H. Lauke wrote: my approach is usually not to put the email address on there and instead provide a contact form, one major annoyance of contact forms for me: as a sender, i don't have a copy of the email in my email client's sent items folder. depending on the complexity of what i'm emailing, this can be quite annoying. P Good point, Patrick. I'll certainly consider offering a checkbox as a UI option for 'send me a copy of the contents of this form'. ~R I'd certainly be interested if this could be done in php by assigning the user's mail address as a string, then posting to it. Anyone done that? -- Bob www.gwelanmor-internet.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Taking a slightly different approach, any bot visiting your site knows your domain name so at that point they don't need to find any addresses to send to or from [EMAIL PROTECTED] Also, they'll likely assume that things like [EMAIL PROTECTED] exist without you ever publishing an address so obviously what we are trying to protect here are bots discovering actual mailbox addresses. Therefore, never use actual email addresses and only ever one or 2 generic addresses on a website. Use something like a href='mailto:[EMAIL PROTECTED]'email us/a and if it starts to get spammed, change it to [EMAIL PROTECTED] and bounce [EMAIL PROTECTED] If you then needed a few different addresses on a site that appeared across multiple pages, you could have a central config file on the server that mapped addresses like: marketing = [EMAIL PROTECTED] sales = [EMAIL PROTECTED] then when one of these starts getting spam, change it. It's only good for mailto links though and doesn't solve the problem of publishing an address for people to save to their address books. It also means when you click a mailto link the address in the message may look strange to the user. I guess the other thing is if a user saves the address and reuses it later it may bounce. Anyway, just an idea to try and tackle the issue differently. -- Chris Knowles *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
I was just about to post an idea, then i thought, it dont matter what you do if a spam bot gets your email address, which they always do, your going to get spam anyway. So its best to just control it on your end. In the real world businesses in prime locations get bombarded with junk mail, so its just something we have to accept and try to block out with software. On 10/19/07, Chris Knowles [EMAIL PROTECTED] wrote: Taking a slightly different approach, any bot visiting your site knows your domain name so at that point they don't need to find any addresses to send to or from [EMAIL PROTECTED] Also, they'll likely assume that things like [EMAIL PROTECTED] exist without you ever publishing an address so obviously what we are trying to protect here are bots discovering actual mailbox addresses. Therefore, never use actual email addresses and only ever one or 2 generic addresses on a website. Use something like a href='mailto:[EMAIL PROTECTED]'email us/a and if it starts to get spammed, change it to [EMAIL PROTECTED] and bounce [EMAIL PROTECTED] If you then needed a few different addresses on a site that appeared across multiple pages, you could have a central config file on the server that mapped addresses like: marketing = [EMAIL PROTECTED] sales = [EMAIL PROTECTED] then when one of these starts getting spam, change it. It's only good for mailto links though and doesn't solve the problem of publishing an address for people to save to their address books. It also means when you click a mailto link the address in the message may look strange to the user. I guess the other thing is if a user saves the address and reuses it later it may bounce. Anyway, just an idea to try and tackle the issue differently. -- Chris Knowles *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links - and mail sender
Mike at Green-Beast.com skrev: That said, even though people are the most difficult to control, they don't seem to be the real problem. The problem seems to be with 'bots so that's the form's main focus. You're right, bots are the real problem to focus on. /anders *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links - and mail sender
Hello Anders, Is there any way to protect this from being used as a way to send out spam? You can't really know that people enter their own emailaddress ... A person could use it to send the copy to someone else, but then again people are the most difficult to control. I do offer an IP blacklist with this to deal with people if necessary (a weak control at best since not everyone has a static IP). A robot shouldn't be able to do it, though. The form has a number of measures to prevent 'bot submissions and exploitation, one of which is a honeypot (a baited input) which someone had mentioned before. That said, even though people are the most difficult to control, they don't seem to be the real problem. The problem seems to be with 'bots so that's the form's main focus. Cheers. Mike - Original Message - From: Anders Nawroth [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Friday, October 19, 2007 10:46 AM Subject: Re: [WSG] Encoded mailto links - and mail sender Hi! Mike at Green-Beast.com skrev: I offer that in my contact form. It's a config option. The contact form owner can enable/disable offering a get-a-copy option to his/her visitors. Is there any way to protect this from being used as a way to send out spam? You can't really know that people enter their own emailaddress ... /anders *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Encoded mailto links
Thanks for that Nick, I changed the example domain. If you do want to test it though you would need to copy the code, change it to you own domain and email addresses, and put it on your own server. Best Regards, Kepler -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Fitzsimons Sent: Friday, October 19, 2007 9:06 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Encoded mailto links On 19 Oct 2007, at 04:59, Kepler Gelotte wrote: I created a test page that demonstrates the technique. I tested it with my email but changed it to a dummy domain so I won't get flooded with emails. Kepler, mydomain.com isn't a dummy domain: http://www.whois.net/whois_new.cgi?d=mydomaintld=com If you need to use a dummy domain name, example.com and others have been reserved for exactly that purpose: To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. http://www.ietf.org/rfc/rfc2606.txt Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Hi! Chris Knowles skrev: Plus you're still putting the email address in the source code albeit a modified version. If this became a popular way to handle mailtos a harvester is sure to be written to pattern match http://.../com/... or http://.../com/au/... or whatever at some stage and attempt to construct an email address from it. You could either use a key in the URL. http://example.com/mail/key which the server resolves to an emailaddress stored in a database backend, or you could add some arbitrary string to make it more difficult for harvesters: http://example.com/mail/me/arbitrary/stuff/to/confuse/harvesters The domain shouldn't be needed, your server sould already know it. It's a pity that the support for mailto: locations isn't better, though. As for now I still wouldn't attempt using it. /anders *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Andrew Maben wrote: On Oct 18, 2007, at 4:19 PM, Dejan Kozina wrote: Anybody (Mac Linux browsers...) wants to take a ride? The thing is up there at http://www.kozina.com/mailtest/ . Let us know of your results. worked for me: MacOS 10.4.9/Safari 2.0.4 Andrew I noticed this page also uses entity encoding. This is a solution I have used myself but the more I think about it the more I realise realise how ineffective it is really. take the following PHP code: // some page fetching function $html = fetchPage($url); // convert any entites in the page to plain text $html = html_entity_decode($html); now $html contains plain email addresses - with one line of code surely any harvester performs this operation first? -- Chris Knowles *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Andrew Maben wrote: On Oct 18, 2007, at 4:19 PM, Dejan Kozina wrote: Anybody (Mac Linux browsers...) wants to take a ride? The thing is up there at http://www.kozina.com/mailtest/ . Let us know of your results. worked for me: MacOS 10.4.9/Safari 2.0.4 Not mac or linux but... win xp, firefox 2, thunderbird 2 opens 2 mail messages, both with the correct email address redirects to this url: http://www.kozina.com/mailtest/example/com/me with this content: Found The document has moved here. I tried setting this up myself on win xp, apache 2.2 and fiddled a lot with the rewrite rules and i got mixed results at best. As far as I'm concerned it's too unreliable to use. Plus you're still putting the email address in the source code albeit a modified version. If this became a popular way to handle mailtos a harvester is sure to be written to pattern match http://.../com/... or http://.../com/au/... or whatever at some stage and attempt to construct an email address from it. -- Chris Knowles *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links - and mail sender
Mike at Green-Beast.com wrote: Good point, Patrick. I'll certainly consider offering a checkbox as a UI option for 'send me a copy of the contents of this form'. I'd certainly be interested if this could be done in php by assigning the user's mail address as a string, then posting to it. Anyone done that? I offer that in my contact form. It's a config option. The contact form owner can enable/disable offering a get-a-copy option to his/her visitors. http://green-beast.com/blog/?page_id=71 (Stand alone version) http://green-beast.com/blog/?page_id=136 (WordPress version) Cheers. Mike Cherim Thanks Mike, that looks wonderful! (I've downloaded the zip!) -- Bob www.gwelanmor-internet.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On Oct 18, 2007, at 4:19 PM, Dejan Kozina wrote: Anybody (Mac Linux browsers...) wants to take a ride? The thing is up there at http://www.kozina.com/mailtest/ . Let us know of your results. worked for me: MacOS 10.4.9/Safari 2.0.4 Andrew *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 10/19/07, Chris Knowles [EMAIL PROTECTED] wrote: I noticed this page also uses entity encoding. This is a solution I have used myself but the more I think about it the more I realise realise how ineffective it is really. take the following PHP code: // some page fetching function $html = fetchPage($url); // convert any entites in the page to plain text $html = html_entity_decode($html); now $html contains plain email addresses - with one line of code surely any harvester performs this operation first? Hi Chris, I often see the same argument about Javascript. That is, it is trivial to embed a Javscript interpreter in an email address harvester, so Javascript-protected email addresses are (or soon will be) vulnerable. IMHO, arguments based on the cost of programming the harvester are misguided. Far more important is the CPU and memory cost of running the harvester over the long term. For the harvester, both increased throughput and increased intelligence imply increased addresses harvested. But the former buys them much more simply in sheer numbers -- most addresses are presented unprotected. And the latter (clever harvesting, like running html_entity_decode) is only likely to harvest the addresses of Net-savvy individuals who are the least likely (we hope!) to respond to spam and phishing. One could even argue that a clever harvester is counterproductive in that it will pollute its database with the addresses of these Net-savvy individuals. In short, I think harvesters download HTML pages and run a regex that looks for '@' with text on either side. They care about getting as many email addresses as possible as quickly as possible. Just my $.02, -- Philip http://NikitaTheSpider.com/ Whole-site HTML validation, link checking and more *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 19 Oct 2007, at 04:59, Kepler Gelotte wrote: I created a test page that demonstrates the technique. I tested it with my email but changed it to a dummy domain so I won't get flooded with emails. Kepler, mydomain.com isn't a dummy domain: http://www.whois.net/whois_new.cgi?d=mydomaintld=com If you need to use a dummy domain name, example.com and others have been reserved for exactly that purpose: To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. http://www.ietf.org/rfc/rfc2606.txt Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
djn, I tested on Kubuntu 7.04 using the following browsers: * Konqueror 3.5.6, correct behavior, opens the default mail application with the email in the TO field * Firefox 2.0.0.6, incorrect, goes to a 302 Found page with a matilto link to the email specifies. Regards, on 10/18/2007 11:19 PM Dejan Kozina said the following: Anybody (Mac Linux browsers...) wants to take a ride? The thing is up there at http://www.kozina.com/mailtest/ . Let us know of your results. djn -- Abdulrahman Al-Otaiba http://www.mawqey.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links - and mail sender
Good point, Patrick. I'll certainly consider offering a checkbox as a UI option for 'send me a copy of the contents of this form'. I'd certainly be interested if this could be done in php by assigning the user's mail address as a string, then posting to it. Anyone done that? I offer that in my contact form. It's a config option. The contact form owner can enable/disable offering a get-a-copy option to his/her visitors. http://green-beast.com/blog/?page_id=71 (Stand alone version) http://green-beast.com/blog/?page_id=136 (WordPress version) Cheers. Mike Cherim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links - and mail sender
Hi! Mike at Green-Beast.com skrev: I offer that in my contact form. It's a config option. The contact form owner can enable/disable offering a get-a-copy option to his/her visitors. Is there any way to protect this from being used as a way to send out spam? You can't really know that people enter their own emailaddress ... /anders *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Screen readers run on top of normal browsers like IE of Firefox Didn't know that this is how screen readers work. Well, the best way to let visually impaired people see your email, is just do something the spambots can't get and the ones you want to gets the email will get it. Simply put it as an audio file. Record yourself reading your email, the spambots can't get it and the people using screen readers will simply click on the audio file and listen to the email, just as if it was written there. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Hi! Nikita The Spider The Spider skrev: You might be interested in an experiment I ran that compared a few techniques for protecting one's email address from harvesting bots. The short answer: entity references worked very well I think the time span of your study is to short. I have used the method you used for äcklig, with mixed decimal and hexadecimal numeric entities. In about a year there was no spam, but somewhere at 1.5 years it started a little, and after 2 years there where 100+ spam/day. So I think you just push the problem forward, which could be fine in some cases. But when a entity-decoding spam harvester finds the email-address, this will get listed in the same databases as all other emailaddresses. The more traffic your site has, the less difference the encoding will make. I think the htaccess-trick linked to by Dejan Kozina looks more promising. I have used this method, but abandoned it because of that some browser wouldn't send the mailto: address to the email client. But this was a few years ago, so this could possibly have changed. If you already use .htaccess rewrite rules this is very simple to implement. The question is of course if harvester have implemented a way to capture those email-addresses too, but I think this would require more knowledge than decoding numerical entities (for instance the PHP manual describes how to do this ...). /anders *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 10/18/07, Anders Nawroth [EMAIL PROTECTED] wrote: Hi! Nikita The Spider The Spider skrev: You might be interested in an experiment I ran that compared a few techniques for protecting one's email address from harvesting bots. The short answer: entity references worked very well I think the time span of your study is to short. I have used the method you used for äcklig, with mixed decimal and hexadecimal numeric entities. In about a year there was no spam, but somewhere at 1.5 years it started a little, and after 2 years there where 100+ spam/day. Hej Anders, That's very interesting, thanks for letting me know! So I think you just push the problem forward, which could be fine in some cases. But when a entity-decoding spam harvester finds the email-address, this will get listed in the same databases as all other emailaddresses. The more traffic your site has, the less difference the encoding will make. I agree. I assumed (wrongly) that the 200+ days of the study was long enough to get found by any harvesters that bothered to decode entities. I'm not surprised to learn, however, that once the address was exposed that it received an ever-increasing amount of spam. This is consistent with my intuition and also what I observed. I think the htaccess-trick linked to by Dejan Kozina looks more promising. I have used this method, but abandoned it because of that some browser wouldn't send the mailto: address to the email client. But this was a few years ago, so this could possibly have changed. This method looks promising to me too but I haven't had a chance to test it yet. -- Philip http://NikitaTheSpider.com/ Whole-site HTML validation, link checking and more *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Nikita The Spider The Spider wrote: On 10/18/07, Anders Nawroth [EMAIL PROTECTED] wrote: Hi! Nikita The Spider The Spider skrev: You might be interested in an experiment I ran that compared a few techniques for protecting one's email address from harvesting bots. The short answer: entity references worked very well I think the time span of your study is to short. I have used the method you used for äcklig, with mixed decimal and hexadecimal numeric entities. In about a year there was no spam, but somewhere at 1.5 years it started a little, and after 2 years there where 100+ spam/day. Hej Anders, That's very interesting, thanks for letting me know! So I think you just push the problem forward, which could be fine in some cases. But when a entity-decoding spam harvester finds the email-address, this will get listed in the same databases as all other emailaddresses. The more traffic your site has, the less difference the encoding will make. I agree. I assumed (wrongly) that the 200+ days of the study was long enough to get found by any harvesters that bothered to decode entities. I'm not surprised to learn, however, that once the address was exposed that it received an ever-increasing amount of spam. This is consistent with my intuition and also what I observed. I think the htaccess-trick linked to by Dejan Kozina looks more promising. I have used this method, but abandoned it because of that some browser wouldn't send the mailto: address to the email client. But this was a few years ago, so this could possibly have changed. This method looks promising to me too but I haven't had a chance to test it yet. Hi all, As a matter of preference, I generally try to eliminate all mailto: links on any site I've been asked to work on. In place, I use a contact form, usually with a password protected admin interface where the site owner, with creds, can add to, edit or remove what entities are listed in the drop-down for 'to'. Then using some php, I generate the mail, scripted on the server side to avoid open publication of users' email addresses. I understand that not everyone wants or is able to do server-side scripting, but for me it seems to be the best solution. It's far more work than adding mailto:, certainly, but I find that it's working well and while I don't charge more for that, my clients generally see it as a value-added service. Just my drop in the bucket :) Philip, I truly loved the article/research results on the obfuscation techniques. Very very informative...thank you. The .htaccess method is quite viable, imnsho, but does require a web server which follows the .htaccess/.htpasswd paradigm. I may well do some testing to see how the re-write directives affect accessibility (if at all). Interesting topic, this. Thank you all for some really informative insights. Kind regards, ~Ray *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Hi! Ray Leventhal skrev: As a matter of preference, I generally try to eliminate all mailto: links on any site I've been asked to work on. In place, I use a contact form, Me too :-) But then you get form-post spam after a while ... I have begun to add a random token as a hidden field to forms (which is then checked on the server side, ensuring that a form can only be posted once), stopping bots that don't actually read the form every time. (I actually think most of them don't ... when I change the field names in forms the spam form posts continue to use the old ones for a long time.) The random token method is 100 % standards compliant and so on, but rather easy for bots to work around. Still more difficult than decoding mailto links. Also randomly changing the name of the token field would be the next step (requiring bots to examine the form for the current token field name and content in every form every time). A human spammer (not using a bot) will of course be able to send the form, but I think people sitting and copy-pasting spam into forms is not a big concern. Captchas is also a possibilty, but I sometimes have difficulties reading them myself. Not very user friendly. Random tokens are more user-friendly, as they are handled automatically by the browser, and not even seen by the user. But it's not so easy to add it to every site, it depends on the architecture used and you need some scripting language on the server (but I think most sites have this anyway today). IMHO captchas are used too much, as they suck considerably! /anders *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 18 Oct 2007, at 15:49, Anders Nawroth wrote: IMHO captchas are used too much, as they suck considerably! And they are also frowned upon by the W3C because of their inaccessibility, and the fact that they provide a false sense of security: http://www.w3.org/TR/turingtest/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Encoded mailto links
I just got curious and went on to test that .htaccess trick in the real world. I'd say that I'm less than happy with the results. I tried some tests with similar behavior. I think I found a technique that gets around the problem. By initiating the mailto: redirect from an object embedded on your page, you get around the problem of the browser waiting for HTML to display. This method doesn't work on all browsers (safari on windows for example) so a submission form is also required. I created a test page that demonstrates the technique. I tested it with my email but changed it to a dummy domain so I won't get flooded with emails. The link is: http://www.neighborwebmaster.com/tests/safe_email.php Regards, Kepler Gelotte *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
I've followed the technique below; I find it much simpler to follow these techniques (and change the fieldnames occasionally), than try to get accurate spam filtering at the server level. We actually hired a company, spamstop.ca, to filter our results for our College. It's better, but still a case of I'm getting too much spam! and then I didn't get that email! For other email addresses (or projects), I've used Hiveware Enkoder ( http://hivelogic.com/enkoder ) and that seemed to work, with noscript pointing to a form or textual description of the email address. Seems to help... Ray Leventhal wrote: As a matter of preference, I generally try to eliminate all mailto: links on any site I've been asked to work on. In place, I use a contact form, Anders Nawroth wrote: Me too :-) But then you get form-post spam after a while ... To minimize form-post spam, I've taken to employing a technique I learned early on in my phpBB admin days. It amounts to including a field which is extra and which must remain empty for any process action to take place. Visible text informing the *human* user to leave the field blank or risk their post not reaching the destination is placed clearly near the field. The processing script is instructed to simply ignore the form if the 'extra' field has anything in it. In php, I do this with a combination of trim and strlen on the $_POST['fieldname'] value. Naming the form field attribute something interesting like 'email_address_confirm' makes this more effective. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On Oct 19, 2007, at 5:19 AM, Dejan Kozina wrote: Anybody (Mac Linux browsers...) wants to take a ride? The thing is up there at http://www.kozina.com/mailtest/ . Let us know of your results. running OS X 10.4.10 + Mail.app * WebKit latest build + Safari 3.0beta + Safari 2.04 : opens a new mail message; page stays where it was (no redirect). * Camino 2.0a1pre/Minefield + Fx 2.0.0.8pre: open a new message/ redirect to a page [1]. * Opera 9.5 alpha: bugs me about choosing an email client, but then opens a new mail message and stays on the page (no redirect). * iCab 303: opens a new mail message and stays on the page (no redirect) * IE 5.23 Mac: opens a new mail message, no redirect. [1] http://www.kozina.com/mailtest/example/com/me Found The document has moved here. I don't know enough about 302 code to know if this could be a correct behaviour or not. Philippe --- Philippe Wittenbergh http://emps.l-c-n.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Patrick H. Lauke wrote: my approach is usually not to put the email address on there and instead provide a contact form, one major annoyance of contact forms for me: as a sender, i don't have a copy of the email in my email client's sent items folder. depending on the complexity of what i'm emailing, this can be quite annoying. P Good point, Patrick. I'll certainly consider offering a checkbox as a UI option for 'send me a copy of the contents of this form'. ~R *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Thanks for the heads up on that, Patrick. I'm going to contact him and ask he remove that. Domain registration records is another source I think. :-( Cheers. Mike - Original Message - From: Patrick H. Lauke [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Thursday, October 18, 2007 7:50 PM Subject: Re: [WSG] Encoded mailto links Mike at Green-Beast.com wrote: My personal policy is to never put an email address on the web unless it's written out using plain text The problem there is that, quite often, you don't have much control over things like web-based email archives, e.g. http://www.w3.org/Search/Mail/Public/search?keywords=cherim (though admittedly there are only 3 hits, matching an old email address of yours, but still...all it takes is one occurrence somewhere on the web) oh, this was interesting (check the first post there) http://www.sitepoint.com/forums/showthread.php?p=2312012 -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Well, the best way to let visually impaired people see your email, is just do something the spambots can't get and the ones you want to gets the email will get it. Simply put it as an audio file. Record yourself reading your email, the spambots can't get it and the people using screen readers will simply click on the audio file and listen to the email, just as if it was written there. not much good for someone using a device without sound *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 10/18/07, Anders Nawroth [EMAIL PROTECTED] wrote: Ray Leventhal skrev: As a matter of preference, I generally try to eliminate all mailto: links on any site I've been asked to work on. In place, I use a contact form, Me too :-) But then you get form-post spam after a while ... I have begun to add a random token as a hidden field to forms (which is then checked on the server side, ensuring that a form can only be posted once), stopping bots that don't actually read the form every time. (I actually think most of them don't ... when I change the field names in forms the spam form posts continue to use the old ones for a long time.) Mail forms (badly coded ones at least) are also vulnerable to SMTP header injection. Once spammers find a vulnerable form, they can use tools like curl to POST data to your mail processing script without even loading the form. Challenge tokens like yours are a good solution to this problem. FYI, I ran into a nasty problem with Safari related to a challenge string embedded in a logon form. Funnily enough, the solution is to change the field name, as you're doing, Anders. Here's the problem and a solution just to save someone else some headaches. Forgive me, all, if this is getting too far afield for this list. I generated the challenge string server-side and stuffed it into a hidden input field with a name and id of challenge. When I submitted the form I was sent to ProcessLogin.xxx. If I then hit the back button (say because my password was rejected), Safari respected my cache control directives and reloaded the page from the server, thus getting a new challenge string. BUT, once the page was loaded, Safari helpfully repopulated the input fields with the values they held prior to form submission. This was nice in the case of the userid because it saved me some typing, but it caused a problem with the challenge field because Safari *overwrote it with the old challenge string*. The order of events was as follows: 1) I hit back: 2) Safari gets a new copy of the page from the server. This creates a new challenge string that embedded in the challenge field of the page. 3) Safari (re)populates form fields with the values they held when the form was submitted. 4) Safari executes the page's Javascript. What was very confusing was that even View Source showed that the page had the new challenge string but it was the old string that was sent over the wire when I resubmitted the form. (Thank you Wireshark.) Because of the order of 3 4, I could have solved this problem by (re)setting the challenge field in the onLoad event. But that might not fix the problem if there's another browser that has the same quirk but executes those steps in a different order. Instead I came up with the solution of using the challenge string as the field id/name instead of its value. (The value is simply challenge.) Safari's helpfulness leaves this field untouched since it has a new name every time the page is loaded. The challenge string still gets transmitted to ProcessLogin.xxx, I just have to find it by looking through the form field names rather than their values. Note that since the challenge string appears as a form control name and form control names must begin with a letter per the HTML spec, challenge strings have to start with a letter. -- Philip http://NikitaTheSpider.com/ Whole-site HTML validation, link checking and more *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Hello all again. I just got curious and went on to test that .htaccess trick in the real world. I'd say that I'm less than happy with the results. With Thunderbird as the default mail app on Windows XP SP2, IE7, Firefox 2.0.0.7 and Seamonkey 1.1.4 did indeed open a new message window with the correct addressee in the To: field. The main browser window, in meantime, went to a blank page in IE and a Found - The document has moved here. page in Gecko browsers. The design part of my soul cried thinking at website visitors landing there after clicking a link... Even worse, both Opera 9.23 and Safari 3.0.3 failed to open a message compo window. Opera just hanged there spinning a 'busy' cursor, while Safari informed me that »The page you opened redirected you to a page that isn’t supported by Safari. Safari can’t open the page “http://www.kozina.com/mailtest/example/com/me” because it cannot redirect to locations starting with “http:”.« I guess there is a 'not' missing somewhere. Anybody (Mac Linux browsers...) wants to take a ride? The thing is up there at http://www.kozina.com/mailtest/ . Let us know of your results. djn -- - Dejan Kozina Web design studio Dolina 346 (TS) - I-34018 Italy tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina http://www.kozina.com/ - e-mail: [EMAIL PROTECTED] *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Hi Anders, Ray Leventhal wrote: As a matter of preference, I generally try to eliminate all mailto: links on any site I've been asked to work on. In place, I use a contact form, Anders Nawroth wrote: Me too :-) But then you get form-post spam after a while ... To minimize form-post spam, I've taken to employing a technique I learned early on in my phpBB admin days. It amounts to including a field which is extra and which must remain empty for any process action to take place. Visible text informing the *human* user to leave the field blank or risk their post not reaching the destination is placed clearly near the field. The processing script is instructed to simply ignore the form if the 'extra' field has anything in it. In php, I do this with a combination of trim and strlen on the $_POST['fieldname'] value. Naming the form field attribute something interesting like 'email_address_confirm' makes this more effective. I know there are bots which will get around this, but on at least 3 forms which had been receiving tons of form-spam, we've cut it down by over 80% just with this one technique. IMHO captchas are used too much, as they suck considerably! ditto ditto ditto :) big time agreement here. Kind regards, ~Ray *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Encoded mailto links
Hi, can anyone tell me what is the best accessible way (if any) of encoding a mailto: link? I want to make the email addresses on a site usable to screen reader users, but don't want them harvested by spambots. Javascripted solutions seem like they would create a headache for screen readers, and any plain text equivalent presented in the name of accessibility would simply be harvested instead. And I prefer to avoid jscript if I can anyway. Is there a way out what seems, to my inexperienced eyes, like a catch-22 situation? Cheers; -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Encoded mailto links
Rick Lecoat Is there a way out what seems, to my inexperienced eyes, like a catch-22 situation? Fix your spam issues at the mail server + mail client end, not at the web page end, would be my advice. P Patrick H. Lauke Web Editor Enterprise Development University of Salford Room 113, Faraday House Salford, Greater Manchester M5 4WT UK T +44 (0) 161 295 4779 [EMAIL PROTECTED] www.salford.ac.uk A GREATER MANCHESTER UNIVERSITY *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Rick Lecoat wrote:
can anyone tell me what is the best accessible way (if any) of encoding
a mailto: link? I want to make the email addresses on a site usable to
screen reader users, but don't want them harvested by spambots.
Javascripted solutions seem like they would create a headache for screen
readers, and any plain text equivalent presented in the name of
accessibility would simply be harvested instead. And I prefer to avoid
jscript if I can anyway.
I too am interested to know what others are doing. Javascript seems the
best way because you can keep the code to generate and insert a mailto
external to the html file but you have to cover the problem where
javascript can't be used.
I have a function I wrote in PHP that converts a string of characters to
their ASCII values and this works ok but is still in the html code so
maybe harvesters look for the ASCII value of the @ symbol and find
addresses still?
function htmlEncode($str)
{
$encoded = ;
for ($i = 0; $i strlen($str); $i++) {
$encoded .= #.ord($str[$i]).;;
}
return $encoded;
}
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Encoded mailto links
Rick Lecoat Is there a way out what seems, to my inexperienced eyes, like a catch-22 situation? Patrick Lauke wrote: Fix your spam issues at the mail server + mail client end, not at the web page end, would be my advice. This is good advice and raises the question of whether theres any real need or point in encoding email addresses on web pages at all. All anyone needs is a domain name and they can send mail to (or from) a dictionary of names @domain.name anyway. I guess that when clients want their own email addresses on pages and not just info@ or something generic there is maybe argument for encoding. As for screen readers, are html entities a problem? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Hi! Chris Knowles skrev: maybe harvesters look for the ASCII value of the @ symbol and find addresses still? Some harvesters decodes the links, so this is not a solution to the spam problem. The decoding is really trivial to perform in most programming languages. /anders *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 17 Oct 2007, at 13:55, Rick Lecoat wrote: can anyone tell me what is the best accessible way (if any) of encoding a mailto: link? I want to make the email addresses on a site usable to screen reader users, but don't want them harvested by spambots. I, long ago, gave up trying. Methods are either highly ineffective, or block out users you want as well as spam bots. I take the view that email addresses are going to end up on spam lists eventually no matter what I do, and just run spam filtering software. -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On Oct 17, 2007, at 8:55 AM, Rick Lecoat wrote: can anyone tell me what is the best accessible way (if any) of encoding a mailto: link? To answer a question w/ a question: I have started encoding email address strings, but your question makes me wonder how accessible this may be? How do screen readers dal with encoded characters, and how does a screen reader deal with a plain text email address? Andrew *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 17/10/07 (14:16) Patrick said: Fix your spam issues at the mail server + mail client end, not at the web page end, would be my advice. David said: I, long ago, gave up trying. Methods are either highly ineffective, or block out users you want as well as spam bots. I take the view that email addresses are going to end up on spam lists eventually no matter what I do, and just run spam filtering software. So the general consensus would seem to be forgeddabowdit. I wondered if that would be the result, but I'm surprised that there isn't a workaround -- only because almost everything else that I thought would be impossible some clever person has found a way to do. To join with Andrew Maben, however, I'd be curious to know whether spambots decode encoded entity text, eg: 'user' becomes '#117;#115;#101;#114;' (ignore quote marks). I assume that they can read them perfectly easily -- browsers can, after all -- but it'd be good to know for sure. Same question for screen readers. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Why not simply display the email address as a simple mailto only when the browser is a screen reader? On 10/17/07, Rick Lecoat [EMAIL PROTECTED] wrote: On 17/10/07 (14:16) Patrick said: Fix your spam issues at the mail server + mail client end, not at the web page end, would be my advice. David said: I, long ago, gave up trying. Methods are either highly ineffective, or block out users you want as well as spam bots. I take the view that email addresses are going to end up on spam lists eventually no matter what I do, and just run spam filtering software. So the general consensus would seem to be forgeddabowdit. I wondered if that would be the result, but I'm surprised that there isn't a workaround -- only because almost everything else that I thought would be impossible some clever person has found a way to do. To join with Andrew Maben, however, I'd be curious to know whether spambots decode encoded entity text, eg: 'user' becomes '#117;#115;#101;#114;' (ignore quote marks). I assume that they can read them perfectly easily -- browsers can, after all -- but it'd be good to know for sure. Same question for screen readers. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 18/10/07 (15:20) Chris said: Well I guess now I really think about it you can't solve it as you could append an email address to the DOM from an obfuscated javascript function and that would likely solve the problem but it's not an accessible solution. For screen readers you need to have the email address in the HTML code and whether it's encoded or not it's accessible to harvesters. Therefore theres no solution, so as Patrick said, Fix your spam issues at the mail server + mail client end Fair enough. One less item on the 'things to clarify' list; thanks everyone. (Of course, I rarely have control over the client's mail server, still less their email client. I suppose that becomes their problem). -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Rick Lecoat wrote: I'm surprised that there isn't a workaround -- only because almost everything else that I thought would be impossible some clever person has found a way to do. Well I guess now I really think about it you can't solve it as you could append an email address to the DOM from an obfuscated javascript function and that would likely solve the problem but it's not an accessible solution. For screen readers you need to have the email address in the HTML code and whether it's encoded or not it's accessible to harvesters. Therefore theres no solution, so as Patrick said, Fix your spam issues at the mail server + mail client end -- Chris Knowles *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 17/10/07 (15:33) Or said: Why not simply display the email address as a simple mailto only when the browser is a screen reader? If you mean by CSS (display: none -- or similar -- for aural media types), I'm not sure that would work because AFAIk spambots just look through the source code of the page for mailto links. The fact that the text is hidden when it gets to the browser is neither here nor there, surely? If you are talking about actually hiding markup from certain agent types, I'd certainly like to know your method. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Encoded mailto links
Because you can't detect when a screen reader is there or not... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Or Golan Sent: 17 October 2007 15:33 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Encoded mailto links Why not simply display the email address as a simple mailto only when the browser is a screen reader? On 10/17/07, Rick Lecoat [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 17/10/07 (14:16) Patrick said: Fix your spam issues at the mail server + mail client end, not at the web page end, would be my advice. David said: I, long ago, gave up trying. Methods are either highly ineffective, or block out users you want as well as spam bots. I take the view that email addresses are going to end up on spam lists eventually no matter what I do, and just run spam filtering software. So the general consensus would seem to be forgeddabowdit. I wondered if that would be the result, but I'm surprised that there isn't a workaround -- only because almost everything else that I thought would be impossible some clever person has found a way to do. To join with Andrew Maben, however, I'd be curious to know whether spambots decode encoded entity text, eg: 'user' becomes '#117;#115;#101;#114;' (ignore quote marks). I assume that they can read them perfectly easily -- browsers can, after all -- but it'd be good to know for sure. Same question for screen readers. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Encoded mailto links
Rick Lecoat To join with Andrew Maben, however, I'd be curious to know whether spambots decode encoded entity text, eg: 'user' becomes '#117;#115;#101;#114;' (ignore quote marks). I assume that they can read them perfectly easily -- browsers can, after all -- but it'd be good to know for sure. Same question for screen readers. All that would take for a spambot is to do a two-pass: replace all encoded entities, then scan the result for email-address-like patterns. Trivial. And once an email address is harvested by one bot, it's likely to end up on lists that are then sold and shared around...so even if not all spambots will bother with a two-pass, it's not a safe way to go about things...and I'd say it's more trouble than it's worth (makes editing the page a pain for non-techie users, for instance). P Patrick H. Lauke Web Editor Enterprise Development University of Salford Room 113, Faraday House Salford, Greater Manchester M5 4WT UK T +44 (0) 161 295 4779 [EMAIL PROTECTED] www.salford.ac.uk A GREATER MANCHESTER UNIVERSITY *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Encoded mailto links
Rick Lecoat If you are talking about actually hiding markup from certain agent types, I'd certainly like to know your method. Screen readers run on top of normal browsers like IE of Firefox, so user-agent-wise you won't be able to really distinguish them. You *may* be able to catch some specialised talking browsers, but who uses those nowadays? P Patrick H. Lauke Web Editor Enterprise Development University of Salford Room 113, Faraday House Salford, Greater Manchester M5 4WT UK T +44 (0) 161 295 4779 [EMAIL PROTECTED] www.salford.ac.uk A GREATER MANCHESTER UNIVERSITY *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On Oct 17, 2007, at 11:19 AM, Patrick Lauke wrote: All that would take for a spambot is to do a two-pass: replace all encoded entities, then scan the result for email-address-like patterns. Trivial. Thanks, Patrick - guess I'll abandon that effort... Andrew *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Or Golan wrote: Why not simply display the email address as a simple mailto only when the browser is a screen reader? A screen reader attaches to a visual browser as an add-on thus it cannot be detected. It's a shame as that would solve some problems. Text browsers can be detected, but screen readers cannot. Moreover, once that is relied upon it can be spoofed. I created two experimental solutions. [1] One was found out due to browser spoofing and I now get a spam or two each week. [2] My other experiment has proven itself effective thus far, and to the best of my knowledge it is quite accessible. I agree with Patrick that solving the issue on the site isn't the best way, but only to a degree as it leaves two things up in the air. One is a problem for me in that I cannot apply filters because I need to gauge solution effectiveness. The other is exposing my email and filtering on the mail server will still make the email available to harvesters. Harvesters don't just use your email to send you spam, but they also use it as a from or reply-to on spam sent to others. It'll look like it came from you. My personal policy is to never put an email address on the web unless it's written out using plain text so it's understandable to people but not understandable to robots (Send mail to mikecherim at this domain... etc). Most obfuscation techniques I've seen either don't work well or they aren't accessible to all. As far as character encoding doesn't work (using server side tech or JS), though it is accessible. Cheers. Mike Cherim http://green-beast.com/ [1] Somewhat effective but not completely: http://mikecherim.com/experiments/php_hide_email.php [2] So far so good (knock-on-wood): http://mikecherim.com/experiments/php_email_protector.php - Original Message - From: Or Golan [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Wednesday, October 17, 2007 10:33 AM Subject: Re: [WSG] Encoded mailto links Why not simply display the email address as a simple mailto only when the browser is a screen reader? On 10/17/07, Rick Lecoat [EMAIL PROTECTED] wrote: On 17/10/07 (14:16) Patrick said: Fix your spam issues at the mail server + mail client end, not at the web page end, would be my advice. David said: I, long ago, gave up trying. Methods are either highly ineffective, or block out users you want as well as spam bots. I take the view that email addresses are going to end up on spam lists eventually no matter what I do, and just run spam filtering software. So the general consensus would seem to be forgeddabowdit. I wondered if that would be the result, but I'm surprised that there isn't a workaround -- only because almost everything else that I thought would be impossible some clever person has found a way to do. To join with Andrew Maben, however, I'd be curious to know whether spambots decode encoded entity text, eg: 'user' becomes '#117;#115;#101;#114;' (ignore quote marks). I assume that they can read them perfectly easily -- browsers can, after all -- but it'd be good to know for sure. Same question for screen readers. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 17/10/07 (16:20) Patrick said: Screen readers run on top of normal browsers like IE of Firefox Ah, I did *not* know that -- I thought that they were a sort of self- contained browser themselves. Thanks for that heads-up. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Hello list. This is what I use in my Smarty templates:
a href=mailto:{ #email#|escape:hex }
{ #email#|escape:hexentity }
/a
With this, [EMAIL PROTECTED] becomes:
a href=mailto:%6d%65%40%6d%65%2e%63%6f%6d;
#x6d;#x65;#x40;#x6d;#x65;#x2e;#x63;#x6f;#x6d;
/a
It's not foolproof, but my customers are generally happy with the result.
This other trick I haven't tried yet, but sure sounds good to me:
http://www.htaccesselite.com/htaccess/use-htaccess-to-hide-mailto-links-vt181.html
I posted about this on the WebAIM list back in February and nobody seems
to have found objections to it, accessibility-wise.
djn
Rick Lecoat wrote:
can anyone tell me what is the best accessible way (if any) of encoding
a mailto: link? I want to make the email addresses on a site usable to
screen reader users, but don't want them harvested by spambots.
--
-
Dejan Kozina Web design studio
Dolina 346 (TS) - I-34018 Italy
tel./fax: +39 040 228 436 - cell.: +39 348 7355 225 skype: dejankozina
http://www.kozina.com/ - e-mail: [EMAIL PROTECTED]
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Encoded mailto links
This technique (as well as almost all others in this thread) is/has been cracked by virtually every spam harvester. Security by obfuscation is no security at all. Just put in straightforward mailto: links pointing to a designated email address. Then help your customers get a good spam filter program. No screen reader problems, no uninstalled javascript problems, etc. It just works. KISS. From: Dejan Kozina [EMAIL PROTECTED] Subject: Re: [WSG] Encoded mailto links With this, [EMAIL PROTECTED] becomes: a href=mailto:%6d%65%40%6d%65%2e%63%6f%6d; #x6d;#x65;#x40;#x6d;#x65;#x2e;#x63;#x6f;#x6d; /a It's not foolproof, but my customers are generally happy with the result. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
On 10/17/07, Rick Lecoat [EMAIL PROTECTED] wrote: Hi, can anyone tell me what is the best accessible way (if any) of encoding a mailto: link? I want to make the email addresses on a site usable to screen reader users, but don't want them harvested by spambots. Hi Rick, You might be interested in an experiment I ran that compared a few techniques for protecting one's email address from harvesting bots. The short answer: entity references worked very well and do not need Javascript to work. I am not an accessibility guru so I can't say how friendly that is to screen readers and the like, but I reckon you have plenty of people on this list who can inform you on that score. http://NikitaTheSpider.com/articles/IngenReklamTack.html Hope this helps -- Philip http://NikitaTheSpider.com/ Whole-site HTML validation, link checking and more *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Fix your spam issues at the mail server + mail client end, not at the web page end, would be my advice. not a solution ... we all know how hard it is for any filtering software to determine whether something is spam or not... ...and any machine-readable version of an email address on a page could unfortunately also potentially be read by harvesters. my approach is usually not to put the email address on there and instead provide a contact form, but even that has its problems nowdays as there are an increasing number of spambots out there that post to forms! (and I hate captchas!) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Encoded mailto links
Why not simply display the email address as a simple mailto only when the browser is a screen reader? If you mean by CSS (display: none -- or similar -- for aural media types), I'm not sure that would work because AFAIk spambots just look through the source code of the page for mailto links. The fact that the text is hidden when it gets to the browser is neither here nor there, surely? most spambots don't look at css or javascript If you are talking about actually hiding markup from certain agent types, I'd certainly like to know your method. Is there anything in agent strings (or any other header sent to the server) for any commonly used screenreaders? I'd love to know! *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
