== How we deal with the spam forwarding problem We have a spam forwarding problem. Specifically, we forward spam, although not through choice; it's a political mandate not to impose filtering on people, and some of the people who don't filter forward their email elsewhere, and [[predictable things ensue ForwardingDanger]]. We're dealing with this in three ways: * we use a different source IP address when forwarding [[spam-tagged email CSLabSpamFiltering]], splitting good email traffic away from the spam so we avoid contaminating the former with the latter. This is especially important for places where a bunch of users may be forwarding their email, like Yahoo and Hotmail; this way we avoid having a user that forwards a lot of spam cause problems for other users who mostly forward non-spam. * in order to eliminate as much backscatter as possible, we outright discard bounces of spam-tagged email. This is definitely not RFC compliant but is the lesser evil in a situation with no really good way out. (It also keeps our delivery queues small, since otherwise they would fill up with all of the bad addresses that spammers use.) * just in case, bounces go out from yet another source IP address, used only for bounces, so if we get blocked for being a backscatter source it will affect as little mail as possible. Our spam-forwarding source IP address has already shown up on a few email reputation systems, although I believe not in any of the public DNSbls. This doesn't bother me, because I can hardly blame anyone who blacklists it; it is pretty much a spam source. (Since I don't believe in tempting fate, it has an innocuous host name.)