Business, Development
Comments Off Handling Bounced Emails in PHP
I’ve touched on this subject before, but I’m going to go more in-depth as I recently learned that I wasn’t fully handling bounced emails. The problem I run into is that there is no manual for properly running a website. You can read all you want about HTML, CSS, PHP, MySQL, but you’ll be hard-pressed to find good books and articles on how to run a website successfully. Do’s and dont’s. How to avoid problems. You have to learn piece-by-piece as you make mistakes.
Why Bounces are Important
As I’ve talked about before, it’s important to handle bounced emails because ISP’s and email providers use this information against you. If you send emails to invalid, expired, or spamtrap email addresses, you will be punished. Your emails will not be delivered with the regularity that you expect.
Two Types of Bounced Emails
I just learned, after more than 2 years of thinking I was properly handling bounced emails sent from my websites, that I was not handling the majority of bounced emails. This means that my websites are emailing mistyped, expired, and fake email addresses daily, without my knowledge. Technically, there are bounced emails and there are rejected emails.
#1 – Bounced Emails
I thought I was so smart when I first set up bounced email handing. I don’t recall where I read about how to do this in PHP, but what I read was that I first of all needed to add a return-path header to outgoing emails. This return-path header will contain a way for your site to discern who the intended recipient was. On my sites I formatted the return-path header as such, “user=domain.com@mywebsite.com”. I then have to set all emails coming to my website, that are addressed to a nonexistent address, to be sent to a new email inbox. Then, this inbox has to be “piped” to a specific PHP page. The PHP page reads all emails it receives, checking for this return-path header. It parses the header, converts it to properly formatted email address, and adds the email to a do-no-email table in the database. This is great, and needed, but bounced emails going to return-path addresses make up only a part of invalid or bounced email attempts. I guess, I don’t know for sure, but I assume that this type of bounce happens when an address is recently deleted, only. Addresses that simply never existed, or have been gone for some time, appear to not bounce in this way. Thanks SMTP geeks.
#2 – Rejected Emails
It would be too easy for the above to be the end-all way to handle bounces. In doing some research for why some ISP’s hate emails from FidoFinder.com, I was browsing through my SMTP email log for a specific day. I saw some 550 errors where I was attempting to email invalid email addresses. I wanted to verify that these addresses had been added to the do-not-email database table after this bounce, and none of them had. I then wrote a test page to email these same addresses. I added a line to my bounce PHP code to email me a copy of any email it received. I never got a bounce emails. After a short discussion with Rackspace in the support ticket I had open for getting a copy of that SMTP log file, something the tech said revealed to me that many times the server rejects the attempted email, and that this does not produce an email to the return-path address. Instead, the MTA, in this case Qmail, sends the sender a message telling him about the bounce. Everyone has received a similar email before. The problem was I had my outgoing website address set to simply delete all incoming mail, as it was a do-not-reply address that people were not supposed to send emails to. In order to read these reject messages I had to remove the setting to pipe all emails to NULL and now pipe these emails to my bounce script. I added some code to look for “Remote host said”, a common text in email rejection notices, and consider all emails with this line to be reject bounces. I then search for the return-path header, which is included as the part of the original email, and add this address to the do-not-email database table. Now we’re adding rejected addresses to the do-not-email table.
Conclusion
In the first day I had 10-15 rejected emails where I normally have 1 bounced email. This means I was barely just scratching the surface of handling bounced emails previously. Possibly the repeated attempt to send emails to nonexistent emails has been affecting Fido Finder’s delivery rate for years. That was the idea when I set up the first bounce rules. So hopefully cutting down the emailing of these rejected addresses will have a positive effect.