Anyone who has ever received postmaster or (worse) AOL feedback loop complaints is familiar with the problem of lusers using the "Junk" button for "Delete."
If you have a moderate population of students reporting every email that certain college officials send to the "all students" mailing list as Junk, then eventually, you have a problem. I need some help on some components of a possible solution (which, alas, does not involved disciplining certain college officials as to the responsible use of bulk email).
Under the Zimbra hood, currently:
When someone hits the "Junk" button, the email is forwarded as an attachment to the spam.* account created upon server installation. A nightly cron job uses that account's INBOX as a corpus for training spamassassin's bayes database.
I encourage you to "View Mail" for your spam user. You might be surprised how much nonspam is being reported as spam.
Vision for possible improvement:
1) When someone sends an email to spam.*, we shunt the mail into a "manual review" mailbox, and autoreply with a pointer to a web page with a "So you want to help us by reporting Junk Mail?" web site.
2) We use the web site to educate the user about how to opt out of "official" mailing lists, how to squelch junk mail from commonly complained-about sites including Facebook, Abercrombie, and Amazon, etc. And then we welcome their feedback about actual unsolicited bulk email.
3) They agree. They are added to the spam.* user's Contacts.
4) A filter in the spam.* account allows email from their Contacts, and only email from their Contacts, to get through to INBOX.
1) Where exactly does the built-in vacation functionality hook in? Is it possible to write a sieve filter that vacation-replies only under some circumstances? The other obvious thing that people might want is to send vacation autoreplies only to one's contacts or local domain. Makes no sense to send a vacation autoreply to a spammer or a burglar.
2) Hmm, I guess I only have one question. General comments about this scheme?