I am using Spring JavaMail for my Email communication application. How Can achieve the functionality that when a email delivery fails due the reason of wrong email address?
Achieving this reliably is not trivial. The protocol specs for SMTP in RFC 821 specifies a number of return codes. Notably 550 is what an SMTP server should return when attempting to send an email to a nonexistent address. I say should because most public-facing SMTP servers won't do this - they either quietly accepts the message and then drops it or, if they are a little more good-mannered, accepts the message but sends a "delivery failed" notice back to the sender ("from" address). Public services like MSN and Gmail will also blacklist senders if they send enough emails to non-existing addresses to prevent spam.
The reason for this is to prevent email-fishing and spamming.
So what you can do is to
Check for SendFailedException in your code. This will only work for servers that follow the SMTP specifications and actually send an error code back. Like I said, very few public servers actually do this.
Set up a proper mailbox for the address you use as sender and monitor that inbox for delivery failed notices. Note thought that these need not follow any common pattern, which is why this is non-trivial.
For the email servers that doesn't give any notice, you really have no way of knowing.
This is one of the reasons why companies buy mass emailing services from dedicated providers, since they have all these things already built to measure bounce-rate etc. But even with those, it's never going to be 100% accurate.
These FAQ entries might help as well:
If I send a message to a bad address, why don't I get a SendFailedException or TransportEvent indicating that the address is bad?
When a message can't be delivered, a failure message is returned. How can I detect these "bounced" messages?
Related
Java 8 here, although this really is more of a generic Exchange/SMTP question I suppose.
I purchased a domain name and Office 365 support from GoDaddy, and as a result, have several email addresses through them. Let's say one of these is support#myapp.example.com.
I am writing a Java 8 app that will allow users to send emails to this support address (through the app). I will likely use the excellent Simple Java Mail library, which wraps the Java Mail API. And so somewhere in my app there will be some code that looks something like:
Email email = EmailBuilder.startingBlank()
.to("MyApp Help Desk", "support#myapp.example.com")
.withSubject("Support Ticket #12345")
.withPlainText("Something went wrong inside the MyApp!")
.buildEmail();
Mailer mailer = MailerBuilder
.withSMTPServer("smtp.host.com", 587, "user#host.com", "password")
.withTransportStrategy(TransportStrategy.SMTP_TLS)
.withProperty("mail.smtp.sendpartial", true)
.buildMailer();
mailer.sendMail(email);
Pretty straight-forward stuff, right? Except I'm confused about one simple thing: which SMTP server am I using here? Would I use the Microsoft Exchange server that my GoDaddy account provides me, or would I choose something else?
That depends a little bit on what you want to do.
If you just want to make one attempt to send the mail, you connect to the mail server that accepts mail for support#myapp.example.com. It sounds like this is an office365 server owned by Microsoft that accepts mail for myapp.example.com. There should be public DNS records for that domain. I haven't used the Simple Java Mail library, but from your pseudocode, I assume it does the DNS lookups for you.
It sometimes happens that an application encounters errors when trying to send an email. For example, somebody could restart your app server in the middle of the smtp conversation, or reboot your router, or something else. It's pretty common to use a Mail Transfer Agent (MTA) such as Exchange to help make this process more robust. If the MTA fails on the first delivery attempt, it will retry delivery for some configurable period of time. In your case, you could send the email to your Exchange server, and it would route the email to myapp.example.com.
(In this case, Exchange is sort of acting as a Mail Submission Agent (MSA), but that's kind of a nitpick.)
Hope this helps.
I have an application hosted in an Amazon EC2 Server that uses e-mail service from a shared web host. I did this to utilize the shared hosting e-mail server and the available e-mail administration tool and webmail interface.
My application uses amazon SES to send e-mail. I just authorized SES to send mails with my domain name (by adding some entries to my dns records and confirming I'm the domain owner), and this is working ok. When I need to send a mail, I connect to SES SMTP server and send it using PHPMailer.
Everything is working ok, except my mails are getting the DOS_OUTLOOK_TO_MX flag in SpamAsssasin's, making it sometimes be classified as spam.
What this flag means? Is there some way to avoid it?
Spamassassin DOS_OUTLOOK_TO_MX rule is fired when two internal flags are set by processed message: __DOS_DIRECT_TO_MX and __ANY_OUTLOOK_MUA.
__DOS_DIRECT_TO_MX flag means that the message was sent directly from sender email client to recipient MTA server. This is usually true for internal mail but can occur in your case when a recipient also uses Amazon SES for mail processing.
__ANY_OUTLOOK_MUA flag means that the message has X-Mailer =~ /^Microsoft (?:Office )?Outlook\b/ header.
Both internal flags are harmless by themselves but their combination leads to DOS_OUTLOOK_TO_MX with high spam score. You need to check X-Mailer header of messages sent with PHPMailer. This header should be set to PHPMailer, not to Microsoft Outlook or something similar.
I'm testing out the service and it appears that sandboxed applications do not support incoming replies even if the reply is from a verified number. Can I get that confirmed?
If that is not the case, my second question is how Sinch handles self-signed certs for the endpoint on non standard SSL ports ... in my case self-signed on 8443.
Lastly, a gripe. As a developer I look for immediate feedback when errors occur with my integrations. I'm not really willing to wait 24 hours for a CSV to see what happened. Any roadmap here to timely error feedback?
To handle incoming replies you need to rent a number like most providers, you can rent a number in the dashboard https://www.sinch.com/dashboard/#/numbers assign it to your app and configure your callback for SMS.
To handle incoming sms, check out the documentation here:
https://www.sinch.com/docs/sms/#smsmessagingcallbackapi
And if you have multiple numbers assigned to you app you can set the from id in the body of the request
{
“from”:”your rentednumber”,
“message”:”hello world”
}
You can always check the status for a particular message using the API here
https://www.sinch.com/docs/sms/#checkmessagestatus as you probably know long code delivery is only carrier delivery and not handset delivery.
If you mail me at christian#sinch.com I can hook you up with some more credits to rent a number.
I'm looking for the best practice, proper and "mobile carrier accepted" way of authorizing the sending of SMS/text messages to a cell phone number so that it can't be flagged as spam or abuse.
Basically, I want the user to enter in their cell phone number in my web app and then I want my web application to send some kind of SMS to them asking them to do something that tells the carrier and my app that they accept SMS messages from my web service. I do not want to spam - I only want people that want to receive the messages to their phone.
Also, I'm assuming that I can just SMTP to "email" text messages to their phone as well. Hopefully there's not a caveat to this method.
I have a little experience in this area and AFAIK there is no 'opt-in' list. However, carriers typically use the keyword DELETE to allow users to block messages.
Most carriers support a SMTP gateway addresses but you will need to know the carrier for each number. Here's a list to get you started. Also most messages received via a SMTP gateway will appear to come from different numbers on the users phone. (This is annoying for iPhone users who are accustomed to grouping of messages by individuals.)
If you are willing to pay per message services like EZTexting can take away some of the pain by doing the carrier lookup for you or sending your message via a direct, and more expensive, SMS gateway.
Here is a good overview :
http://www.acma.gov.au/webwr/consumer_info/frequently_asked_questions/spam_business_practical_guide.pdf
The US is actually behind with SMS regulations. We typically adhere to EU and Australian Legislation, which are stricter. The US will get there.
From a technical perspective:
You can use our Red API, just log on to www.redoxygen.com and select developers.
We are building a web app that should be able to receive SMS messages and store the information contained in it in database.
Which methods have you used? Which service providers are out there that can assist?
http://www.clickatell.com/ are massive and it works exactly like it says on the tin. You pay for a phone number and sms messages sent to that end up hitting a URL on your site to deliver them just like someone posting a form.
I'd recommend using a service such as TextMarks. TextMarks is free, and lets you pick a keyword for your service that allows users to route messages to you through TextMarks' shared short code, 41411. The only catch here is that they reserve 20 characters in each message for short advertisements to pay for their services.
If you ever outgrow their ad-sponsored services, you can upgrade to a premium version that doesn't include ads.
Another (cheaper) alternative is to have your users send text messages to an email address like sms#yourapp.com. Then you can have a background thread that's looking at the email account and puts the messages into the database.
I've implemented and tested this approach with major US carriers with everything from smart phones to pay-as-you-go "crappy" phones without a hitch.
When the user sends the SMS to your email address you get the SMS email gateway address (e.g. 8055551234#vtext.net) so you can send response messages.
The only downside is that it's a bit more difficult to find the "send to email address" options on most phones, but it is (basically) free for you. This is especially helpful for reducing costs while testing out workflows. Those ~3 cents for each SMS add up pretty quickly, especially during automated testing.
When you want to support SMS numbers you can configure most SMS gateways to send an email to an address, so you won't have to change your infrastructure to support a "real" SMS messages.
I haven't done it yet, but I guess you could also setup an Asterisk system on your server, then get a regular VOIP acccount (which Asterisk hooks into) and configure the Asterisk server to forward all SMS to your application. This article might help setting up the Asterisk server.
I've had experience using MX Telecom as an SMS Gateway. Essentially they posted data to our web service every time we received an incoming SMS. The application in question was also sending SMS messages as well and we just did an http GET to a web page of theirs.
I can't speak to the business end (i.e. cost), as I was just in charge of implementing the features - but working with an SMS gateway is really very simple from a development perspective.
+1 on sebastian i was jsut writting pretty much the same
if you are working with ruby you might want to have a look at adhearsion
You can use SMS gateway software which will receive SMS messages through a GSM modem or 3G dongle connected to a PC and POST them to your website via HTTP. Eg: this software