Would this be a safe and useful service?

[RJM62]

Yesterday afternoon a client asked me if I could code his contact form processing script to send him a text message whenever someone submitted a contact form that specified a high-priority subject. He wanted a nudge when an important message had been sent.

Sure, said I, and I asked him to send me an email from his phone's text message application so I could get the phone's address.

This client is brighter than most regarding technology, and yet he had no idea that his phone even had an email address, much less that he could send messages to email addresses from the SMS / MMS applications. That got me thinking that there probably are a lot of other people who don't know that, either.

I'm thinking that it might be a useful service to set up a site that does one simple thing: Find a user's phone's email address for SMS or MMS, and send that information back to the requester.

It would basically be a stripped-down IMAP client with an auto-responder, that would be executed when a user sent it an email using their SMS or MMS application. It would simply reply with a message saying, "Your phone's SMS [or MMS] address is" and echo the sending address. Then both the incoming message and the reply would be deleted from the server.

It would be a no-brainer to code, but I'm wondering how vulnerable it would be to spoofing, which could result in annoying text messages being sent to people who never asked for them.

I'm not sure how valid a concern that is because the spoofer would have to know both the phone number and the user's carrier, plus the carrier's email-to-text gateway suffix (@vtext.com, etc.), and the only thing that would happen would be that the owner of the phone would get a text message telling them what the phone's email address is. So my first thought is that there would be little motivation to bother with it. Also, there doesn't need to be a database, so there's nothing to inject. But I could be missing something.

Any thoughts?

-Rich

 

[ZeroPapaGolf]

It seems unnecessary. A quick Google search will tell you what the standard format for any carrier is. It's just number@txt.att.net, for example.

Sent from my SAMSUNG-SGH-I337 using Tapatalk

 

[poadeleted21]

SMTP is a god awful protocol. There's no way that I know of to know who the sender actually was without a warrant. You can type whatever you want in the "mail from" command or headers.

 

[RJM62]

SMTP is a god awful protocol. There's no way that I know of to know who the sender actually was without a warrant. You can type whatever you want in the "mail from" command or headers.

I agree. But what advantage would there be to bothering? Other than simply annoying someone whose phone number and carrier you already know, what would be the point?

It's a good point, though. It could be used that way unless some code (and a database) were added to limit the number of requests from any given number.

-Rich

 

[RJM62]

It seems unnecessary. A quick Google search will tell you what the standard format for any carrier is. It's just number@txt.att.net, for example.

Sent from my SAMSUNG-SGH-I337 using Tapatalk

But you're not a moron.

But you're right: Anyone with common sense could figure it out, or simply send an email from their SMS app to their own email address and accomplish the same thing. It's the novel nature of the thing that got me thinking.

-Rich