Live data from Hacker News

Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

github.com

61–70 of 304 posts

Re: Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

#61
post #13

How about blacklisting Gmail? They're a major source of spam.

The issue with blocking Gmail is that Gmail is a lot of people's only email. This list is a list of domains people use for addresses that definitively aren't their primary email address (since they are disposable/temporary/forwarding addresses).

While Gmail might be a major source of SPAM, they're also the email service most people legitimately use. If you block dummy-address@my-email-relay.tld, someone might be annoyed, but can sign up with their non-proxied address. If you block Gmail, the person can't just use their "real" address. You're forcing them to create a different email address to use your service - and there's no reason to think that new email address will be from a service that better validates their users.

Re: Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

#62

The reason disposable email addresses exist and are popular is because services have abused users' trust to not use these emails for shady ad revenue and marketing schemes. It's further compounded by shoddy security that leads to leaks and exposure of people's personal email addresses to pwned compromised lists. People don't want to give up their personal email addresses so that they can be spammed or hacked. Until s…

I’m the founder of a small bootstrapped SAAS and people use disposable email addresses all the time to avoid paying for our product. We don’t sell any data.

Why don't you ask for a credit card instead of relying on email?

Re: Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

#63
post #40

Earlier quoted context omitted.

I think as long as it's just INCOMING email, what's the harm in it?

People can use it to sign up for things like discord and then use that to spam. Though I guess even Gmail could be used for this

To spam who? How? Sybil attax ?

Re: Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

#64

Earlier quoted context omitted.

> people use disposable email addresses all the time to avoid paying for our product. From the prospective subscriber’s perspective, that’s your problem to worry about — not theirs. > We don’t sell any data. How should users know that? It’s also not just a matter of selling data — almost all companies will spam your email address, even if you check the box asking them not to.

> almost all companies will spam your email address, even if you check the box asking them not to. I find this very hard to believe. "Spam" has a specific definition; the most important bit of which is that it is unsolicited. Mails landing in your inbox that you'd rather not get, but which are not unsolicited (say, by you signing up for an account and confirming your address), are not spam by definition . "Almost all…

As a user, I don't at all care about the technical/legal definition of spam. As with obscenity spam is a case of "I know it when I see it".

Re: Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

#65
post #42

Earlier quoted context omitted.

Recently, I wanted to try a web service but they did not let me register with a disposable email address. Well, I guess I will not try the service then.

And how would you protect your service from users that just sign up with disposable Emails for the 7 day trial over and over again?

> just sign up with disposable Emails for the 7 day trial over and over again?

That's a lot of effort to go through to avoid paying for something. And I guess you can't keep your data or configuration, if the app has any.

Re: Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

#66
It's arguably the case that Firefox Relay is no different from the other services in this list. If someone can use it to create ~unlimited identities for almost free, that serves the same purpose as any other disposable email service.

And frankly, there's no sense in getting upset about a directory of services that allow the creation of unlimited disposable identities. If it wasn't this github repo, it would be another. As long as there's demand for lists of these services, the lists will exist.

And why do folks want lists of these services? Because they're a massive nuisance: folks avoid paying for services and abuse free services with spam (or worse). This isn't to say that businesses shouldn't support their users in being privacy-conscious, but the unfortunate fact of the matter is that Sybil-esque attacks are costly to businesses (time, resources, reputation), sometimes to the point of being existential threats. Many businesses have no choice but to make _some_ tradeoff between user-friendliness and revenue/operations cost.

My own business was absolutely _flooded_ with spam until I started blocking most popular disposable email services. I built tools to help detect and mitigate the spam, but it was purely reactive. I was spending more than half of my time fighting spam instead of working on the product.

The reason these services work for privacy-conscious folks is because they're convenient. But that's the same reason they're useful for malicious actors: nobody wants to spend the time to set up a new gmail account. The (time) cost of establishing the identity is what makes it hard to use for abuse.

There are obvious potential solutions. The first is for services like Firefox Relay to allow abuse reports. If I see spam from a Firefox Relay user, I should be able to report it and have it count against them. Any legitimate service should hold its customers to some responsible use guidelines, and if they break those rules, there should be consequences.

Another is that identities should not be "free". I disagree with Mozilla's pricing: $1 for unlimited identities is practically begging for bad actors to use the service. Setting limits or scaling the cost of the service (more identities per unit of time costs more, or throttling identity creation) makes it harder to abuse services with those identities. Almost no legitimate users actually need truly unlimited email addresses, and the ones who do can very much afford to pay more than a single dollar. Even generous limits would help to avoid many problems.

I'm generally bearish about crypto and blockchain technology, but I can also see how using it for identity would be super beneficial. There's some cost to establishing the identity, and you separately can use a (~worthless) disposable email for communication. The identity is worthless to "leak" and isn't useful for marketers.

Re: Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

#67
One of the comments on the issue [1] says:

> My reasoning on including this is that an email with a mozmail domain is never going to be a primary email and is always going to forward to some other address.

This is laughable and sad at the same time. I have a few tens of email addresses that are used for different purposes and with different classes of sites and services. None of them are “primary” and I wouldn’t really give one address used for one purpose to a service that I classify under another. People also use aliases on email services, and those are also “forwarding” emails in a way. This point about forwarding is a poor distinction.

As other comments in the issue have stated, adding Firefox relay domains to this list is a user hostile move with no benefits. I’d love to see them try this with Apple’s email relays (used by Sign In with Apple if a user decides to hide their email address).

[1]: https://github.com/disposable-email-domains/disposable-email...

Re: Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

#68
post #2

if you're having issues with disposable emails, you need to either add phone verification or make it so people can try your service (or view prices!) without signing up

If you're masking your email because of privacy concerns, are you really going to be happy to go through phone verification?

Re: Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

#69
post #2

if you're having issues with disposable emails, you need to either add phone verification or make it so people can try your service (or view prices!) without signing up

Just get rid of the password and require email based magic link login. Fine use a disposable email but the account will be wiped soon when you never log back in again.

Please no. I hate services that do this, it takes longer to jump over to email and open a link then to autofill the info with a password manager and click submit.

Re: Mozilla's Firefox Relay to be added to disposable-email-domains blacklist

#70

Earlier quoted context omitted.

> people use disposable email addresses all the time to avoid paying for our product. From the prospective subscriber’s perspective, that’s your problem to worry about — not theirs. > We don’t sell any data. How should users know that? It’s also not just a matter of selling data — almost all companies will spam your email address, even if you check the box asking them not to.

> almost all companies will spam your email address, even if you check the box asking them not to. I find this very hard to believe. "Spam" has a specific definition; the most important bit of which is that it is unsolicited. Mails landing in your inbox that you'd rather not get, but which are not unsolicited (say, by you signing up for an account and confirming your address), are not spam by definition . "Almost all…

Most email I get from services is unsolicited. While I did sign up for the services I did not solicit every newsletter, marketing email, "notification" and so on.

For 98% percent of services I use I mainly want my email for one thing: a way to reset my password.

Often I need to unsubscribe from each of them individually and then navigate some sort of "notification preferences" interface. Even after that has been done a lot of them seem to default any new newsletter or preference to on instead of deriving the preference from the closest existing option.

Post reply on HN