Hacker News Reader

Comment by nmjohn | Hacker News Reader

> services should allow me to easily create lots of aliases. Right now the best defense against social engineering seems to be my fastmail account which allows me to create 1 email address alias per service

What you may want is a catch-all email - which lets you do @domain.com -> nmjohn@domain.com (where is everything besides already defined addresses) - that way you can make up emails on the fly without having to setup the alias beforehand.

I've had that setup for 5 or 6 years now, and it works extremely well. A handy side-effect of this is it makes it easy to see which companies sell your email address to spammers when you included the name of the original company in the email you register with

View on HN

I've done this and once had a phone rep from Geico who was convinced I worked for them because my email was something like geico@example.com. This was probably in the late 90s when email was still new to many people. She was really confused that I wasn't getting the employee discount. "Are you sure? Does a family member work for Geico? No? Are you sure?..." I don't think she ever did really understand what was going on.

Perhaps I could have saved even more than 15% if I'd just gone with it. :D

Fastmail and Gmail support a local suffix of the form yourname+amazon@gmail.com. That's a plus character between the local name and local suffix. If you use a password manager, you can replace a predictable suffix like "amazon" with random hex value.

Unfortunately, many sites borked their e-mail address validation and do not accept the plus character. (Amazon permits it.) Also, you'll ocassionally find a customer service ticketing system that expects replies to come "From" your account's e-mail address. (Many mail clients can alter that header, but it's a pain.)

I fear that customer support might still accept emails without the suffix from the "customer". These are people, not robots, so if the address is close or in the vicinity of being correct, they might accept it. Same goes for the dot characters allowed in gmail addresses.

I strongly second this concern. I generate random strings as answers to my recovery questions. When I recently got asked one of the questions the support rep let out a sigh when asking (presumably because he saw the "crazy" answer) and then said "yeah yeah, alright" when I was about half way through the answer. That any company even suggests these insane security questions that anyone can trivially research is completely beyond me.

An idea I just had which is buried in a deep thread lower down...

Not that I trust the "security questions", but if Amazon lets you use freeform questions as well as answers, it might help to make your first security question "Have you noticed this account has two factor authentication turned on?" with an answer like "Yes, so Amazon Customer Service will take additional care when being asked to reveal account information, right?"

Even if you can't do freeform questions, perhaps the answer to "What's your mother's maiden name?" could be something like "Have you noticed this account has two factor authentication turned on? Please take extra care before disclosing account details to anyone, Thanks."

For those sort of "mother's maiden name" type questions, I generally use a fake but plausible name. Probably not as secure as a random string (especially as the name is reused across a few services), but makes it near impossible to research, and avoids a random string not being accepted/treated as an error/truncated like your example etc.

I would recommend strongly against that. You'd be far better off picking something plausible, so if someone does impersonate you it's obvious.

Remember it's a human verifying this. The attacker just needs to answer: "oh, yeah i just spammed the keyboard with some jibberish" and he's in.

The other thing I noticed by the attacker going after me, sometimes he'd call/contact the service multiple times in a row. All he needs to do is find out from 1 support rep that the reset password is randomly generated. Then tell another support rep that its "some jibberish" and he's in.

> I generate random strings as answers to my recovery questions.

What's your favourite football team? -> Genghis Khan 2nd XI What was your first school called? -> Little Horrors School for Hackers

etc. Easier to say, you won't lose the customer service rep's attention either :)

Panix.com supports this, plus an alternate that works almost everywhere. You can use "whatever@yourname.users.panix.com", and it ends up in your inbox, filterable by the "To:" address. I create a new email address for every company I sign up with.

(Satisfied Panix customer.)

Fastmail also supports something similar, with whatever@yourname.fastmail.com mapping to yourname+whatever@fastmail.com

Gmail also supports you.r.nam.e@gmail.com (add random dots to the local-part). (Almost?) every system considers '.' a valid character. However, you need to keep track of which tagged address goes to what service, much like the case of a tag with random hex digits.

Also a lot of systems strip anything after the + now, especially spam systems.

Fastmail supports a@fastmail.com -> anything@a.fastmail.com, which is even better

I've even started seeing registration systems that tell me that I've entered an invalid address if I do the [email]+[something]@gmail.com trick.

Twice now I was only able to register after removing the +[something] part of the email.

Is + actually an invalid email character (according to RFCs etc?). I couldn't find any reference to that when I looked.

I'll try to avoid ranting here, but anything is a legal email address per the RFC (even an @ sign in a username, or an email address without any @ sign).

RFC 821 is the original and 2821 summarizes it plus the few that came after to add and clarify.

The only true "RFC email validity check" is to send an email to whatever address they provide.

Gmail also allows yourname.amazon@gmail.com

No they don't, since I could register that. Maybe your confusing the period with a plus?

EDIT: I am stupid, disregard thread

That's radically different to what you presented in your previous example.

oh, yes it is isn't it. I was not SMRT

It ceartainly does not allow yourname.amazon@gmail.com if you don't own yournameamazon@gmail.com. You can do suffix with + and random . but not suffix with .

Note, though, that catch-all emails will also catch a ridiculous amount of spam. Creating each account name individually avoids that problem, at the cost of some extra trouble when registering a new service.

An intermediate step that may work if you don't expect people to target you individually: have one or more required substrings for the email local part, and catch all mail to addresses containing that substring.

I created my catch-all on a subdomain. While it gives a problem with certain websites (don't consider it a valid e-mail address), I barely receive spam on it.

> While it gives a problem with certain websites (don't consider it a valid e-mail address)

Are you saying that there are sites out there which don't accept mailbox@subdomain.example.com a valid email address? If so, that's beyond broken...

My school's student addresses ended in @u.northwestern.edu. You can imagine this was annoying sometimes when email addresses ending in .edu were used to verify student status.

>My school's student addresses ended in @u.northwestern.edu. You can imagine this was annoying sometimes when email addresses ending in .edu were used to verify student status.

Sorry, could you repeat that? yourname@u.northwestern.edu certainly matches \.edu$.

Unless you're worried about the false-positive for a non-student with a different subdomain?

It doesnt match \w\.edu$

And you can imagine how maddening it is when 90% of students worldwide don't have a .edu, but some do.

Only one university in Germany has a .edu, and their students obviously manage to get far more benefits than those of us with an @informatik.uni-kiel.de email.

99% of times we need to send proof that we are students, what is interesting is that many companies accept that even if it's not in English. Probably on good faith.

In Brazil, universities can use .edu.br, but we have few universities providing email addresses to students and also, the majority of grad schools in Brazil are not universities but a small college called 'University Center'

I receive all mails @ my domain and I get about 1 spam a day. Fastmail's spam filters are pretty good.

Do you have a good idea of the rate of false positives?

No, I don't check my spam folder. Never had any reason to do so in the last couple of years.

One method that I've seen used (heard it described by a guest one of Leo Laporte's podcasts a looooong time ago) is to iterate account names by year. For example, this year the email address would be pyre2016@example.com, and next year it will be pyre2017@example.com. Not sure how well it works, but the idea is that by that every year you start over with a fresh address (that takes a while to get onto spam lists).

I'll note that I don't use this method as it seems too high maintenance and the effectiveness is unclear.

Not a big deal if using a password manager and email acts as username.

Using it as your mail email for personal/business purposes could run you into trouble though. Most people aren't used to a rotating email address.

I believe the real issue here is its not uncommon for spam services to try to locate valid email addresses. Generally, an email server won't accept email to an invalid users and will probably start flagging the incoming server/domain as those attempts start to cross a threshold of some sort. OP is talking about *@example.com as a catchall which means a spammers script will sit there and email a dictionary of usernames against your domain until it crosses it's own threshold. It's not too hard to add an alias for each name as you go along but it really depends whose list your domain gets on.

I was talking about making those actual accounts vs. aliases to the catchall address. That method makes no sense if each pyre<year>@example.com email address was just an alias to the catchall because pyre<previous_year>@example.com would still be caught by the catch-all, even if you disabled the alias.

> Note, though, that catch-all emails will also catch a ridiculous amount of spam.

I haven't found this to be true, or at least Google's spam filters have gotten sufficiently good to prevent it.

I have a catch-all address @morgante.net and rarely ever see spam—maybe once a week.

> Note, though, that catch-all emails will also catch a ridiculous amount of spam

Hasn't been a problem for me.

Make sure you keep a list somewhere of which site got which email address.

I used to do this too and it was great, but then when I started trying to recover accounts that were a few years old, I had a heck of a time remembering what email address I had actually given them in the first place!

I just do compapyname@mydomain.com. That's how I knew Broderbund sold my email address.

I was doing that but some companies think you are "hacking" if you put the company name in. Like I don't think you can do facebook@mydomain.com on Facebook.

fb@mydomain.com is perfectly usable though.

So I think that was grand-OPs point to a degree. If you can't always do companyname@mydomain.com there is a change you will forget what you used: Example:

aws vs amazon-web-services vs amazon.web.services

facebook vs fb vs fbook

Or for example I've used Rally the project management tool but my health insurance uses a (terrible) "rewards" program called "werally" but it's ALWAYS referred to "rally". It can get unmanageable.

Now I use 1Password to track all of this stuff which works well so I think there are solution but I do understand the grand-OPs point.

I would tell you that my FB email address has that format, but maybe I'd be leaking too much information by doing so....

They must have changed that at some point, since I do exactly this and have no issues. I set up my FB account 6 or 7 years ago though.

You can approximate this with gmail using the plus sign. Like myaccount+label@gmail.com.

It's ignored for delivery, but gmail's filters can match on it in the to: address.

Every time I've tried to use that feature, the email field in the registration form I'm trying to fill out rejects it because they don't like + in an email address. There are a lot of not-quite-correct email form validation routines out there. Or maybe this is selection bias: the forms where I'm most likely to want to use the + are with the companies that are most likely to want to resell my email address, and they may be intentionally rejecting the +.

Lots of programmers try to write regular expressions to validate e-mail addresses, but it's extremely difficult for them to get it right, because valid e-mail addresses as defined by RFCs 822 and 5322 fall outside the set of formal languages describable by most regular expression libraries. See this fun stackoverflow answer [0].

[0] http://stackoverflow.com/a/201378

but then the spammers use BCC and you don't know what email they used?

There's Envelope-to, which is the only thing you should at. To, From etc. could be forged.

Reply on news.ycombinator.com