I sent a message there. Can you check?
Yep; it retrained.
It's not a simulated environment here, just a pilot project, and I'm not
usually careless, but I have clearly overlooked this problem so maybe I am.
If you have, then send more info:
- What MTA
- What version of DSPAM
- etc...
There's a production mail feed gateway -> crap filter -> exchange
I've done redirects for a pilot group of users
gateway -----------> crap filter ------> exchange
| ^
---> postfix -> dspam -> postfix---|
I'll skip the extra details because it's not up to me to give them out; and
more importantly, I don't need that level of help, I was just struck that the
problem which was dismissed by you and Tony as being an edge case is probably
very common.
Essentially I need to make sure that external people can't send to the training
addresses, which is easy enough to do.
It's not so easy to stop staff from poisoning each other's spam databases, but
I really don't think it'll be a problem.
I suppose the neatest solution for my particular problem is to strip any
line with !DSPAM:[0-9]*,.{22,22}! (or whatever...) on the way in or out of
the building, but that doesn't stop users from messing with it internally
(internal mail is all within exchange and I can't touch it).
This would be security through obscurity and this mostly does not work. Better
would be to make a profound and solid setup.
I take it from this you mean that the signature data is obscured; in which case
I agree.
Perhaps however it's a storm in a teacup. The worst case scenario is that
we either restore the db from a backup or just reset the training and
start again. This doesn't seem too serious really; have I missed the point?
--
Daniel Rose
National Library of Australia
