You can generate email from your web application using the popular CFMAIL tag. This tag includes some very interesting features that let you get a better handle on the life cycle of your email after your call to CFMAIL.
By default, when you call CFMAIL email is not sent immediately, but instead queued in the background and managed intelligently as it is transfered to an upstream MTA agent (such as sendmail or postfix). You can control the amount of threads for this using the properties in the bluedragon.xml file.
Emails are first saved into the ./cfmail/spool/ folder. The call to CFMAIL will not return until the email has been saved in this folder. This ensures any server crashes will not lose any email.
The mail spooler will look for files in this folder periodically and attempt to deliver them. If it fails to do this, this mail file be moved to the ./cfmail/undelivered/ folder. You can look at the ./cfmail/mail.log for reasons as to why this occurred. You can have the email be resent (if you have resolved the problem) by simply copying the files from the ./cfmail/undelivered/ folder back into the ./cfmail/spool/ folder without having to restart the engine.
You can manage this life cycle from within CFML code by using the callback routines of CFMAIL to alert you when emails have been successfully passed to the MTA agent or have failed. You can get the path of the mail spool directory by calling the GetMailSpoolDirectory() function.
Due to the rich email capabilities of OpenBD, it is very easy to build an environment that has a lot of outgoing emails. However, during a development or staging phase, you may not wish emails to actually be sent to their original recipients, but instead to one or more test email boxes.
Naturally you could control this using CFIF blocks in your code for when you are in production or development. This can be somewhat troublesome and dangerous as you are relying on the developer to make sure they have caught all instances of outgoing email in the code base.
OpenBD realizes this can be a headache and has a feature to help with this. You can specify in the bluedragon.xml a list of email addresses that all CFMAIL tag calls will be redirected to. This is called catchemail.
You keep your CFMAIL code the exact same, but instead of being delivered to the emails specified there, they will instead be delivered to the email list specified in the catchemail block in the bluedragon.xml file. The original intended recipients will be placed in a series of headers in the email, x-openbd-to/x-openbd-cc/x-openbd-bcc, so you can see who would have gotton the email if the catchemail feature was not intended.
The logfile will still show the original recipients but will have an additional prefix to let you know that they didn't really get delivered there. Any CFC callbacks however, will still be for the original email addresses. This way you can keep your business logic as close to production as possible without any nasty hacks.