JavaMail API and Postmaster undeliverable errors

Hi,

I was wondering if there is any kind of standard way to identify a bounced email (ie after sending to an address that doesn't exist)?

I am using JavaMail to read the incoming email, so I have access to all of the data stored - but programatially I am unsure what is the best option to identify these bounced emails.
Do all bounced emails have the "from" set to "[email protected]"?
Do all bounced emails have the "subject" set to "Delivery Status Notification (Failure)"?

Does anyone know of any standard way to detect these errors?

Since I need to handle these bounces (by flagging them, so I don't keep emailing invalid addresses), I want to make sure that the script I write will catch all of the errors from different mail servers.

Thanks
Michael

Unfortunately the answer to all of those questions is "No".

The script I have for capturing bounce messages has about a dozen different subject lines. And I haven't even attempted to extract the culprit e-mail address from the bounce message; the message formats vary even more widely than the subject lines do.

All you can do is to monitor the bounce messages as they come in, and modify your procedure to handle each different format as you encounter it.

However... there is a new e-mail feature called Delivery Status Notification. Here's a link to the part of the JavaMail API documentation which describes it: http://javamail.kenai.com/nonav/javadocs/com/sun/mail/dsn/package-summary.html. It comes with a Warning, and there's no guarantee that servers will send you these things, and so on and so on, but it might be worth experimenting with them.

I had a feeling that would be the answer

Just thought of an easy way I can do this on my system though...

Simply compare the "from" data in the incoming email, then cross reference this against the list of email addresses within the DB - if there is no match, it is safe to say that the email has bounced.

I can then forward all of the bounced emails content & headers to a certain email address, where I can begin looking at these on a case by case basis to see how I can extract the original "to" from the postmaster delivery failure.

Should keep me busy for a while :-)

Thanks
Michael

Hi, Did you find the way to do it?? I too have this requirement and cannot use IMAP or POP3 to read my mails.

abcdSiddharth tiwari wrote:Hi, Did you find the way to do it?? I too have this requirement and cannot use IMAP or POP3 to read my mails.

Welcome to the Ranch. After 13 years, it's unlikely Michael is still around to answer your question.

What does having this requirement have to do with POP/IMAP? And what's more, if not by POP/IMAP, how are you accessing the mails? I think those are pretty much the only mail receiving protocols JakartaMail understands.

Just to be picky, IMAP and POP are not "mail receiving protocols". They are the services that support access and control of the mail user's mailboxes. So the word I was struggling for was "mailbox protocols".

When a Mail Transfer Agent (MTA) receives an email, it delivers it to the user's account, to an inbox by defaulyy, although users can define post-delivery routing via facilities such as procmail.

More to the point, Internet Mail developed in a very untrustworthy environment. We tend to think of it as nearly instantaneous these days, by many MTA systems might actually only boot up and run for a limited amount of time. That will be illustrated by me probably this evening when Hurricane Milton starts taking down the electric services and my servers go offline, for hours or perhaps days. During that time, incoming email will bounce because there will be no server to receive it. So the sender will keep retrying for up to 4 days, typically, and only then will the upstream server return a delivery failed notice.

For the case when a recipient doesn't exist, the case may be even worse. I think the default for my system is to simply discard them so that spammers and bad actors cannot simply probe to see what accounts might be subvertable.

There is a "receipt notification requested" header that can be attached to email, and it's older than what Paul Clapham mentioned, but it's not guaranteed to work.

Beyond that, about the closest you can get would be to A) look for emails from "postmaster@" and B) check incoming mails to see if they have embedded content with a copy of your original mail (with your address in its "From:" header). Also look for "Re: xxxxxx" in the subject, where "xxxxxx" is the subject you sent the original email under.

I used the words IMAP and POP3 because to read the bounced mails coming back to me, i might need these. but since i am not allowed to use those i have to somehow log the SMTP responses in order to get the code for delivery.
Since i am using simple SMTP server and javax mail, i am getting mail delivered succesfully even for mails that are wrong. ex: [email protected].

I am still here.

When you send a message to an SMTP server, it will not reply that the message cannot be delivered. That isn't how SMTP was designed. You may later receive one of those bounce messages, but that is not guaranteed. Some servers may just ignore undeliverable messages.

Yeah. As I said, the upstream MTA will attempt to contact the destination MTA (smtp server), and just as with HTTP, it may or may not be able to connect and to send the email.

If it cannot, the upstream MTA holding the mail will try again in an hour or so and keep trying for a day or 3. Only then will it admit defeat and - possibly - notify the sender that the mail was undliverable.

Another note. While these days, an email MAY get sent straight from the sender's MTA to the recipient's MTA, that was not originally the case, and it wasn't guaranteed. An email could be stored and forwarded through intermediaries.

When you send an email via SMTP, the only SMTP acknowledgement you'll get is from YOUR MTA. So if your MTA is smtp.google.com, the only thing you'll know is that you managed to pass the mail to google.com (gmail), but as I said, if my receiving MTA is offline, that mail will be sitting in google's queues until I either come back online and can receive or google times out on send attempts.