Good point. That's why I favor giving users access to their spam pool
when they suspect problems, and using challenge/response in certain
(carefully defined) situations.
A good filtering mechanism is not nearly as black and white as a blacklist.
so, you're conflating two things here:
1) the access control criteria (message source address in blacklist
vs. "bad" message content as determined by various heuristics).
2) what happens to the message once the access control decision is
made (rejected at SMTP layer; accepted but bitbucketed; accepted but
quarantined; accepted and placed in regular mailbox; etc.).
you can (and spamassassin does) uses DNSBL's as part of a "not black
and white" decision process, and you can implement both strategies.
One problem with dropping suspected spam into a spam cesspool as
opposed to rejecting it outright in the SMTP session is that many
people (myself included) have neither the time nor the inclination to
wade through our spam cesspools on a regular basis looking for
An SMTP-level reject at least gives the sender a real-time indication
that the recipient will not be seeing the message any time soon..