Email Bounce Processing
I'm designing the user registration system for a new website. To get me going in the right direction, I want advice on a specific part of this system: detecting bounced confirmation emails.
This website will be running on a virtual hosting account that has a cPanel-type installation.
Here is my plan so far:
Write a PHP script that is run nightly by crontab. This PHP script connects to the POP or IMAP account where bounces would be received, and reads all messages. For each message, the script searches for an email address inside < > brackets near the top of the message body. The script also looks for the confirmation code that was included in the original message. If such a message is positively identified, the pending registration would be cleaned out of the database.
Things I am concerned about:
I am sending out the confirmation mails using PHP and the localhost SMTP server. Can I assume that the SMTP server will accept all mails and any errors would be received as bounces? If not, which SMTP errors should I look for? (for example, would a malformed TO: address generate a bounce, or an SMTP error instead?)
The POP or IMAP account for bounces is probably going to receive non-bounce mails sooner or later. What can I do to ensure that most bounces are handled, and most spam is ignored?
Do email bounces always include the original message's body? If not, what is the best way to authenticate incoming bounces? Obviously, I do not want to blindly delete user accounts based on incoming emails. If this procedure gets implemented in other ways (newsletters, for example), then I need to know what risks are involved in automatic bounce processing, generally.
Also, I've seen information about forwarding mail directly to a PHP script. This sounds cool but seems impractical in a virtual host account because I think the CGI version of PHP is running the crons. I think. :)
Guidance greatly appreciated.
This website will be running on a virtual hosting account that has a cPanel-type installation.
Here is my plan so far:
Write a PHP script that is run nightly by crontab. This PHP script connects to the POP or IMAP account where bounces would be received, and reads all messages. For each message, the script searches for an email address inside < > brackets near the top of the message body. The script also looks for the confirmation code that was included in the original message. If such a message is positively identified, the pending registration would be cleaned out of the database.
Things I am concerned about:
I am sending out the confirmation mails using PHP and the localhost SMTP server. Can I assume that the SMTP server will accept all mails and any errors would be received as bounces? If not, which SMTP errors should I look for? (for example, would a malformed TO: address generate a bounce, or an SMTP error instead?)
The POP or IMAP account for bounces is probably going to receive non-bounce mails sooner or later. What can I do to ensure that most bounces are handled, and most spam is ignored?
Do email bounces always include the original message's body? If not, what is the best way to authenticate incoming bounces? Obviously, I do not want to blindly delete user accounts based on incoming emails. If this procedure gets implemented in other ways (newsletters, for example), then I need to know what risks are involved in automatic bounce processing, generally.
Also, I've seen information about forwarding mail directly to a PHP script. This sounds cool but seems impractical in a virtual host account because I think the CGI version of PHP is running the crons. I think. :)
Guidance greatly appreciated.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
cracky,
I guess you answered Part II of my question. I need to be certain that writing this script will be time effective before I commit to it. I will consider as a serious alternative requiring registration confirmation within 24 hours. This would allow me to clean the database of any old registration attempts regardless of the email validity.
As far as this G-Lock program goes, it is not an option for me because the website is hosted from a Unix virtual server. Having a Windows machine involved would be highly impractical.
I am hoping experts will still comment on the other parts of my question.
Thanks,
-- Miqro
I guess you answered Part II of my question. I need to be certain that writing this script will be time effective before I commit to it. I will consider as a serious alternative requiring registration confirmation within 24 hours. This would allow me to clean the database of any old registration attempts regardless of the email validity.
As far as this G-Lock program goes, it is not an option for me because the website is hosted from a Unix virtual server. Having a Windows machine involved would be highly impractical.
I am hoping experts will still comment on the other parts of my question.
Thanks,
-- Miqro
> Having a Windows machine involved would be highly impractical.
Note that this does not need to be a server, but I understand what you mean. We just use a crappy little Windows box to run the program just in the office and FreeBSD for our servers.
I do not believe that writing this script yourself would be time effective. That's just my opinion though. Just looking at the number of rules GEP uses to catch all different bounce headers and types will show you that bounces are not consistent in their appearance, so you would need long periods of trial and error to come up with a similar set of rules. Of course, you could copy GEP's rules, but I don't endorse that. Unless, you pay for a license and ask them if you could use their rules in your own regexp app.
If the purpose of bounce handling is simply to make sure people are who they say they are, then the double opt-in method would be the best. You should probably use double opt-in anyway to make sure your system is not being abused.
Note that this does not need to be a server, but I understand what you mean. We just use a crappy little Windows box to run the program just in the office and FreeBSD for our servers.
I do not believe that writing this script yourself would be time effective. That's just my opinion though. Just looking at the number of rules GEP uses to catch all different bounce headers and types will show you that bounces are not consistent in their appearance, so you would need long periods of trial and error to come up with a similar set of rules. Of course, you could copy GEP's rules, but I don't endorse that. Unless, you pay for a license and ask them if you could use their rules in your own regexp app.
If the purpose of bounce handling is simply to make sure people are who they say they are, then the double opt-in method would be the best. You should probably use double opt-in anyway to make sure your system is not being abused.
ASKER
Regarding Part I of the question: I determined through testing that my internal mail server will generate bounces for most commercial domains (aol.com, hotmail.com, yahoo.com) and also for SMTP errors such as unrouteable domains. This gives me new hope, since the majority of bounces will be in a predicatble format with headers and body intact.
ASKER
This answers Part IV of my question: http://www.evolt.org/article/Incoming_Mail_and_PHP/18/27914/
I'm still looking for comments on the security issues involved. What should I expect in the way of bounces from other servers, and in fake bounces?
I'm still looking for comments on the security issues involved. What should I expect in the way of bounces from other servers, and in fake bounces?
ASKER
Well, that's what I get for asking email questions in the PHP section :p
You can specify "Return-Path" in mail() header to get the bounced emails...
S: