Agreed on the challenge of working with a fixed number of phone numbers (and I say this as someone who recently moved to NYC and would love to own a 212 number).
In the industry, phone numbers that have a high-volume of unwanted traffic are called "dirty numbers." Think of a number used by someone who signed up for every sweepstakes they came across for 40 years, or maybe a number that's particularly cute (you probably don't want to have a cellphone tied to XXX-867-5309).
If we sold them, dirty numbers would be worse-than-useless for (almost all) of our customers. So, whenever a phone number is released by a Twilio customer, we reserve it for a minimum of two months before it can be purchased by another account. We also monitor each reserved number until it reaches an acceptably low number of phone calls.
If you do find yourself getting unwanted calls, you can use the <Reject>TwiML verb[^1] to create a blacklist - your account won’t receive or be charged for those calls.
We have a similar challenge in working with the fixed number of IPv4 addresses we're able to get our hands on. We offer our customers dedicated IP addresses for outbound email, but there are sometimes situations where a customer doesn't want to hold onto one forever.
We want to make sure mailbox providers (like Gmail and Hotmail) have time to realize the IP is not in use, rather than mistakenly associating it with the old customer. It makes sense to hold onto it for a while after the customer releases it before allowing another customer to purchase it. We call this the "cooldown period."
Gmail primarily uses domains for reputation, according to their docs (and in practice). I never had to deal with much IP management when sending to Gmail or G Suite recipients.
Microsoft does use the range of black holes, e.g. Spamhaus, including using their own, so etjossem is right about having to cool down a bad IP before requesting whitelisting. Almost all ESPs and black holes will reject whitelisting requests without a sufficient cool down period anyway.
Gmail is certainly ahead of its time. I haven't tried sending with IPv6 addresses but the Gmail documentation claims it will work.
Just from looking at my own mail servers and mail headers, Gmail will happily both send and receive mail over IPv6, and has for years. Same with Outlook. Oddly, despite Apple's push for IPv6 support, iCloud doesn't seem to have an IPv6-capable MX.
You're spot on about Google; they've moved forward from this approach and lean more heavily on domain-based information now. But they're a rare exception, and they have very little to go on when the domain is just "sendgrid.com" (i.e. the customer hasn't set up whitelabel yet). So we want to make sure we're always giving customers new or cooled IPs!
I'm surprised you willingly burn your own domain's reputation. Other email-as-a-service companies require a validated domain with SPF and DKIM in the DNS TXT records or use a burnable subdomain, e.g. freeaccount12345.sendgrid.com; or even better, 12345.sendgridfreeaccount.com.
Hey Greg, uneducated but interested inquirer here: Once you're inside a phone network, phone numbers can be as long as you like, can't they?
Could Twilio not arrange for a new "country code" to be assigned, possibly to an industry working group of some kind, and then make the numbers ~64 digits long? Then there should be more than enough to go around and to discard dirty numbers, and the numbers could always be made larger in the future if needed?
No, because 98% of peoples' phone systems out there expect a destination number in a specific format. You can't just have a NANPA area phone number that is arbitrarily long or has extra digits in it.
If you are way, way bigger than Twilio you can create a country code. Country codes exist for special purposes like the Iridium satellite phone network. But you cannot just create a country code for arbitrary purposes and expect it to work with the world's PSTN/SS7 infrastructure, any more than you can choose an arbitrary non-RC1918 /8 of IP space and start using it on the public Internet.
Maybe Twillio isn't big enough by themselves, but if you add in Google Voice, Plivo, all the internet VoIP providers, and all the Cable Company VoIP services, you are big enough.
Is there a VoIP trade association they are all members of? If so, the trade association would be big enough to push for a new country code for the special purpose of software-based telephony just like Iridium has one for satellite-based telephony.
If that fails, Iridium is struggling. That hypothetical trade association could acquire the country code from Iridium with special agreements to ensure that Iridium still can lease numbers for no-cost for satellite-phone purposes.
You're wrong that Iridium is "struggling", they're in the process of launching and commissioning their next generation satellite system. It is used so extensively by the US DoD, NATO militaries, aircraft based phone systems and maritime systems that it's quite well positioned. It is the only real LEO truly global coverage satellite phone network that includes high latitude polar regions. The globalstar bent-pipe network architecture and coverage is a joke.
The problem with that idea is I'm pretty sure an incoming call with a +988 (or other) country code is much more likely to be screened by Americans. I'd be like "I don't know anyone in that country". Not sure but I suspect Europeans may screen calls if not within their set of known Euro country codes.
I wouldn't pick it up because I'd be worried about fees for taking an international call. I don't know if there are actually fees though the uncertainty would stop me.
Or if you're in the local area, you can find somebody with a POTS 212 number or cellphone and pay them cash. Porting a number to a voip service is basically as simple as the bill payer writing "authorized to port to NEWSIPTRUNKINGPROVIDERNAME 2017-07-18" plus a signature on a one page scanned piece of paper.
At Penn State, we run our own phone system and have the 867 local exchange (in the 814 area code). If you dial 867-5309 from a phone on campus, it plays "Jenny" for you - an Easter Egg in a phone system!
Why not disclose prior call patterns before selling the # rather than putting the burden on developers to flag spam to receive credits?
Saving a couple of cents by getting reimbursed for the call doesn't actually solve the issue when your team is wasting their time picking up the phone only for it to be a misdial or spammer.
Wholeheartedly agree that the burden is ours -- not the developer's -- to make sure a number is clean before you buy it. We monitor inbound activity for two months before making a number available for sale. <Reject> is not for spam that comes with a number when you buy it -- it's for all the stuff that happens after you put that number out in the wild.
More than that though, we can't reveal historical patterns because we'd be violating the privacy of whoever previously owned the number.
Is it actually a problem though? I'm not a high volume consumer of numbers, but I've not had any spam on the handful of numbers I have.
The same can't be said for my physical POTS/cellular numbers.
Anecdote of one, and everything, but has anyone actually impactful levels of spam from an insufficiently cooled number that they wouldn't have had from any number in the area code?
Agreed on the challenge of working with a fixed number of phone numbers (and I say this as someone who recently moved to NYC and would love to own a 212 number).
In the industry, phone numbers that have a high-volume of unwanted traffic are called "dirty numbers." Think of a number used by someone who signed up for every sweepstakes they came across for 40 years, or maybe a number that's particularly cute (you probably don't want to have a cellphone tied to XXX-867-5309).
If we sold them, dirty numbers would be worse-than-useless for (almost all) of our customers. So, whenever a phone number is released by a Twilio customer, we reserve it for a minimum of two months before it can be purchased by another account. We also monitor each reserved number until it reaches an acceptably low number of phone calls.
If you do find yourself getting unwanted calls, you can use the <Reject>TwiML verb[^1] to create a blacklist - your account won’t receive or be charged for those calls.
[1]: https://www.twilio.com/docs/api/twiml/reject