[BBLISA] sender-specific addresses

[Tom Metro]

Steven M Jones wrote:
>Tom Metro wrote:
>> I used sender-specific addresses back in the 1990s, but migrated to the
>> equivalent using address extensions in the 2000s. It works great, as you
>> describe, and is a great way to spot when a vendor has had a breach and
>> their customer database downloaded by hackers/spammers. (Also makes it
>> trivial to spot phish emails, that get directed at publicly exposed
>> address, and not the vendor-specific ones.)
> 
> I've done this as well, but in my opinion the most common cause of such 
> "leakage" is that the site/vendor has "monetized" your information by 
> selling profiles and addresses to third parties...

True. You see that a lot with magazine publishers - particularly trade
magazines.

Either way, it immediately highlights the origin of your information
disclosure (be it bad security or shady business practices), and can be
helpful in deciding whether you want to do business with that vendor in
the future.


>> The big problem with the user+extension at example.com format is that it
>> appears some newb who didn't understand RFCs wrote an email validation
>> library in the early 2000s which incorrectly believes the "+" character
>> is invalid, and about 50% of web sites use it or a derivative. (I'm
>> guessing a PHP library.)
> 
> Hallelujah! I've filed dozens of complaints with different websites and 
> vendors on this very point.

Great to see someone else fighting the good fight. :-)


> So far as I'm aware none of corrected the situation;

I've had a few successes. Generally it happens at small startups that
are immature enough that their support department hasn't yet evolved
into being a "keep all useful feedback away from the engineers" department.

The thing is in most cases I wouldn't even be aware if they fixed the
problem. If the site provided frivolous functionality, I just don't
bother using it. If there are alternatives, I'll use them instead. If it
is important, then I go through the hassle to create a custom alias with
"-" instead of "+".

Some notable big companies that handle "+" in a way you wouldn't expect:

Facebook use to reject "+", but as of around 2012 they accept it.

Google will handle "+" in many places, but not everywhere. Sign up for
Google Groups and I believe it won't. I know from recent experience that
you can't use a "+" address as your login for a Google Apps account, yet
you can for Google Voice. They aren't consistent. You'd think running a
massive mail operation designed to support "+" address would make them
more aware of this requirement.


> ...worse, many companies who are happily sending me email via 
> "+" detail addresses, have changed their websites or validation routines 
> subsequently and reject such addresses.

I don't think I've yet ran into that.


> I have one domain that will rewrite vast categories of addresses to
> my actual address in another domain, so that I can use almost
> anything on the fly when I'm interacting with an application or
> website.

Many services, including Google Apps, will let you use a "catch all"
address, but they are generally discouraged.


> (So far there's been no problem with spam to random addresses being
> accepted.)

I gather you've been lucky enough to avoid being hit by a dictionary attack.

At the domain I've owned since the early 90's I get vast amounts of
messages directed at non-existent users.


> This reminds me of another problem -- websites that require you to use 
> your email address to login, but reject a "+" during validation prior to 
> looking anything up. This caused me to abandon my 8 year old Ofoto/Kodak 
> Gallery account when it was purchased by Shutterfly...

(I can't say I've experienced that specifically.)

Sometimes you can get around this sort of stupidity by disabling
JavaScript in the browser. It's not unusual for web developers to use
substantially different validation rules on the browser side from what
they use on the back-end.

But disabling JS isn't the quick fix it once was, because these days it
is common that the form submit button will be coded such that it fully
relies on JS and has no fallback behavior to old-style form processing.
In which case you need to do more invasive JS hacks using tools like
Greasemonkey, which rarely are worth the effort.

 -Tom

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