I'm looking for ways to programmatically keep of email sending failures that occur at our local mail server while it tries to deliver to the remote mail server.
Our web application sends emails based on activity at the site, e.g. someone replies to your forum message or makes a change to something so we send an email. For each email we create an entry in our dB which contains details of the message including a UUID we generate which is used for unsubscription purposes (it's purged on a semi-regular basis so it's never enormous). The same dB entry also includes a "status" of sorts for that mail, such as that we've generated the mail, we've handed it off to our mail server, our mail server rejected or accepted it (example grossly invalid address that we miss in our validation logic will throw exception we log that in the dB).
If the status shows an issue we flag the user at the next login that we had problems sending them a message and ask they check their email address.
We're using JavaX Transport to send mail now (server runs locally with the web application) and while we can capture the errors trying to build and hand off the message, we have no way to programmatically track the status of the message once it's out of our hands and in mail server's.
While we of course realize we can't track it once it's handed to the remote mail server, we'd like at the very least to understand when a message bounces or is delayed--for example our mail server is told by remote mail server that the destination mailbox doesn't exist, or is full, or won't accept our mail, or perhaps our mail server can't resolve the hostname due to some typo that wouldn't been caught by validation logic earlier, etc... we'd use the same status in the dB as a way to alert the user at their next login.
We're using postfix for mail, it seems like it generates its own unique identifier for mail which is listed in the logs, is there some way to get that identifier returned to our code as part of the sendMessage process? At least then we could store it in our dB and have a separate process scour the mail logs looking for failures and update our dB accordingly.
I'm green when it comes to mail, so I'd appreciate any ideas or direction that may be different from what I've suggested.
Our user base are not technology savvy at all, they use our web app because they must, but we frequently have typos in domain names or user names which are perfectly valid syntax but are invalid, often times a user will be using the system for weeks before something happens and they say "I never got any emails!!", so 90% of these frustrating moments could probably be caught early if only we could relay back to the user what our mail server sees whenever it tries to deliver the message.
My pie came with a little toothpic holding up this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth