Tell HN: GitHub now blocks aliased email addresses
"Our spam detecting systems flagged your account because of the email address you used to register the account. Temporary/aliased email addresses are not permitted for use on GitHub accounts."
"Before we can remove the flag we need you to add a personal, non-disposable email address and then verify that address. You also need to remove the temporary/aliased email from the account."
Bad news for SimpleLogin and AnonAddy users.
47 comments
[ 2.5 ms ] story [ 91.3 ms ] threadgithub@lastname.com, reddit@lastname.com, randomstore@lastname.com all direct to firstname@lastname.com.
I rarely get spam these days, but when I do, I simply block the address and move on.
random1@lastname.com
random2@lastname.com
random3@lastname.com
Do you have a whitelist as well?
nobody is sending email to alsdkjfadf@domain
That’s actually the kind of spam I used to receive on a very short domain with a catch-all.
I guess they loop through short domain names and then try to brute-force the local part.
One of our users used a throwaway a@apple.com, which earned us a complaint inside of an hour, just by sending a welcome/confirm message.
Actually, I did receive one, from my friend who typed the entire message in the name before the @ and left the body and subject empty :D
So something like this?
You've made my evening!
You don't, but spammers don't care that much to do what you describe.
Think like a spammer. Why would a spammer motivated by profit to do that on a small personal domain? It makes sense on large service (e.g. gmail, yahoo, comcast), because they might increase their audience, but on a personal domain they're just going to swamp someone's inbox in a way that makes it even less likely they'd bite.
However it does happen a little. Because it sounded like fun I actually added a signature to my addresses. So it looks like github.com-abcdef@example. Then the spam filter will check the signature and if it is invalid it will give it a high spam weight. (Other than a few widely-published addresses that are accepted at neutral weight)
* If a server tries to send an email to a user that doesn't exist on another server, the email will "bounce", and the receiver will automatically respond with an error (we've all seen this).
* If a server slowly spams another server with emails to invalid users (say once an hour) they'll just get bounced back each time. No harm done.
* If a server spams another server with an onslaught of emails, even if they are to a valid user, at some point it becomes a DOS attack and the IP of that server will be blacklisted.
So the case you're probably concerned about is the second one where they could essentially brute force a username slowly enough that they don't trigger any red flags. But the time investment, compute power, and bandwidth necessary to do that is not worth how easy it would be to mitigate that. "Great you figured out my email address. Blocked."
If they're going to spend time shooting into the dark like that they might as well be guessing random passwords to public facing ssh servers (which bots are doing all the time).
What I do get are a lot of misdirected messages for people at a school district(one letter, that sounds the same, off from mine) and a defunct tech school in India.
The amount of personal information that companies will send to an unverified email address is terrifying. Devs, please make sure you send a confirmation email before believing an address is good. If I was malicious I could really mess with a lot of travel plans for people, among many other things.
Sounds tedious if it’s the former
Requires zero user action to make up an address
Thankfully it isn't.
To set a catchall with sendmail, add a line to /etc/mail/virtusertable like so:
And if I decide to block a particular address, which I've only had to do with addresses set up for specific sites (which I've then decided sends me too many emails -- I've yet to receive spam that's not from the site in question), add a line to /etc/mail/access like so: And that can be temporarily (or permanently) reversed by commenting it out. I imagine it's something similar for postfix, qmail, exim, etc.Edit: I'd add that I make extensive use of folders/filters to handle email as well, so unless I don't want to use a site/service any more, I'll usually create a filter unless I don't want any more contact with a specific entity -- then it's "user unknown" for that email address.
Most of the time, the email addresses only end up coming from the company they were given to, but a few hacks like LinkedIn continue to produce scams and spam emails.
There have been numerous times now where I'd like to quickly provide details about a problem affecting some GitHub-hosted open source project I'm using, sometimes along with a fix. But since I can't easily create a throwaway GitHub account, I'll just end up keeping the information and fix to myself. I wish that wasn't the case.
Gmail has "+", but I've used '.' for a very long time.
example.hn@mypersonalsite.com
For most sites, things like this are enough to fool. Alternatively I use a base64 encoded version of the sitename.
so: example.aG4g@mypersonalsite.com
I got banned, cause I created a couple of separate accounts with temporary email addresses and aliases on my gmail account.
I redefined the '-'/'+' localpart separator of the username/localpart of my fully-qualified email address to be something else (it's a letter).
so, my own mail alias works just fine ... in commercial Git repos and many websites.
Google's GMail lets you use multiple periods as you see fit but that is easily stripped out (to get your username).
Just another cat-n-mouse in computer security.
Might make more sense for GitHub to enforce whitelisting.
more on this local-part separator: https://egbert.net/blog/articles/comparison-of-local-part-in...
(again, my hardened website cannot be viewed on only Chrome clients as these clients remain broken for intentionally ignoring my server-mandated HTTPv1.3/ChaCha-only).