One solution is to use VERPs, which let you track exactly what messages bounced. You can then write a handler for those bounced messages, which will do the right thing, and continue using your regular mailer to send. I think if you search for VERP you'll find some examples of how you might approach it in Perl.

One of the issues with sending directly to an MX is that many, many MX's will refuse your mail because it doesn't come from a "real" SMTP server. Implementing enough of an SMTP server to play nice with that type of MX would be non-trivial.

One thing I've had luck with to solve your bounce-detection problem is to add an X- header to the mailing list mails, and let bounces go to a real mailbox. I do this, today, all in Perl:

1. Change .forward file for the account listed in the From header, so that mail there will be delivered (instead of silently discarded).
2. Generate messages, tagging each with a common X-List-Message-ID: (in my case, a hash of the message body).
3. Enable a cron job (which runs a Perl script) that checks the mailbox for bounce responses (which I do by looking for the X-List-Message-ID header) over the next 72 hours, logs the mail addresses which bounced, and clears the message. This runs hourly.
4. The last run of the cron job from above resets the .forward file and shuts off the cron job until the next time I need them.

This has worked very well for me, and catches the majority of bounced addresses. I even have a process that follows up on the bounces a week or two later with a "just checking" message before removing the address from my list.

The main problem you'll run into when writing your own mail script will be how to handle all the different (possibly temporary) error conditions that exist. Examples of such errors are:

• The remote mail server is heavily loaded and your transmissions time out. You need to recover gracefully and try sending the mail at a later time (preferably after some time has passed to avoid congesting the remote server even more)
• The remote server uses greylisting and asks you to try again later
• The remote server does spam filtering in an odd way and refuses some of your mails, but not others
• Due to a temporary network problem almost none of your mail gets delivered on the first try. You need to write the mail out to a spool file, or else you memory fills up, the server crashes and all mails are lost.

As I said, just a few examples. There's way to code around all of these of course, but thankfully some very clever and diligent people have already written programs that do this. These programs are called mail servers :-) (or Mail Transfer Agents if you want to be precise). I'd recommend letting these specialist programs help you by doing what they do best, a little time spent carefully RTFMing on the MTA of your choice will surely pay off more than writing another one by yourself. As for logging, I'm partial to exim, which is very flexible in what it will log, the logs are easy to parse and you should be able to get all the information you need out of them without much effort.

Bounces were collected in a separate mailbox. The list was pretty clean so manual checking was acceptable. With things collected in the mailbox it should be easy to script.