You can use something and still fundamentally not understand it…
Here’s an example of a message that’s send the way you describe. Note the fully shown email address in the from field at the top.
And here’s a real 2fa short code message. This was not send via email, this was a registered shortcode number that would be registered with your telephone provider.
Notice that the real 2fa message doesn’t show a full email address as the sender?
If your company is relying on the sms/mms mail gateways, then you are not going to be able to reach most of your clients. Here’s the top 5 carriers in the USA.
Verizon (146 Million users) was opt-in for me (I had to turn it on in order to get my cloudflare alerts to work, can’t rely on email when I’m specifically monitoring the email server). For those who have Verizon, text “status” to 4040 to see if your gateway is active! (https://www.verizon.com/about/account-security/email-to-text-faqs). Though it is entirely possible that it’s no longer opt-in or has changed defaults over time… possible even repeatedly, my account is very old…
T-mobile’s (131 million users) gateway is opt-out last I checked. Meaning that a lot of people will find it once after getting some spam and turn it off.
Boost (7 million) mobile relies on AT&T… See above.
US Cellular (4.4 million) - looks like it’s working.
These are the five biggest carriers in the USA, with 3 of them default to “no”… If you’re trusting this function to work for your users, then you’re in the wrong from an IT perspective.
Another reason you know that most companies do not use this mechanism for 2fa… 2fa pins expire. Can’t send 2fa pins that take “A couple of hours” to arrive when that pin expires in 10-15 minutes for most services.
Most sms texts come from registered services like twilio (https://www.twilio.com/en-us/messaging/channels/sms/short-codes), ez texting, salesmsg, textmagic, simple texting, slicktext, textla, etc… For the ones I’ve interacted with, you use their APIs to send messages, and the messages always come from a shortcode or normal phone number, never from an email address. I’ve never… ever ever… received an MFA pin from an email address. Always short codes or full phone numbers.
You have typed a lot to not have made an impact at all. The entire Crux of your argument is that you don’t see the message arrive as an email. That would be because it gets translated from email format to mms before it arrives on your end. Yes receiving a code 4 hours after is a problem, no the code will not work at that point. Again I do not know the specifics of how it operates on the back end once it is sent out but please do not try to talk down to me about how one of the duties at my job works. I highly doubt your assumptions are correct as I use the service to send 2fa weekly while on live calls with cx. I have never once stopped to ask which phone carrier the cx is using. Many of my company’s clients are international… Yet mysteriously they can all receive the texts that I’m sending via an email. However there have been some cases with super small regional carriers where the message is massively delayed.
The entire Crux of your argument is that you don’t see the message arrive as an email.
This isn’t a Crux… All of the mail gateways work this way.
Fun fact those are actually emailed most of the time. MMS format your [email protected]
You stated this… You stated that it’s phonenumber@carriergateway.
This is how they work. They show the email address.
I have never once stopped to ask which phone carrier the cx is using.
This doesn’t even jive with your initial statement… how do you fill in the carrier.tld part if you have no idea what carrier the customer is on?
Your own story doesn’t make sense anymore.
Yet mysteriously they can all receive the texts that I’m sending via an email.
And yet I’ve shown you MILLIONS of customers in the US alone, direct from the carrier, that will not receive that message as that service DOES NOT exist for them outright… This is literally 1/3 of the US, with another 1/3 that is likely opt-in.
Edit:
Yet mysteriously they can all receive the texts that I’m sending via an email.
Yes, because you’re not doing it the way you claim you’re doing it… I’ve already told you that the way it’s done in industry is through SMS services like twilio or through registered short-code services. And those are API interactions, not email. You’re not using the carrier gateway service. These services have strict KYC requirements that the email gateways never did. You might make your own gateway for email bridging, but at that point it’s not the phonenumber@carrier.tld that you’ve claimed, and that email bridge that you develop would be a registered short-code/phone number and interact as a normal SMS/MMS message. I wouldn’t suspect this based on your explanation either as it wouldn’t take hours for your own email bridge to handle an email from your own infrastructure, or if it does… your IT team probably sucks (probably not even by their own fault). This wouldn’t require you to know the carrier the user is on since twilio would just be translating/sending it as a normal SMS/MMS. https://www.twilio.com/en-us/blog/build-sms-email-bridge-python-fastapi-twilio as an example. But once again… this has nothing do with your claimed phonenumber@carrier.tld function which is the carrier sms gateway which doesn’t work as you’ve stated these days.
You can use something and still fundamentally not understand it…
Here’s an example of a message that’s send the way you describe. Note the fully shown email address in the from field at the top.
And here’s a real 2fa short code message. This was not send via email, this was a registered shortcode number that would be registered with your telephone provider.
Notice that the real 2fa message doesn’t show a full email address as the sender?
If your company is relying on the sms/mms mail gateways, then you are not going to be able to reach most of your clients. Here’s the top 5 carriers in the USA.
Verizon (146 Million users) was opt-in for me (I had to turn it on in order to get my cloudflare alerts to work, can’t rely on email when I’m specifically monitoring the email server). For those who have Verizon, text “status” to 4040 to see if your gateway is active! (https://www.verizon.com/about/account-security/email-to-text-faqs). Though it is entirely possible that it’s no longer opt-in or has changed defaults over time… possible even repeatedly, my account is very old…
T-mobile’s (131 million users) gateway is opt-out last I checked. Meaning that a lot of people will find it once after getting some spam and turn it off.
ATT (118 million users) turned theirs off outright… https://www.att.com/support/article/wireless/KM1061254/
Boost (7 million) mobile relies on AT&T… See above.
US Cellular (4.4 million) - looks like it’s working.
These are the five biggest carriers in the USA, with 3 of them default to “no”… If you’re trusting this function to work for your users, then you’re in the wrong from an IT perspective.
Another reason you know that most companies do not use this mechanism for 2fa… 2fa pins expire. Can’t send 2fa pins that take “A couple of hours” to arrive when that pin expires in 10-15 minutes for most services.
Most sms texts come from registered services like twilio (https://www.twilio.com/en-us/messaging/channels/sms/short-codes), ez texting, salesmsg, textmagic, simple texting, slicktext, textla, etc… For the ones I’ve interacted with, you use their APIs to send messages, and the messages always come from a shortcode or normal phone number, never from an email address. I’ve never… ever ever… received an MFA pin from an email address. Always short codes or full phone numbers.
Edit: typo
You have typed a lot to not have made an impact at all. The entire Crux of your argument is that you don’t see the message arrive as an email. That would be because it gets translated from email format to mms before it arrives on your end. Yes receiving a code 4 hours after is a problem, no the code will not work at that point. Again I do not know the specifics of how it operates on the back end once it is sent out but please do not try to talk down to me about how one of the duties at my job works. I highly doubt your assumptions are correct as I use the service to send 2fa weekly while on live calls with cx. I have never once stopped to ask which phone carrier the cx is using. Many of my company’s clients are international… Yet mysteriously they can all receive the texts that I’m sending via an email. However there have been some cases with super small regional carriers where the message is massively delayed.
This isn’t a Crux… All of the mail gateways work this way.
You stated this… You stated that it’s phonenumber@carriergateway.
This is how they work. They show the email address.
This doesn’t even jive with your initial statement… how do you fill in the carrier.tld part if you have no idea what carrier the customer is on?
Your own story doesn’t make sense anymore.
And yet I’ve shown you MILLIONS of customers in the US alone, direct from the carrier, that will not receive that message as that service DOES NOT exist for them outright… This is literally 1/3 of the US, with another 1/3 that is likely opt-in.
Edit:
Yes, because you’re not doing it the way you claim you’re doing it… I’ve already told you that the way it’s done in industry is through SMS services like twilio or through registered short-code services. And those are API interactions, not email. You’re not using the carrier gateway service. These services have strict KYC requirements that the email gateways never did. You might make your own gateway for email bridging, but at that point it’s not the
phonenumber@carrier.tldthat you’ve claimed, and that email bridge that you develop would be a registered short-code/phone number and interact as a normal SMS/MMS message. I wouldn’t suspect this based on your explanation either as it wouldn’t take hours for your own email bridge to handle an email from your own infrastructure, or if it does… your IT team probably sucks (probably not even by their own fault). This wouldn’t require you to know the carrier the user is on since twilio would just be translating/sending it as a normal SMS/MMS. https://www.twilio.com/en-us/blog/build-sms-email-bridge-python-fastapi-twilio as an example. But once again… this has nothing do with your claimedphonenumber@carrier.tldfunction which is the carrier sms gateway which doesn’t work as you’ve stated these days.