Symphony.

comon problem ?

How to get an encoded email address either from markdown’s auto link or from Nick’s email obfuscator utility into the pagesource as the same encoded strings.

I have tried everything and always end up with an unencoded email or something encoded that is unreadible;

mailto:&#x006d&#x0061&#x0069&#x006c&

also with nicks utility, how do i get the param inside a href? as a variable? while keeping the encodings?

Huh?

I still don’t get the point of obfuscating emailadresses…

Either nobody can read them, not even your visitor. Or everyone can read them, even crawlers.

I am having the exact same problem. I love the idea behind Nick’s utility, but I can’t get it to work either.

This is my code:

<xsl:call-template name="obfuscate-email">
    <xsl:with-param name="email">info@mydomain.com</xsl:with-param>
</xsl:call-template>

However, this code spits out ASCII chars only. Illegible to any human reader.

I am quite new to Symphony, so I am probably missing something important.

@phoque: Obfuscating email addresses is a nice way to minimise the amount of spam coming through your website. It is also much more user-friendly than converting email addresses into images or using captchas.

Obfuscating email addresses is a nice way to minimise the amount of spam coming through your website.

Is there actually any proof for that argument? I just don’t find it very convincing… :-)

Just think about it for a moment. Every day gazillions of spam bots crawl the web searching for new email addresses to get hold of. Most of them aren’t built to pick up ascii characters though. This means that your chances of being indexed are far lower.

This doesn’t mean that obfuscating is a panacea. But not obfuscating your email is madness!

Obfuscating email addresses is a nice way to minimise the amount of spam coming through your website.

Is there actually any proof for that argument? I just don’t find it very convincing… :-)

There is. Unfortunately there are a number of problems with the data floating around out there:

1. Most of it is out of date. Since Obfuscation became popular spam bots have gotten a lot smarter. It used to be a few extra character or some JS was enough to break them but that’s no longer the case.
2. Like standard CAPTCHAs there’s a level of user-error that leads to missed e-mails for you. With CAPTCHAs that tends to be around 10–20% of users never manage to contact you.
3. As spam bots have gotten better so have spam blockers. I’ve started making a practice of putting a naked e-mail address on sites before and you want to know how much extra spam I’m receiving in my Google Apps inbox? None. Oh, I’m getting some (not much) in the spam folder but I’ve yet to see any of it pass through to my inbox.
4. I can’t speak for others but where I get the majority of my spam from these days is through my contact form which means every couple of days I have to delete a single e-mail.

To me, the major problem with all of these tactics is it takes your problem and offloads it onto your users. It’s basically you say, “I don’t want to deal with it so you’re going to have to try a little harder to contact me,” and I see no situation where that is a good idea.

The only time I condone these sorts of tactics is when spam becomes such a problem that it impacts the experience of your users. So spam on a forum or when you start getting bombed with spam and legitimate e-mails are lost as a result.

Most of them aren’t built to pick up ascii characters though. This means that your chances of being indexed are far lower.

Is this really the case? Sounds like another assumption to me…

I mean all it takes is the crawler to run a entity decoding function to break your obfuscation.

I don’t get this email obfuscation either. When I apply Nick’s utility I get what is essentially gibberish displayed in my browser. Can someone please explain how johndoe@gmail.com is supposed to be displayed in the page source and in the browser window?

Update: I got the above results from running the obfuscation utility outside Symphony. When I ran it inside Symphony I got better results: gibberish in the page source and plain readable text in the browser. But I don’t know the reason for the different results.

Sounds like another assumption to me…

But it’s definitely not. I created a few dozen websites in the last couple of years.

From my experience those with unprotected email addresses receive more spam and start to receive spam much sooner than those with some form of obfuscation, be it ASCII or javascript.

“In the land of the blind, the one eyed man is king”.

@Tintin81: Which might well be the case but it’s impossible to tell to what degree. If you could confirm that each site was shown for the exact same amount of time to the exact same spam bots and that the e-mail address was used for nothing else then you could make a firm conclusion.

However, clients don’t protect their e-mail addresses, every site is hit by different spam bots of varying frequency and intensity.

For example, some topics are more likely to get your site crawled by spam bots more often because they’re more popular. Such sites are more likely to get more spam.

As I’ve said already I don’t see the point is hiding my e-mail addresses when I can protect myself from spam in other ways that doesn’t impact the experience of my users.

If we’re going this route what I’d like to see instead is a way to implement the Text CAPTCHA project into Symphony, seeing as it has all the benefits of a standard CAPTCHA with almost none of the negatives..

…then you could make a firm conclusion.

Exactly my point! :-)

If we’re going this route what I’d like to see instead is a way to implement the Text CAPTCHA project into Symphony, seeing as it has all the benefits of a standard CAPTCHA with almost none of the negatives..

That should be easy! You need a Dynamic XML DS and a custom Event. Your page attaches the question, a input field for answering and one or more hidden input fields for allowed hashes to the form. In the trigger() method you’ll simply iterate over the md5 fields and compare them to md5(strtolower($answer)).

You say simple, sir, yet I bet I’ll have trouble. Still, I didn’t know XSLT could deal with MD5 hash fields so that should make it easier.

I’m just waiting for a client to ask me for a CAPTCHA and I want to be able to provide them with one that works well and is actually accessible.

I truly hate captcha’s aswell, so what I’ve tried is to add a hidden field

<input type="hidden" name="email" value="your@email.com" />

Then in the event I check if this hidden input has received a new value (spam!) and rejects it. (because the email value itself is never used in symphony, this does not change anything for symphony)

Fun thing is, users don’t have to type captcha’s, and I don’t get any spam.

@creativedutchmen, I don’t get how that works. Can you explain in more detail?

When spam bots fill out forms they will generally look for a field named “email” and will insert their own lolita@pr0n.ru address before sending. If you know the value has changed, it’s spam.

When spam bots fill out forms they will generally look for a field named “email” and will insert their own lolita@pr0n.ru address before sending. If you know the value has changed, it’s spam.

Indeed.

Ahhh, now I see (said the blind, noob developer!) That’s a classy idea. @creativedutchmen, does that seem to work all of the time? I too hate CAPTCHA, as I can never bloomin’ read the things and want a better solution…

does that seem to work all of the time?

I wouldn’t recommend if for really big sites (if you have enough users for the spam-bot-writers to adapt theirs bots to your site, this method isn’t going to make a difference).

For normal projects it works pretty good.