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 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.