Cloaking Email Address

[Dave Anderson]

Re: Cloaking Email Address

Philip Ronan wrote:[color=blue]
> "Tim" wrote:
>[color=green]
>>Philip Ronan wrote:[/color]
>[color=green][color=darkred]
>>>(b) Spam makes you less productive, and the best way to avoid it is to
>>>be very careful with your email addresses.[/color]
>>
>>Doesn't work. They get it once, they've got it.[/color]
>
> So make sure they don't get it. :-p[/color]

Which is not possible. For example:

1) dictionary-style attacks

2) someone else posting your address in a harvestable form

3) posting your address in what you think is a non-harvestable form
which someone later starts harvesting

You can certainly make it less likely that they'll manage to harvest
your email address, but it's not entirely under your control. And when
they do get it, the only defense (short of spamming becoming an
actively-enforced capital offense worldwide) is good blocking.

Dave

[Guy Macon]

Re: Cloaking Email Address



Dave Anderson wrote:
[color=blue][color=green]
>> username_at_dom ain.com
>> username [at] another domain [dot] com
>> user-at-domain-dot-com[/color]
>
>The algorithm I posted a few minutes ago (before seeing this posting)
>handles all of those (and a lot more).[/color]

How about this one that I used in 2003?

guymacon+" http://www.guymacon.com/ "03@spamcop .net

Perfectly legal according to RFC-2822, and I got no reports of
anyone not being able to email me, but I used it in newsgroup
posts and on web pages for all of 2003, and not a single spammer
harvested my address.

[Philip Ronan]

Re: Cloaking Email Address

"Dave Anderson" wrote:
[color=blue]
> [Re: email addresses of the form "user at another example dot com"]
>
> I've got better things to do than spend time
> searching the net for a site where you couldn't be bothered to provide a
> URL.[/color]

You don't get it do you? According to you, a "trivial" algorithm should have
been able to extract this email address automatically. Instead, I have to
point you right at it before you can do anything about it.
[color=blue]
> Now that I've seen the page, I know that what you've done is corrupt the
> address in a way which you assume a person will figure out how to
> reverse (in this case, by inserting whitespace where it's not allowed).[/color]

Corrupted? Not allowed?? It wouldn't be legal in an RFC822 email address,
but that's not what we're discussing here. Anyone with a brain can figure
out what to do with this email address.
[color=blue]
> Based only on what I know now, what I'd do is:
> [SNIP: 3.3 KB of half-baked pseudo code][/color]

Let me just remind you what you said last week:
[color=blue][color=green]
>> Do you *really* believe that it's any harder to detect and process this
>> (and its obvious variants) than it is to process an entity-encoded email
>> address?[/color][/color]

Earlier on I showed you FIVE LINES of PHP that can extract an RFC822
formatted email address (with or without HTML entity encoding) from any web
page. Now to be fair, I should admit that an additional 3 lines are needed
to decode numerical entities, and the regular expression could probably be
improved.

But how many lines of code do you think your algorithm would run to? How
long would it take you to write and debug all of this? And what sort of hit
rate do you think you would achieve? Do you still honestly believe this is a
"trivial" matter?

Your algorithm would still fail at other "obvious alternatives" like
"mailATexampleD OTcom", or "m a i l @ e x a m p l e . c o m". How would you
work these into your algorithm? Do you honestly believe spammers are going
to tackle these addresses before they start decoding html entities? And
please bear in mind what I said about being 2 steps ahead. If the spammers
move on to entities, I'll move on to something else like Turing numbers.
[color=blue]
> Since the underlying question is whether spammers are willing to use
> harvesting techniques which produce lots of false positives, this is not
> relevant. We've *seen* spammers using dictionary attacks (which
> necessarily involve a very high fraction of false addresses), so we
> *know* that at least some spammers are willing to use such techniques.[/color]

My Oxford dictionary has 192000 words in it. Are you suggesting a spammer is
going to send me 192000 emails in the hope that just one will get through?
These attacks might produce results at domains like hotmail.com, but not on
my website. Any email to a non-existent mailbox goes straight into a black
hole.

I think it's about time you admitted defeat :-)

--
phil [dot] ronan @ virgin [dot] net

http://vzone.virgin.net/phil.ronan/

[Stan Brown]

Re: Cloaking Email Address

On Mon, 30 May 2005 23:52:56 +0000, Guy Macon
<_see.web.page_ @_www.guymacon. com_> wrote:
[color=blue]
>How about this one that I used in 2003?
>
>guymacon+" http://www.guymacon.com/ "03@spamcop .net
>
>Perfectly legal according to RFC-2822, and I got no reports of
>anyone not being able to email me, but I used it in newsgroup
>posts and on web pages for all of 2003, and not a single spammer
>harvested my address.[/color]

What made you stop using it, then?

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA

http://OakRoadSystems.com/

"I feel a wave of morning sickness coming on, and I want to
be standing on your mother's grave when it hits."

[Guy Macon]

Re: Cloaking Email Address




Stan Brown wrote:[color=blue]
>
>Guy Macon <http://www.guymacon.co m/> wrote:
>[color=green]
>>How about this one that I used in 2003?
>>
>>guymacon+" http://www.guymacon.com/ "03@spamcop .net
>>
>>Perfectly legal according to RFC-2822, and I got no reports of
>>anyone not being able to email me, but I used it in newsgroup
>>posts and on web pages for all of 2003, and not a single spammer
>>harvested my address.[/color]
>
>What made you stop using it, then?[/color]

I am running a series of long-term experiments using different
techniques. The disadvanges of the above email address is that
some humans falsely conclude that it isn't valid and thus don't
try to email me, and that some web forms falsely conclude that
it isn't valid and won't let me enter it.

[Dave Anderson]

Re: Cloaking Email Address

Guy Macon wrote:[color=blue]
> Dave Anderson wrote:
>[color=green][color=darkred]
>>>username_at_ domain.com
>>>username [at] another domain [dot] com
>>>user-at-domain-dot-com[/color]
>>
>>The algorithm I posted a few minutes ago (before seeing this posting)
>>handles all of those (and a lot more).[/color]
>
> How about this one that I used in 2003?
>
> guymacon+" http://www.guymacon.com/ "03@spamcop .net
>
> Perfectly legal according to RFC-2822, and I got no reports of
> anyone not being able to email me, but I used it in newsgroup
> posts and on web pages for all of 2003, and not a single spammer
> harvested my address.[/color]

I didn't think of that one, so it wouldn't be handled. OTOH, I did note
that some research needed to be done and that the username handling
could be improved.

Dave

[Bart Lateur]

Re: Cloaking Email Address

Guy Macon wrote:
[color=blue]
>Philip Ronan wrote:
>[color=green]
>>Those exist already. Some spambots are now built on an Internet Explorer
>>kernel, so whatever IE sees, the spambot sees.[/color]
>
>You have evidence of this?[/color]

I have, at least of the core technology:

<http://search.cpan.org/~abeltje/Win32-IE-Mechanize-0.008/>


This indeed does run Javascript before you get the page back, so
anything written using document.write( ) is in the result.

--
Bart.

[Dave Anderson]

Re: Cloaking Email Address

[Apologies for the delayed response; I've been a bit busy.]

Philip Ronan wrote:[color=blue]
> "Dave Anderson" wrote:
>[color=green]
>>[Re: email addresses of the form "user at another example dot com"]
>>
>>I've got better things to do than spend time
>>searching the net for a site where you couldn't be bothered to provide a
>>URL.[/color]
>
> You don't get it do you? According to you, a "trivial" algorithm should have
> been able to extract this email address automatically. Instead, I have to
> point you right at it before you can do anything about it.[/color]

If you can't tell the difference between the tasks of finding something
within a particular page and of finding a page which contains some
particular bit of information, you've got a serious problem with
rational thought.
[color=blue][color=green]
>>Now that I've seen the page, I know that what you've done is corrupt the
>>address in a way which you assume a person will figure out how to
>>reverse (in this case, by inserting whitespace where it's not allowed).[/color]
>
> Corrupted? Not allowed?? It wouldn't be legal in an RFC822 email address,
> but that's not what we're discussing here. Anyone with a brain can figure
> out what to do with this email address.[/color]

Play word games all you want, but don't think it isn't obvious that
you're trying to obscure the real issues.
[color=blue][color=green]
>>Based only on what I know now, what I'd do is:[/color]
>[SNIP: 3.3 KB of half-baked pseudo code][/color]

That "half-baked" code clearly demonstrated the practicality of doing of
what you claimed couldn't be done.
[color=blue]
> Let me just remind you what you said last week:
>[color=green][color=darkred]
>>>Do you *really* believe that it's any harder to detect and process this
>>>(and its obvious variants) than it is to process an entity-encoded email
>>>address?[/color][/color][/color]

I'll admit that I should have said "significan tly" rather than "any",
but that doesn't make any great difference to the real issue -- which is
whether such processing is practical.
[color=blue]
> Earlier on I showed you FIVE LINES of PHP that can extract an RFC822
> formatted email address (with or without HTML entity encoding) from any web
> page. Now to be fair, I should admit that an additional 3 lines are needed
> to decode numerical entities, and the regular expression could probably be
> improved.
>
> But how many lines of code do you think your algorithm would run to? How
> long would it take you to write and debug all of this? And what sort of hit
> rate do you think you would achieve? Do you still honestly believe this is a
> "trivial" matter?[/color]

Whoopti-doo! Processing one form takes less code than processing the
other. Since I've demonstrated that neither takes an *impractical*
amount of code, this difference has negligible bearing on which
processing spammer tools will implement.
[color=blue]
> Your algorithm would still fail at other "obvious alternatives" like
> "mailATexampleD OTcom", or "m a i l @ e x a m p l e . c o m". How would you
> work these into your algorithm? Do you honestly believe spammers are going
> to tackle these addresses before they start decoding html entities? And
> please bear in mind what I said about being 2 steps ahead. If the spammers
> move on to entities, I'll move on to something else like Turing numbers.[/color]

Given that your old encodings are captured in various archives, you
can't "move on" (unless you're willing to abandon all of your old
addresses).
[color=blue][color=green]
>>Since the underlying question is whether spammers are willing to use
>>harvesting techniques which produce lots of false positives, this is not
>>relevant. We've *seen* spammers using dictionary attacks (which
>>necessarily involve a very high fraction of false addresses), so we
>>*know* that at least some spammers are willing to use such techniques.[/color]
>
> My Oxford dictionary has 192000 words in it. Are you suggesting a spammer is
> going to send me 192000 emails in the hope that just one will get through?
> These attacks might produce results at domains like hotmail.com, but not on
> my website. Any email to a non-existent mailbox goes straight into a black
> hole.[/color]

I detect a true master of the non sequitur.
[color=blue]
> I think it's about time you admitted defeat :-)[/color]

Should I admit that I'll never change your mind? Sure -- you've made it
abundantly clear that you're unwilling to listen to anything that
contradicts your ideas. I'm done with this thread.

Should I admit that I'm wrong? Certainly not. You haven't produced any
successful counter-arguments to any of my major points.

Dave

[Guy Macon]

Re: Cloaking Email Address




Here is (one) right way to handle email addresses.

Get an email account with spamcop.net [ http://spamcop.net ].
This alone scares off many email spammers; they often purge
all spamcop addresses in order to stay of the Spamcop blocklist
a bit longer.

"Cloak" your email address like this:

When dealing with Spishak corp, give your email address as
nobody+spishak@ spamcop.net.

When putting your email address on your webpage, use something
like nobody+wp1234@s pamcop.net.

When emailing Bill Gates, use nobody+billg@sp amcop.net

As soon as you start getting a few spams at any of these addresses,
report the spams to Spamcop, which will filter out all email from
that source, not only for you but for all users of the spamcop
blocklist. If they hit someone else who reports to spamcop first,
you will never see that first one.

If you start getting a lot of spam to an address, block it and
select a new one. What I do is to start using the new address,
then a month later I whitelist anyone who has ever emailed me at
the old address and block the rest.

(Spamcop has the feature of being able to retrieve email from
multiple accounts with other ISPs, filtering them, and forwarding
them to any email address you choose, so you can even keep all
your old accounts alive)

No obfuscating, munging, or tricks with character entities or
JavaScript needed.

-------------------------------

About "Plussed" email addresses:

RFC 2822 (which replaces section 6 of RFC 822) says that "+" is legal
when used on the left side of the "@" character in email addresses.
See sections 3.4.1 and 3.2.5 at http://www.ietf.org/rfc/rfc2822.txt or
http://www.faqs.org/rfcs/rfc2822.html for details.

Newer versions of Sendmail accept such "plussed" email addresses,
discarding everything from the "+" to just before the "@". This
can help you to track who sells your email address and in spam
filtering. Many ISPs allow you to have a plussed email address;
try sending one to your present email address and see. Virtually
all ISPs allow you to send plussed email addresses.

[Nisse Engström]

Re: Cloaking Email Address

On Mon, 30 May 2005 23:52:56 +0000,
Guy Macon<_see.web. page_@_www.guym acon.com_> wrote:[color=blue]
>
> guymacon+" http://www.guymacon.com/ "03@spamcop .net
>
> Perfectly legal according to RFC-2822, and I got no reports of
> anyone not being able to email me, but I used it in newsgroup
> posts and on web pages for all of 2003, and not a single spammer
> harvested my address.[/color]

According to RFC-2822, the "local-part" is either a
"dot-atom", "quoted-string" or an "obs-local-part".
What you have before the "@" is neither of those.

Am I missing something?


--n

[Guy Macon]

Re: Cloaking Email Address


Content-Transfer-Encoding: 8Bit

Nisse Engström wrote:[color=blue]
>
>
>On Mon, 30 May 2005 23:52:56 +0000,
>Guy Macon<_see.web. page_@_www.guym acon.com_> wrote:[color=green]
>>
>> guymacon+" http://www.guymacon.com/ "03@spamcop .net
>>
>> Perfectly legal according to RFC-2822, and I got no reports of
>> anyone not being able to email me, but I used it in newsgroup
>> posts and on web pages for all of 2003, and not a single spammer
>> harvested my address.[/color]
>
>According to RFC-2822, the "local-part" is either a
>"dot-atom", "quoted-string" or an "obs-local-part".
>What you have before the "@" is neither of those.
>
>Am I missing something?[/color]

Nope. I made an error. I cut and pasted the above from my
"legal under RFC 822" example in my text file. For RFC-2822
I would have had to put quotes around the entire local part
or used string+string@. .. as my example. Sorry about that.

I just put a warning in all caps into the text file I cut
and pasted that from so that I won't make that mistake again.
I apologize for the error.

[Nisse Engström]

Re: Cloaking Email Address

On Sun, 12 Jun 2005 13:13:40 +0000,
Guy Macon<_see.web. page_@_www.guym acon.com_> wrote:[color=blue]
>
> Nisse Engström wrote:[color=green]
> >
> >On Mon, 30 May 2005 23:52:56 +0000,
> >Guy Macon<_see.web. page_@_www.guym acon.com_> wrote:[color=darkred]
> >>
> >> guymacon+" http://www.guymacon.com/ "03@spamcop .net[/color]
> >
> >According to RFC-2822, the "local-part" is either a
> >"dot-atom", "quoted-string" or an "obs-local-part".
> >What you have before the "@" is neither of those.
> >
> >Am I missing something?[/color]
>
> Nope. I made an error. I cut and pasted the above from my
> "legal under RFC 822" example in my text file. For RFC-2822
> I would have had to put quotes around the entire local part
> or used string+string@. .. as my example. Sorry about that.[/color]

[Sorry about the late reply (again), but I didn't look
into this until I read RFC 822 for some other reason.]

I still don't see how that address is valid.

The RFC 822 rules are:

addr-spec = local-part "@" domain
local-part = word *("." word)
word = atom / quoted-string
atom = 1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">


1. There is only one <word> because there is no "." to the
left of the "@".
2. The <word> is not an <atom>, because <atom> does not
contain <SPACE>.
3. The <word> is not a <quoted-string>, because it does
not begin and end with double quotes.


The following would be valid RFC 822 addresses (I think):

"guymacon+\ " http://www.guymacon.com/ \"03"@spamcop.n et
guymacon." http://www.guymacon.com/ ".03@spamcop.ne t


--n

[Guy Macon]

Re: Cloaking Email Address


Content-Transfer-Encoding: 8Bit


Nisse Engström wrote:[color=blue]
>
>Guy Macon<_see.web. page_@_www.guym acon.com_> wrote:
>[color=green]
>> guymacon+" http://www.guymacon.com/ "03@spamcop .net
>> [is] legal under RFC 822.[/color]
>
>I still don't see how that address is valid.
>
>The RFC 822 rules are:
>
> addr-spec = local-part "@" domain
> local-part = word *("." word)
> word = atom / quoted-string
> atom = 1*<any CHAR except specials, SPACE and CTLs>
> quoted-string = <"> *(qtext/quoted-pair) <">
>
>1. There is only one <word> because there is no "." to the
> left of the "@".
>2. The <word> is not an <atom>, because <atom> does not
> contain <SPACE>.
>3. The <word> is not a <quoted-string>, because it does
> not begin and end with double quotes.
>
>
>The following would be valid RFC 822 addresses (I think):
>
> "guymacon+\ " http://www.guymacon.com/ \"03"@spamcop.n et
> guymacon." http://www.guymacon.com/ ".03@spamcop.ne t[/color]

Russ Allbery made this comment a while back:

| macon+."http://www.guymacon.co m/ "@example.c om is legal under RFC 822, but
| not under RFC 2822. Under RFC 2822, you have to do something like
| "macon+http://www.guymacon.com/ "@example.c om (in other words, quoting the
| whole string).
|
| Quoted LHS parts in e-mail addresses have an iffy reputation with MUAs; a
| lot of software authors don't bother getting this right.
|
| Russ Allbery (rra@stanford.e du) <http://www.eyrie.org/~eagle/>

....and I just rechecked the RFCs. It looks like I was in error
*again*! It's not legal without the "." :(

Note to self: next time, smoke crack *after* posting to Usenet...