I've decided to take a step back from the Nessie code for a bit and consider the architecture of the system. At the current rate, I've coded myself in to a corner, back tracked, tried again, and coded myself into another corner. The system has gotten too large and complex for me to keep straight and I've found myself trying to get tests to pass by simply hacking away at code. I think some better organization and a clear architectural goal could be of help here. The chart below is my first graphical concept of how I think the architecture should work. There are some areas which lack detail, but I think it's enough to start restructuring the code a bit. Hopefully, in doing so, the missing details will become more apparent and I can then add them to the chart.
Not so long ago, I ran a wiki called SecurePHP. On that wiki, there was one particular article about email injection that received a lot of attention. Naturally, with all the attention came lots of spam. As a result, I disabled editing of the wiki and content stagnated. Still, the email injection article remained popular. About a year later, the server that hosted SecurePHP died and I never had a chance to hook it all back up. I saved the article though and I'm reposting it now. It may be a bit old (I've been away from PHP for a long time), and I didn't write all of it, so feel free to leave comments about needed updates and corrections. Though this article focuses on PHP, it provides a lot of general information regarding email injection attacks. The PHP mail() Function There are a lot of ways to send anonymous emails, some use it to mass mail, some use it to spoof identity, and some (a few) use it to send email anonymously. Usually a web mailform using the mail() funct