Hmm; Thanks for your feedback, Wietse!
I'm definitely new to mail serving and not an administrator. Would it be at all advisable to just scan the maillog file periodically for 'status=bounce' lines and parse out the 'to<...>' email address? It seems that'd give a pretty reasonable list of bounced emails. I don't need to be 100% accurate, just reasonably comprehensive. Marshall ________________________________ From: Wietse Venema <[email protected]> To: Postfix users <[email protected]> Sent: Thu, March 31, 2011 12:56:14 PM Subject: Re: example showing how to track bad/bounce emails marshall: > Hello; > > I've been searching around for a while, but I've not found any documentation > or > > examples that show how you can configure Postfix to log bad/bounce/failed >emails > > to MySQL or how to read a log file and parse the bad/bounce/failed emails out >of > > it. > > The application I'm working on needs to detect emails that bounce > and ideally remove them from the database. If Postfix can insert > the bounced emails into a db table (or a log file that just contains > the bad email addres, one per line), that would make it pretty > easy to run a cron job to remove these bad emails from the > application's user database. Postfix delivers mail; it does not parse bounce messages. You could use the documented Postfix hooks to deliver the returned mail to a command that parses out the failed recipient. - "|command" in local alias or .forward file: http://www.postfix.org/local.8.html. http://www.postfix.org/aliases.5.html. - Pipe-to-command daemon; this requires a per-user transprort map entry. http://www.postfix.org/pipe.8.html http://www.postfix.org/transport.5.html Bounce message parsing is not trivial because a lot of systems use a non-standard notification format. Using VERP solves some but not all of these problems (some mail systems ignore the envelope sender address). http://www.postfix.org/VERP_README.html Wietse
