There are already about 10 threads on this.

+1

a bunch of those 10 threads are mine and dont seem to be getting the question answered.

In the US I know you can send an email via text.  My understanding is that all cell carriers in the US have this.  For verizon it would be 5551212@vtext.com

Out of curiosity I just tested it out.  I did have to shorten the System Message for the 2 Step Verification message slightly to see the entire message including the code in the text but once I set it up it worked flawlessly for me.

Carriers have limits on that. We tried it and after a few days they stopped working.

I believe some carriers are severely restricting email to text now.

On T-Mobile, we get:
RSP: 452 4.1.0 server temporarily unavailable AUP#MXRT

Never tried it at scale in production so appreciate the info.

I could definitely see cell providers restricting email to text/vtext functionality. Probably a spammer in-road that hasn't been fully exploited yet. 

These Authenticator Apps from Google and Microsoft require a download / additional phone app. Boo. Sucks.

However, users need to learn how to use these Authenticator apps. The number of web applications using them across the Internet is rising.

We have a client who uses contracted labor, and many are refusing to put the authenticator app on their personal devices.  Some believe it's a way for the employer to track them, or have cited other personal-privacy reasons.  This particular account uses Azure AD so there is a text/SMS option for MFA, but it would sure be handy if SmarterMail could bundle in that functionality.  We've had many requests for something other than secondary email or authenticator as the MFA method.

 

Messaging to SMS for a company or any high volume operation requires registration with the Campaign Registery as a Campaign Service Provider and the payment of slush money (small amount) to the appropriate folks to get your messages through. You must declare your campaign, register it, and pay up for the right to be kicked off when you violate your declaration once it is accepted. I did it, wasn't difficult and it works. You must register the source numbers your messages will be originating from. Either individual server operators would need to do this, or possibly SmarterMail could figure out how to route the MFA messages through a central service, but then they would need to charge for that service as their costs will be volume based.

For more info see https://www.clearlyip.com/services/10dlc-messaging-update/

Hmmm... maybe.  We use <cellnumber>@<cell carrier's email-to-sms gateway> for system messages and such, and it works fairly well.

Some of our customers do that for MFA, using the email-to-sms gateway address as the "secondary" email address to receive the MFA code.  But, the performance varies wildly.  In our local market, it only takes a few seconds for the text to arrive at an AT&T mobile number.  In other markets, such as DFW, our clients have reported 30-60 seconds of delay, and they are also on AT&T.

It would be nice if SmarterMail had the email-to-sms gateway server addresses pre-programmed, so users could select their cell provider from a dropdown list, and just enter their 10-digit cell number.

In the year 2023, it shouldn't  be this difficult.

 

We do this with our billing and control panel systems. Offer SMS along with other MFA options, SMS is done using RingCentral's API, super easy to implement.

ST could open this up to the development community too, allow plugins to to be made, let .net/C# devs here (like myself) create plugins for different SMS providers like RC, Twillio etc.

That totally sounds more like it. do what echodreamz said.

An API call might be the way.  You could then set up with one of the SIP carriers that supports SMS messaging using the API (as the Ring Central example does I think) and it would arrive at the users phone at whatever charge their acocunt has for receiving SMS - likely included in the basic plan without additional cost.  With several carriers we use around the office there is a small charge to receive email to SMS messages via <number>@<carrierservice>.com.

We tried the <number>@<carrierservice> approach, works sometimes, doesnt work at all for others, The API method (we use RingCentral) has been 100%. The RC API doesnt cost us anything extra outside of our normal RC costs for our service with them. The TCR registration was no big deal and easy to complete.