[BBLISA] sender-specific addresses

[Tom Metro]

Edward Ned Harvey (bblisa4) wrote:
> I never give out the same address twice, and as soon as I receive any
> junk on any address, I simply discard that address.  You'll notice my
> current address on this list is bblisa4, implying three times I've
> started receiving junk addressed to whatever address I used on this
> list.

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.)

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.)

(A secondary bug that is also common is when an address gets embedded in
a URL, such as with an unsubscribe link, and the code generating the
email fails to URL encode the address, resulting in the "+" character
turning into a space. But if you spot this, its easy to work around by
manually inserting the escape code.)

I've emailed literally hundreds of sites with bug reports for these two
problems over the last decade.

Although both Sendmail, and later Postfix, support address extensions
and allow you to set any extension separator character, they both use
"+" by default, and major consumer email providers (Gmail) and hosting
companies stick with the default. (I emailed Gmail about this problem
multiple times while it was still in beta, but you have a better chance
of winning the lottery than to have Google listen to a suggestion from
an individual.)

It's really too bad Sendmail and Postfix didn't follow Qmail's lead of
using "-" for the separator, but back when this feature was introduced,
there was no web based form validation to be concerned with.


If you have your mail hosted with Google, there are a few workarounds,
but neither are convenient or scalable. You can create a new mailbox,
but there is a limit on how many you can create. Or you can create a
"nickname", which can be of the form "user-extension", but each user is
limited to 20 or 30 aliases of that sort. Both of these require logging
in to the Google admin UI and creating addresses. (And if you use
2-factor authentication, that is neither quick nor convenient.)

This limitation is one of the primary reasons I plan to eventually
migrate away from Gmail hosted email. (The other being that their IMAP
server has some strange quirks.)


> So in general, the world isn't ready for such a solution.  But in
> both theory, and in practice, it works extremely well.

If you could get a provider that will use a more universally accepted
extension separator character, and provide a bit of UI for managing your
extensions, it could be quite user friendly. The system could let you
create extensions on the fly, and then the UI could record in a database
any it has seen in use, and then provide options where you can
optionally fill in a description (so you remember what you created it
for), designate a folder to file those messages in, or specify that they
should be discarded.

Ideally they'd provide an API for managing the extensions as well, so
they can be managed by an app or mail client extension.


> I wrote an app for my phone, whereby I launch the app, and it will
> either randomly generate a new alias (proxy address) for me, or I can
> manually specify one. And the new address is active within approx 30
> seconds.

Nice.

 -Tom

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