Talk:Address munging

[Untitled][edit]

Since there's ongoing editing I won't change the page myself to avoid conflicts,

No, go ahead. I'm finished for a while. Motor 16:28, 20 Mar 2004 (UTC)

but it should be noted that the TLDs example.com and example.org are reserved for use in examples such as the address used in this article. Consider changing to one of these domains (I prefer person@example.org - it shows we're talking about a hypothetical personal address, uses a reserved TLD, and counters the ingrained assumption that most/all domains are .com)

Also, what RFCs are violated by address munging? This needs elaboration. I assume this refers to email headers (From: and Reply-to:), but the rest of the article doesn't specify that the disguise is in the headers. --rparle 16:24, Mar 20, 2004 (UTC)

[looking up the RFCs] I agree, I was hoping to get around it. And you're right about the lack of From: and Reply-to: feel free to add it. Motor 16:28, 20 Mar 2004 (UTC)

Plain text vs. tags[edit]

There's something I've been wondering about for some time, and since I can't find the answer in the article I'll ask here. Do spambots only look for addresses in what is printed on the webpage, or does it also look at the code itself? ie. would it be possible do to something like this: <A HREF="mailto: person@example.com">person(at)example(.)com</A>, or would the mailto bit have to be mungled as well? Desdenova 15:25, 12 September 2006 (UTC)[reply]

In my experience, email scanners do not parse HTML and simply look or obvious boundaries (spaces, colons, HTML tags) around an email address. They will pick up email addresses in HTML comment blocks and/or URLs. Email comments "(comment)" defined in RFC5322 can be placed anywhere and are treated by most browsers and/or mail clients as to be striped completely before use. Some clients will re-use them as comments _after_ the email address, but that is outside the scope of the objective. <A HREF="mailto:per(removethis)son@exam(removethis)ple.com">person(at)example(.)com</A> will normally be parsed correctly and completely transparent to the user. An example of how some mail clients may present this is "To: person@example.com (removethis)" DennyEugeneWatson (talk) 19:21, 10 March 2020 (UTC)[reply]

HTML codes[edit]

There are HTML codes for substitute the @ and . (dot) symbol with HTML code, this might prevent bots from finding it, while still being fully readable as an usual address to a human.

—

No, this is a misunderstanding of the idea, and is no better at preventing harvesting than the simplest forms of address munging.

What the citation on the main page suggests is randomly substituting characters with their corresponding entities. In other words, do not simply substitute the @ and the . but rather pick random characters from the address (potentially including the @ and .) and substitute them instead.

Nevertheless all good things must come to an end, because if this becomes popular harvesters will be programmed to look for it — an email address munged as such won't look like a valid email address to the eye *before* rendering the page, but I can't imagine it taking a lot of code to simply substitute all entities with their corresponding characters.

BrianRecchia (talk) 04:29, 18 April 2018 (UTC)[reply]

Brackets[edit]

People also use brackets to surround the dot and at such as bob[at]example[dot]como or {dot} etc or various things that their fantasy allows. :p

Javascript[edit]

It might be worth mentioning the use of javascript to display email addresses and usable mailto: links. The hope is that spambots won't be clever enough to parse the javascript. I can't attest to the effectiveness of this technique, hopefully someone else can chime in with an opinion. An implementation of this technique is available under the section "JavaScript to obscure email addresses."

I don't understand how this works. Why don't bots just run the JavaScript? Seems pretty easy to defeat. I suppose it would take some lead time between this technique coming into common use and spammers adding the functionality to their bots. Just like adding OCR to defeat imaged emails. --Daev 15:30, 26 March 2006 (UTC)[reply]
- I think it'd be really stupid on their part. If user is clever enough to obfuscate the email --Molten tar 23:46, 10 July 2006 (UTC)[reply]

Truth is they can run the javascript, and it is easy to defeat. The proof is that search engines do. And for the obvious reasons, there is probably little to no data on how many spam bots search for javascript-hidden email links. However, two argument I like to make as to why spam bots may not want to run the javascript are the following. First, if you're smart enough to hide your email address with JAVASCRIPT, you're probably smart enough to recognize spam when you see it. Second most people DON'T use javascript to hide their email addresses. Considering the vast amount of javascript that there is out there, running javascript would probably be a huge and unproductive time killer. Dominicanpapi82 06:05, 22 April 2006 (UTC)[reply]

Plussed Addressing[edit]

I got my information from several places, but this was the most explicit. I'm not sure it's in the right place though. There is a section on email address that talks about it (linked in this article), but it's pretty bare (so I added a bit). I think I will fill in some information there, but perhaps we could have a new article? One on spam prevention techniques. --Daev 15:21, 26 March 2006 (UTC)[reply]

At, dot and foreign languages[edit]

There's something I'd like to add to the article regarding the problems of address disguising, but I'd rather wait for others' opinions, it could be considered original research or whatever although I consider this commonplace enough to mention without sources: In my experience, for people that can read/write English but aren't native English speakers, dot and specially at aren't immediately obvious as being . and @, people reads addresses in their language (e.g. in my native languages: in spanish <user arroba server punto tld> or in catalan <user arrova server punt tld>) (and @ is something not usually learned when learning English...). Comments? --Outlyer 15:40, 2 May 2007 (UTC)[reply]

Outdated research?[edit]

Quote from the article; According to a 2003 study by the Center for Democracy and Technology, even the simplest "transparent name mangling" of e-mail addresses can be effective. How relevant is this in 2013? A lot has changed in spam harvesters in 10 years I imagine. How smart are those bots nowadays? 84.105.172.5 (talk) 19:39, 6 May 2013 (UTC)[reply]

Proposing addition of an External Link[edit]

As suggested by Versageek, I am proposing here that the following be added as an external link to the page:

Free address munging mailto html encoder

It is directly related to this page and provides a free service. --Oguz0909 19:20, 27 May 2015 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 3 external links on Address munging. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 04:27, 4 October 2016 (UTC)[reply]