On Mon, Aug 23, 2010 at 5:07 PM, Daniel Ouellet <[email protected]> wrote: > One question here. Shouldn't the spamdb -t -a w.x.y.z when adding a trap > manually in the spamd database also removed any grey listing for the same > IP's? > > What happened is of in the same 4 hours window I manually add an IP to the > trap, but I also see source for that IP in the greg listing, they are not > removed and even if the trap entry is there, it will end up being white > listed regardless.
I had a similar issue but with the -d option to delete an offending spam source. Entry is GREY-listed and eventually WHITE-listed. Spam is detected in user inbox followed by an "urge" to remove the offender from the WHITE-list using `spamdb -d'. Guess what? Since it is in the GREY-list still, it is WHITE-listed w/in a minute. I offered a fairly simple patch to spamdb to remove all entries of argument (IP) back in 2008[1], but the idea was shutdown. That thread continues to give advice of using the -t -a options (like you are using), but as you have seen, and also pointed out in follow-up to the advice, the method is not as effective a initially thought. If the patch to -d option was accepted, following `spamdb -d IP' with either your `spamdb -t -a IP' or my current scheme of BLACK-listing the offenders would work like a charm. Alas... --patrick [1] http://marc.info/?l=openbsd-tech&m=121146640814228&w=2 > > example: > > # spamdb | grep 41.199.130.240 > GREY|41.199.130.240|ZGMTAVHVGN|<[email protected]>|<[email protected]>|1282601097|1282615497|1282615497|1|0 > # spamdb -t -a 41.199.130.240 > # spamdb | grep 41.199.130.240 > GREY|41.199.130.240|ZGMTAVHVGN|<[email protected]>|<[email protected]>|1282601097|1282615497|1282615497|1|0 > TRAPPED|41.199.130.240|1282694618 > > If I still receive retrial from that IP before the expiring time that should > be here for this example: > > # date -r 1282615497 > Mon Aug 23 22:04:57 EDT 2010 > > it will pass and being listed as white, even of the trap is pretty clear > that it should be trap until: > > # date -r 1282694618 > Tue Aug 24 20:03:38 EDT 2010 > > Is that really intended to be that way? I don't think so, but that's what is > going on. > > Any thoughts? > > Daniel
