The spam forwarding problem is that when users forward their email to somewhere else, they forward their spam too. Since we have a spam tagging system, we'd like our users to not forward spam-tagged email; at the same time, we can't mandate this as an absolute requirement (and thus implement it centrally in the mailer).

You can certainly do this with procmail; selective forwarding is one of the things that procmail is good at. But there's two problems, one smallish and one big. The smallish problem is that this is not really forwarding, it's remailing. The big one is that using procmail for this is awfully complicated.

As it happens, I'm a big fan of making the right way also be the easy way. The easy way to do forwarding is to put an address in .forward; if we wanted it to be just as easy to forward only non-tagged email, we needed a .forward that only forwarded non-tagged email. So that's what we created in our mailer setup.

.forward-nonspam is just like .forward, but it only sees messages that aren't tagged as spam (or viruses) by our spam tagging system. If you also have a .forward, the .forward sees only spam-tagged email. If you only have a .forward-nonspam, spam-tagged email is quietly discarded into /dev/null because this is the common case (and it's certainly what we want to happen by default).

While we were nervous about adding non-standard .forward processing, I think that implementing .forward-nonspam has been a clear win in a whole bunch of ways. It's given us a very simple thing to suggest to users when we ask them to consider forwarding only untagged email (and many of them take us up on it, perhaps because it's so easy to do). It's even simplified some of our own .forward use.

(For technical reasons that don't fit within the margins of this entry, it's not quite easily useful for the case of 'put all non-spam stuff in my regular inbox and all spam stuff into a file that I can look at every so often if I want to'.)