The sendmail virus/spam filter MailCorral redirects all received spam to the spam corral, instead of delivering it to the spammer's intended victim. All in all, not a bad plan but it is possible that a piece of spam could be valuable (stranger things have happened) or even that a non-spam message be misidentified as spam and corralled by mistake. The spam handling programs in this package make dealing with spam simple and easy.
The ultimate decision, about whether a piece of spam is valuable or not, is best left up to the intended recipient. After all, they are really the only ones who know whether they actually want so see the spammer's message or not. But, if the recipient is shown every piece of spam and asked to make a decision about whether they want to see it or not, the solution is no better than the problem. The compromise solution is to only ask them once or twice a day, in a single message, and to provide a summary that contains sufficient information to allow them to decide, quickly and easily, whether they want to see the spam or not.
To accomplish this goal, this package, called SpamCorral, provides a notification program which can be run periodically by a cron job, whereupon it will send email notification messages to all of the recipients of spam. It summarizes each of the messages received since the last time it was run, giving the sender's address, the subject, the delivery date/time and the associated spam statistics (as a percentage, with 100% being the threshold for classification of a message as spam).
When a user receives the notification, they can optionally reply to the message (using their mailer's reply function), choosing any pieces of spam which they wish to see and the chosen messages will be remailed to them, this time passing through the filter unscathed. The action is simple and natural, in that it is just like replying to any other piece of email that they receive.
Meanwhile, a second program in this package, the spam handling robot, listens for messages sent to it, as result of the user replying to any notification messages. Each message sent to it is a request for a piece of spam to be extracted from the mail corral and remailed to the original recipient. Upon verification of the sender's right to remail the spam, the corralled message will be remailed to the user but, this time, they will pass directly through the sendmail filter unscathed.
The operation of the spam handlers is automatic and unattended. They simply respond to requests from the users to remail all of the spam that they ask to see. No intervention by administrative personnel is required. Furthermore, no important or interesting messages are ever dropped by accident. The recipient has final say in all decisions.
Notification program: the notification program is run, at whatever interval you decide is appropriate, by cron. It notifies the recipients of spam in the corral. All new spam messages, since the last time it was run, are accumulated into a single notification message for each user. The message contains a few descriptive paragraphs telling them how to release their spam for remailing. Following that, there is a summary block for each piece of pending spam. The notification messages are mailed with a return address pointing to the spam handling robot.
Spam handling robot: if a user wishes to have their spam remailed to them, they reply to the notification message. The spam handling robot receives this reply and processes it (it is invoked by a ".forward" file in its own home directory). For each spam message that the user wants to see, the message is removed from the corral and remailed to them. A special header tag in the message tells the filter not to process the message the second time around, since it has already been processed. This allows the message to be delivered directly and takes advantage of the fact that virus filtering was already done the first time, when the message was originally received. At this stage, the spam is also deleted from the corral, since it has now been delivered.