I know this is a subject that has been well covered here and throughout the web, so I am not asking for a list of carrier emails, however my question is how to send a text without knowing the users carrier and preferably without going through a third party.
The only solution that I thought of would be send out to all carriers. I would only be sending to US carriers, however would a large number of failed emails slow the mail server at all or cause any other problems?
Any advice on this solution or thoughts of others would be great.
If you keep sending messages to a carrier to numbers that don't exist, you'll start to get blocked as a spammer. Probably best to either ask your users for which carrier they use or use a gateway like Twilio (where I work) or the various others out there.
I would recommend using CloudVox's digits API. The carrier's aren't always up to date, from what I can tell it basically relies on the original carrier you got your phone number from. i.e. You had verizon but switched to AT&T to get an iPhone and kept the same phone number, CloudVox API would likely tell you the number is still a verizon number. However, I used this for my existing user's and then exposed a select box for them to choose their provider.
http://digits.cloudvox.com/
If you have a reason to consider using a third-party API provider, I'd recommend Plivo (I work here), among many other providers, to bypass the carrier lookup issue and have more flexibility.
It will require some extra legwork than sending to carrier emails, but you will less likely to fret over the deliverability. For example, check out the email and sms gateway built using Plivo and Mailgun API.
Related
I am creating a PHP system that will forward emails, (ie. someone#emailforprofession.com to someone#gmail.com) without using an SMTP server which is faster and more stable? PEAR::Mail or PHP: Mail? (or another one entirely)
I would be using extra headers and attachments but mainly trying to keep it looking and acting the same. (if anyone has an example for forwarding with attachments PLEASE provide it!)
And not exactly on the side but is there a way for people to be able to send email from they're someone#emailforprofession.com email address without having a complete inbox etc?
It would probably be better for me to use a real email provider but these are supposed to be free email addresses so paying by the email address is not an option, if anyone knows of a service that: charges by the month or year, has an API that email addresses can be created from and that can set up email forwards via the API that would be most appreciated.
I currently have a partial system together but would like to know which way I should go first.
Thank you all.
The PEAR class supports multiple mailer backends, which allows you to
switch whenever needed and you'll be able to perform some benchmarks
and see which backend suits you best. The native mail function on the
other hand is much less advanced and will show a clear difference in
performance, especially for that amount of mails.
I also suggest you have a look at PEAR's mail queue class:
http://pear.php.net/package/Mail_Queue
This is much more recommended for larger projects such as yours,
you'll also be able to implement a cron like feature which will send a
certain amount of mail per period you choose.
Here
I know that user agent can be faked easily when connecting through HTTP. I want to ensure access to my SOAP API only from iPhone devices. We don't know how many users will be using this when it is released but it might be a lot and we can't handle traffic from outside of the devices. Any other means to prevent this?
It's not clear to me why limiting just to iPhones would be the way to go since I guess what you're really worried about is volume per user on the API (iPhone or not) and number of users. Spoofing the client is pretty easy so a better way to would be either to issue keys/ids on signup and then limit volume on each key or by IP address. Using keys also means you'll have a better ID on your users which might be useful in the long run. IP addresses could be problematic with mobile clients but at least you can do some basic load limiting.
Unless you control both sides, there's no way to determine the type of the other party reliably over HTTP.
No. (Outside of asking them if they're on an iPhone of course.)
We run a large online community in the Netherlands. Because of that we send a lot of mail to the hotmail email addresses of our members.
Recently we have noticed that not all mail is reaching our members, because we have hit a certain limit or so it seems.
Google doesn't give a solution (yet) but we see a lot of others having the same problem.
Note, We have added (since long) SPF records for our domain, in TXT and SPF types.
What else can we do to tackle this problem?
// Ryan
To add to what bzlm said, hotmail probably isn't rejecting your mails, so much as trying to use rate-limiting to prevent spam. That said, there are a few potential solutions you could use here. You could contact hotmail and see about getting your mailserver exemption status from their rate-limiting. Depending on the size of your community, they may or may not respond to you or be willing to work with you. I suggest this only as the "diplomatic" solution.
Or, you could set up two mail servers; one for hotmail users, and one for everybody else. I know from some of the sites that I run that a lot of people register with hotmail accounts, mostly because everybody has one which they use as a "spam dump" for online services where they don't want to use their real email address. So, as you no doubt realize, the number of hotmail users in your database represents a fairly substantial percentage. Therefore, when you need to send an email, you could determine whether to send it to your normal SMTP server, or your hotmail-designated one. On the hotmail SMTP service, you'd need to add some type of waiting mechanism to sleep a certain amount of time after receiving a 421 response.
The problem with this idea is that the number of hotmail users you have, plus the delay you'll encounter in sending, means that the queue length might very well exceed the number of mails you must send. You could alleviate this problem by setting up secondary/tertiary servers, preferably on other networks... but I'm getting ahead of myself here. At any rate, I did a bit of googling around (as you probably have, too), and this isn't such an uncommon problem, but there is no obvious solution to it.
So likely, you'll either have to create some type of slightly-unorthodox network workaround, or try the "diplomatic" route and contact an organization unlikely to care about your problem. I'd suggest doing both in parallel. :)
421 means that the service is not currently available, and that the client should try again. This could be for any number of reasons, including trying to discourage you from too frequent mailing if Hotmail thinks you might be a spambot.
Why not simply let your outbound smtpd queue the mails and try again?
Why is "not all mail reaching your members"? Don't you try again if you get a 421 response?
EDIT: Do what sqook says.
The only real way to "get around" this is to become a good e-mail citizen. Make it easy for people to unsubscribe from your notifications, establish complaint feedback loops with the major mail providers, remove bouncing e-mails from your list automatically, don't send people e-mails they don't want to receive. Failing to adhere to these simple requirements makes you look like a spammer, and providers like Hotmail will treat you like one.
The mail server IP connecting to Outlook.com server has exceeded the rate limit allowed. Reason for rate limitation is related to IP/domain reputation. If you are not an email/network admin please contact your Email/Internet Service Provider for help.
https://mail.live.com/mail/troubleshooting.aspx
I advise you too wait some times
I'm looking into ways of sending a voicemail message (ideally as an audio file) to a number of mobiles/landlines in the UK (anywhere up to 300 people, but we can do them in batches if necessary).
Has anyone had any experience trying to do this?
Asterisk can certainly make calls, not just recieve them.
We use Asterisk, a VOIP provider, and a cepstral voice to send alarm calls. If no one answers, it leaves a message.
It can be a bit fiddly getting it to detect the answerphone correctly, but we've got it working with most of the ones we've come across so far.
Asterisk and probably other softswitches like (Freeswitch) could do that for you. The Asterisk voicemail config file, voicemail.conf, allows you to specify a command to run whenever a new voicemail is left in a user's mailbox. You could create a custom script or application that would do the forwarding for you.
Alternatively you could do it without any programming at all by creating an email alias for the 300 people and then assign that email address to a particular Asterisk mailbox. Asterisk supports voicemail to email by default so there wouldn't be any special configuration provided.
And you could probably also avoid setting up Asterisk by finding a VoIP provider that supports voicemail to email, which most of the Asterisk based ones do, and forwarding the voicemails to your own email alias address. In this case you'd just want to be careful about who could leave messages!
I would recommend Katalina 'VoiceGuide' - a windows-based CTI, IVR and dialler system at a reasonable price, supporting both tradtional POTS/ISDN telephony cards and VoIP. see: www.voiceguide.com
I'm implementing a email newsletter sender service using .NET and Windows Server technologies. Are there comprehensive guidelines which could help avoiding emails being trapped by spam filters and other mechanisms?
They should cover all aspects of (legal) bulk mail sending: SMTP configuration, DNS, HTML content, images, links within content etc. A simple example: is it better to embed images or load them from a server?
It would be great if you could provide some empirical data to show the efficiency of some measures taken.
Although I don't have a definitive answer, I think this is a very important question.
Here are few tidbits I know about it
Choose a clean hosting/smtp server. IP addresses of spamming SMTP servers are often black-listed by other ISPs.
Send a simple introductory email to every subscriber, asking them to add your sender address to their safe list.
Be very prudent in sending to only those people who are actually expecting it. You wouldn't want pattern recognizers of spam filters learning the smell of your content.
If you don't know your smtp servers in advance, its a good practice to provide configuration options in your application for controlling batch sizes and delay between batches. Some servers don't like large batches or continuous activity.
Unless you have a very specific reason to host the newsletter yourself, I think you'd be much better off using a third party service. There are lots out there, and some are very cheaply priced.
It'll save you on development work
(no point in re-inventing the
wheel).
Their system will handle all
the unsubscribe link stuff that you
need to include in email newsletters
to comply with CAN SPAM laws or
whatever.
They handle the spam
reports that you will inevitably get
if you have a list of any non-trivial size.
They keep records of who signed up,
how they signed up, and their IP
address, and can present those on
receipt of a spam report to prove
that their service wasn't sending
out spam.
You can use double-opt in
(or confirmed opt in), for extra
evidence to prove that the people
you're sending emails to actually
signed up to receive them.
If you really do need to host it yourself I'd suggest you search the web for "email deliverability". Things that are known to help include properly set up SPF records, DomainKeys/DKIM, correct DNS settings (reverse DNS especially - best to just use an online service to check your DNS settings). You can test a lot of these things by sending an email to check-auth#verifier.port25.com.
It's best to avoid using spammy words in your email - always a bit of guesswork this but you some words can trip filters.
But I'd guess that by far the most important thing is to be sending your email from a trusted server that maintains good relationships with ISPs (i.e. ensuring that ISPs don't think that the server is sending out spam). This is a big reason why it's much much easier to get a third party to handle everything for you.