No information you can collect from the SMTP-session or elsewhere can ever compete with the accuracy in notification gained if you reject the message in-line and leave the responsibility for sender-notification with the sending MTA.
On the other hand, sending the DSNs back to the sending MTA is not UBE because a 3rd party is not involved. Of course, the sending MTA may not accept incoming sessions and your queues may fill. But, if you record the MTA that passed you the message, then your post-processing applications have a right to send whatever notifications they want to that MTA owner. The MTA owner *IS* directly involved in the incident in question since the SMTP session originated on their server. The owner can take direct action to stop the virus transmissions by filtering, changing server config, stopping the source or setting up an ACL to block rogue mail servers on their network. This whole discussion centered around the fact that innocent 3rd parties with no ability to act, were being sent large volumes of notifications. Once you remove the innocent 3rd party from the equation, the shape of the problem is quite different. I agree that notices should not be sent to addresses that are likely to be forged because then innocent 3rd parties are being spammed. However that does not mean that all notifications are bad. --Michael Dillon