Should Email Errors Keep Customers From Buying? describes a robust way to handle email in Java. The main point is very clear - don't leave a web visitor waiting while the application server attempts to send an email to them.

I am surprised this is even an issue in 2007. I suppose not everyone has gotten the message (no pun intended!) that OpenACS has used a background thread to deliver email for years. It uses a simple queue that attempts to save the messages, batch them up, and send them to a local SMTP server regularly. Usually, it is done at least every 5 mins or so, but that depends on how much email you are sending out.

I can't imagine it's that hard to run a local SMTP server in this modern age. It doesn't seem necessary to rewrite a SMTP server within Java instead of just running something like Postfix on the same box. Postfix will then make sure the email gets delivered to the intended recipient. 

The author is worried that we won't know which email had a problem, if it is ultimately rejected at the destination. I think this is such a rare occasion that a mail is rejected for reasons other than invalid recipient, that your time is better spent having someone respond to requests from users who have a problem, rather than building a huge infrastucture in your application server to mimic the functions of an SMTP server.

I agree with the author that tying up a connection thread sending email is a bad idea. I just think you can get carried away with abstracting the background delivery of mail if you are not careful and end up with a full MTA within your application.