I've seen other companies do this, but Google is a notable example.
When you turn on two-factor authentication with Google, one of the options is to receive an SMS when you logon. I've noticed that the sender's address, rather than being an MSISDN like 346-555-1234 is "Google".
How are they doing that?
In the smpp 3.4 specifications, the source address can be defined as an alphanumeric string of 11 characters
Related
I use twilio to send sms messages but in the message I am trying to create it is a very long url and therefore won't send in 160 characters so twilio cuts the message off and url doesn't work.
If I use the automated twilio Shorten SMS the same thing happens.
I assume there is a limit to the amount of characters Twilio will send and I believe it cannot join concatenated messages in Australia from Twilio.
Edit: as of August 2019 Twilio has discontinued its URL shortening service. You should consider using a 3rd party service that allows you to set a unique base URL.
Sharing a static base-URL for a link shortener can cause unexpected carrier filtering issues with U.S. 10-digit long codes (short codes are not carrier filtered). Carriers sometimes spam filter messages by content, and the base-URLs of the links being shared appear to be one way that they categorize spam.
Twilio is working on a next-generation URL shortener that provides randomized base URLs as an add-on to a messaging service. If you are interested in this functionality contact Twilio support.
You should check to see that URL shortening is explicitly enabled in your account before attempting to send messages.
https://www.twilio.com/console/sms/settings
I've been using Twilio to send SMS and things work great. The only issue is that Twilio charges for both outbound and inbound messages. As such, we've been looking for other solutions.
We thought we found it with Plivo as their pricing was more favorable for SMS.
However, with Plivo, very quickly our outbound messages are being marked as spam or something and they're not being delivered.
We are sending the exact same message every day to about 5k users at a given time in the day. The message has a url in it, but it is something our users signed up for.
Two questions:
1. Why does everything work on Twilio and not on Plivo?
2. Is there a code change I can make to ensure our outbound messages sent with Plivo are not marked as spam by carriers and then stopped?
You need to contact Plivo about this. I experience this problem too. Their carrier mark our number as spammer since we are sending almost the same messages (verification). They called their carrier and our number was white-listed.
Plivo Sales engineer here. This is indeed an issue with the carrier marking your messages as spam. We can definitely help you overcome this. Could you please drop an email to ramya(at)plivo.com and we can sort this out?
You need to contact with Plivo support , there may be problem for number prefix for country like if you are using twilio you have to add +(with country prefix) but not in Plivo. It will be better to contact with Plivo support.
Thank You
I dont know how Pilvo work but usually with SMSC there is Message Queue associated sometimes with each SMPP Client and also with Mobile Station. You can't always send messages until your certain number of request are still pending. there is a specific error code that SMSC sent to its client about message queue overflow.
BADABING BADABOM! After having a look in the Plivo administration I noticed a new option under other-settings "Automatic Encoding Of Unicode Characters". As Norway uses inernational characters this is definately a setting for me, and after enabling it all SMS are delivered as expected. So remember to enable this setting.
MAKE SURE TO ENABLE THIS:
Path: Plivo admin / Messages / Settings / Other settings
Feature: Automatic Encoding Of Unicode Characters -> Enable
When I send a test sms from https://www.twilio.com/user/account/developer-tools/api-explorer/message-create with a predefined friendly name, it doesnt apear on my phone. I only see the number.
-if this isnt possible, do you know other providers with this function that work?
[UPDATE]: Twilio now supports this feature.
You can now send messages from an alphanumeric sender ID using Twilio. I wrote up a blog post on how you can achieve this in Ruby and you can check out this article on how to get started with an alphanumeric sender ID on Twilio for more of an overview. Then check out the documentation on how to send an SMS message from an alphanumeric ID.
[UPDATE] Previous answer is below.
Twilio developer evangelist here.
You're absolutely right, the friendly name defined in your account is actually for your uses only and is not intended to appear in place of the number when sending an SMS. We have a few reasons for this, which might be interesting to you depending on your use case.
I don't have a particular company that I can recommend that does allow you to do this. A Google search might help though.
From what I've been reading the SPF can be used to validate email addresses by sending commands (rather than an actual email) such as HELO. I've managed to pick up a basic grasp of the policy but I can't get my head around how I'd go about solving the following problem:
I've got a number of email addresses attached to contacts in a CRM system and I'd like to find out if the email addresses are valid and still in use.
Currently we're using a REST Web Service (http://emailinspector.co.uk/) which returns "Ok" (if its ok... duh), "Bad" (if its not valid or not in use) or "Unknown". For Unknown, you are also provided some notes on why it came back with that, i.e. you are told if the Mailbox is full or if its a well known DEA.
I'd like to be able to program a script that can replicate this functionality and from what I've worked out it should use the Sender Policy Framework to do this? The problem is I don't know how I'd go about returning such precise information for "Unknown" email addresses.
Ideas and thoughts?
Actually SPF is just a text record, with some "hints" to let you know if an IP address or mail server is "allowed/Authorized" to send email for that domain. It doesn't tell you anything about an individual email address in that domain..
for example
[doon#qix:~] host -t txt labratsoftware.com
labratsoftware.com descriptive text "v=spf1 a -all"
The SPF record for one of my domains says that only the a record for the domain is authorized to send email for labratsoftware.com, and that if it doesn't come from that IP then it should be rejected (-all).
So the best you can do with SPF is tell that a received email came from an authorized host, and then use that information to help decide if you want to reject it or not.
The best way To test the validity of an email address you have, is to email it, and see if it bounces. You can use options like VERP (http://en.wikipedia.org/wiki/Variable_envelope_return_path) to automate the bounce handling. You can also try and connect to the MX records listed for the domain and try to deliver a message that way. Some Mail servers support verify (But most admins disable this to prevent information leakage). You can use RCPT TO to see if the server accepts it, but even if it does , you have no way of knowing if it will actually make it to their INBOX. My guess is that is what the API you are currently using is doing. And unknown are just ones that either don't answer, greylist, etc.
I'm trying to figure out how to set up an SMS service where users can communicate with people on phones that are not participating in my service. "TextFree" on iPhone does something like what I want to do. They let you sign up, then you can send messages for "free" to other friends that aren't part of the service.
It looks like when you sign up for TextFree, they assign you an email address [user#textfree.us]. People outside the service without MMS capabilities can't send an SMS to this user. The user must first send an SMS to them, starting a conversation. I think this is what they're doing:
Textfree signs up for an account with a bulk SMS provider, and is assigned a single phone #, like "123".
Joe signs up for TextFree, gets assigned email: joe#textfree.us.
Mary wants to send Joe an sms, but can't because she doesn't know what # to direct the sms to.
Joe sends an sms to Mary using textfree. This really just makes an http request to some textfree server. The server gets the request, and the destination # (Mary's phone).
The server sends the sms out using their bulk sms api provider.
Mary receives the sms, and sees the originator phone # as "123".
Mary replies to the sms, using this phone #, "123".
Their sms provider receives the message, and forwards it to textfree's http server.
Textfree now has to resolve that the sms received by Mary's phone # is destined for Joe (not sure how this can be done), so it can be delivered to Joe's account.
I think that all makes sense and seems feasible, I'm just not sure about that last step, how they could figure out which conversation sms' belong to. If all outside users are directing their sms to phone #123, how could I figure out which internal user the message is destined for? Is there some way to embed a unique identifier in an SMS, so that when the external user replies to the SMS, some unique ID can be embedded in there to provide that type of context to read on the reply side of things?
Long question, thanks for any thoughts!
As for the last part of your question (unique ID in SMS):
I know of no mechanism that could help you here. When replying to a short message phones only set the sender address as destination and the user is free to type the text. The headers in a short message PDU are solely for the basic transport parameters (encoding, sender-ID, ...). There is a way to define so called user data headers, but for this to be of any use for you, you'd have to be in control of most of the devices that are involved in the message delivery, including the handsets... So basically the only way I see to correlate messages with each other reliably is the use of some ID within the message text.
An alternate approach would be to rent a bunch of numbers and assign these permanently (I assume some subscription model here) to your users. This way you could use these as identification numbers within your service and forward the messages to their real phone numbers (or even a completely different media like email / instant messenger).