the best way I know to deal with that problem is to recognize bounces
(not just by return-path but by message format) and to correlate them with
a Sent IMAP mailbox.
This is just another variant of including a cookie in outgoing email which
you check for in the bounces that come back.
Putting the cookie in the message data doesn't work in general because
many bounces are unparseable, or they don't include enough of the original
message. The extreme example of this is vacation messages which usually
include nothing of the original; also some bounces have extremely
abbreviated copies of the original header.
putting the cookie in return-path might work better. putting it elsewhere
in the envelope would be cleaner, but would require all MTAs in the path
to be upgraded before it became useful.
more ideally, return-paths would be authenticated (in the sense that the
sender needs to be able to demonstrate he has the right to use that
return-path), and MTAs wouldn't bounce messages that failed authentication.
This is the fallacy of universal deployment: you can't assume that
everyone will upgrade their systems to conform to best current practice,
so you can't rely on BCP to eliminate backscatter.
the usual trick is to try to arrange things so that those who do upgrade
their systems will see an immediate benefit - i.e. to put the incentives
in the right place. I think this would be true for RP authentication -
MTAs today see a substantial load from boucing forged mail.
Keith