[Discuss] box.net

[Tom Metro]

Edward Ned Harvey wrote:
> You may already know, I use disposable email addresses.

Likewise. Mostly of the address extension variety, as mentioned
elsewhere in this thread.

It's particularly handy for weeding out phish emails if you know all
legitimate messages from your bank will be sent to me+mybank. (For
banking sites, I've taken to throwing in some cryptographic characters
to make guessing the address improbable.)


> Two weeks ago, I signed up for box.net (also now box.com) using
> boxnet at nedharvey.com.  I haven't given that email address out to anybody
> else, and I started receiving enlargement email on that address today.

The bank situation you mentioned was scary. A few months back I had this
happen with an address I gave to Equifax - you know, one of the three
major credit reporting agencies that has everyone's credit records? That
was disturbing. I can only hope that it was some secondary server or
outsourced email marketing vendor that got compromised.

Equifax has never disclosed the breach, if they are even aware of it.
(Contacting large organizations is pointless. They design their customer
service organizations to firewall the tech people from any useful
customer feedback. I did, however, tweet about it.)


Theodore Ruegsegger wrote:
> But how is this address disposable? ...how do I "dispose" of the
> address? Do you mean I add a line in my filters to reject any mail
> with that address?

In the case of Gmail, I don't think I've manually written a filter yet.
I use Gmail via IMAP and I simply move such messages, if Gmail hasn't
already flag them as spam, to the spam folder, and that seems to help
tune Google's statistical filters.


> ...won't spammers simply add a script truncate any gmail address with
> a + in it, yielding a valid and no-longer-traceable address? Or can
> we count on them to be really, really lazy?

So far they seem to be lazy. I've yet to spot any evidence of extensions
being stripped.


Edward Ned Harvey wrote:
> That's actually an RFC standard that's supported by many MTA's.  

I'm not aware of the address extension mechanism being codified in any
RFC. (Reference?) Of course the "+" character is permitted by RFCs, but
it isn't imbued with special meaning.

My understanding is that it is a defacto standard pioneered by Sendmail.


> The only problem is... As mentioned, lots of companies / websites /
> whatever reject your email address if there's a + character in it...

This is a major annoyance with this technique. I'd estimate something
like 80% of the web forms I encounter will incorrectly reject addresses
containing "+".

The sad part is that major providers, like Gmail, could easily have
avoided this by using a universally accepted character, like "-". (I was
part of the Gmail beta and complained frequently about this. Of course
it fell on deaf ears, and now with millions of Gmail accounts, it is
impossible to change.)


> ...because some other RFC standard defines the + character
> as a bad character for email addresses.

Again, I've never heard of that.

My best guess is that there are a handful of popular email address
validation libraries that all share this bug. (Perhaps some stock PHP
library? I know the Perl libraries don't have this bug.) That, and every
other web developer thinks they can easily whip up an email validation
regular expression from scratch in a matter of minutes.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/