I've asked for more details, but I'm going to bite here:
For most Web applications/sites I setup that need to send mail (and again, this isn't necessarily the best way to scale, but my stuff is usually low-load with < 100 concurrent users), I use Postfix on the same box as Apache/PHP.
Because I'm usually dealing with a domain that already has MX records and an authoritative mail server somewhere else, I'll either relay it through that authoritative mail server as a smarthost (usually the easiest method) or set it to send outbound only directly and make sure that the SPF records are updated accordingly and that the public IP address I'm (usually) NAT'ing out as has reverse DNS setup.
If you do end up sending it directly, make sure your banner that's displayed from Postfix has mail.yourdomain.com and that you have an A record setup that resolves to the public IP that Postfix is listening on. This shouldn't be necessary, but there's alot of odd anti-spam vigilance out there. I'd also setup [email protected] and [email protected] as well; these can be aliases/forwarders to your real email address, but again, I've seen some mail servers try to reconnect and issue a rcpt to
from the address that mail is sent as in the header and if it doesn't exist, you'll be black/graylisted.
If you don't have an authoritative mail server, you could setup Postfix and Dovecot for IMAP support, but you'll likely have an easier/more reliable experience setting up Google Apps for your Domain for free and relaying mail off of their servers. As long as you don't plan on sending massive amounts of mail, this works really well and gives you a nice interface for adding email addresses.
Note: I'm finding that increasingly receiving mail servers/anti-spam configurations are setup to drop SMTP traffic originating from Amazon's EC2 block and other commodity hosting providers (HostGator, Dreamhost, etc.), so again, setting up a secure relay to your authoritative mail server is likely the best option.