How do I track failures while sending mail using Java?

[Yogesh Gandhi]

Hi

I have been using javax.mail package to send emails.

I used Transport.send method which throws a MessagingException

Now you see when we send more than 1000 mails, there is a validation at the server side or somewhere, which blocks our IP (if its not properly registered.... may be not a  registered domain or something)
So, after 1000 mails or so, the java program does send mails, but the mails never reach the recepient.

And we never come to know that emails are not going at our end in java program, as the Transport.send doesnt throw exception.

Can someone please guide  me if it is technically possible to track such failures?

[Tim Moores]

I don't think JavaMail has anything like that built in, as that's really a function of the mail server. It can be hours (or even days, in unlucky cases) until a mail server gets to deliver a piece of mail, so there's no way to check it at runtime anyway.

To ensure delivery, at the very least you need to set up SPF.

It's also easy to set up DKIM with JavaMail, and you should do that as well.

Also check if the IP address you're sending from is on any of the common blacklists; Spamhaus is a good resource for that.

[Matthew Bendford]

First you have to understand how e-mail is designed, how it's supposed to work and what's wrong with using static Transport.send().

To not get too far into it static Transport.send() tries to directly connect to the MX of the recipients domain. This only works when the server this code runs on is correctly setup to be a MX of your domain, otherwise your mails are most likely marked as spam or maybe even silently dropped without any error message at all.

That's where a proper mail server, a MTA, and non-static Transpirt.sendMessage() comes into play: Instead of try to directly connect to the recipients MX you first connect to your MX and have it handle sending the mail. This way you also get proper error messages if the delievery of a mail failed like if your domain or MX is blocked due to spam reports or if the recipients inbox is full or doesn't exist.

Yes, JavaMail can be used to do all that - but you have to use it correctly in combination with a proper set up MX for your domain. Otherwise it looks like some malware running on your local machine try to send out spam mails. That's why ISPs serving private customers gave countermeassures in place to allow you to connect proper set up MX like google or outlook but prevent from some malware going rogue to pretent to be a MX. Also private customer ranges are on pretty much any blacklist. So you have to rent a server in a proper datacenter with good reputation.

[Paul Clapham]

And following on from that: Yes, your mail server (if set up correctly, as MB says) can send you error messages if an e-mail cannot be sent. But don't expect those messages to result in Transport.send() throwing an exception. They will occur much later and they will look like a response to the e-mail message which ultimately could not be sent. (At least that was my experience when I was working on e-mail senders; it was a long time ago but e-mail protocols haven't changed much since then.) This is mainly because your mail server puts your e-mail send request into a queue, rather than trying to process it immediately.

And once your e-mail volume starts getting large, you won't want to have a person assigned to reading all of the e-mail responses to find those failure reports. But it's possible (again using JavaMail) to automate some of that.

[Tim Moores]

Paul Clapham wrote:They will occur much later and they will look like a response to the e-mail message which ultimately could not be sent. (At least that was my experience when I was working on e-mail senders; it was a long time ago but e-mail protocols haven't changed much since then.)

Just to elaborate: In addition to mails about permanent failures, there may also be messages about temporary delays - e.g., if the target mail server is not reachable right away. This will cause the sending to be delayed by 4 hours, and then 12 hours, and then 24 hours etc. until it succeeds. And as Paul said, if it fails permanently, it will notify you about that, too, so you can ignore the messages about temporary delays until then.

[Tim Holloway]

Some ISPs have anti-spam mechanisms in their mailservers. They may limit the number of emails that they will accept per day, throttle senders who send lots of mail to non-existent recipients, and/or clamp down on emails where a single mail has too main receiver/cc addresses.

Given the situation described, I would contact the upstream mailer and have them look at the problem. If it turns out that they are the cause of it, they would also be able to tell you what to do.