This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

PureMessage feature request

Within PureMessage, although there is the option to scan for certain words or phrases etc, its not quite modular enough to allow us to allow certain usernames to be exempt.

As an example, we have a student user who's surname ends with shi, and his first initial is T... 2+2=this being quarantined in any reply. We also have a member of staff who has Gay in her surname. Again, this is frequently blocked. The words aren't particularly offensive in a sense that maybe we could allow it. But would it be possible to get a feature whereby words can be filtered; so the username "Ri**bleep**" or "Gayton" would be avoided?

I have already phoned support who gave me a few suggestions on how to only search for the full term "gay", but when the kids try to be clever: "youaregay" etc, then we still need to be filtering the phrase. Is there any way that an specific exception feature could be added? I don't know how the scanning agent behaves, but would there be potential to look for the "To:" header, then use a list of rules from there, making the rules more adaptable?

I'm not entirely sure I'm explaining my point very well, but would appreciate any feedback.

:1575


This thread was automatically locked due to age.
  • Why not exempt authenticated users from spam filtering/quarantining? That is what we do, and it avoids issues like this.
    :1580
  • In the staff case:

    We suffer from spam, so as part of our service, are required to block it.

    In the student case:

    We MUST have filtering in place

    :1585
  • RIght, but you can whitelist messages sent from authenticated users. If your own users are spamming, then lock their accounts.
    :1588
  • I will look into the whitelisting - though despite this, I still need the filtering in place. (This is where I think I failed to express my point). We do have staff users who are on an alert only policy to the filtering etc, but that was on request.

    If only blocking accounts was so simple. I don't know whether you can empathise with the situation, but if I block an account for misuse, I will be hounded to re-enable said account if it causes a problem for staff in a teaching room (they need to send an e-mail to the pupil etc).

    I'm looking for a middle ground - if at all possible. I am sure there is a work around to get this in place as it stand, though a more modular approach to policies is what I'd personally like to see. (though from the comments made so far, not important to others)

    I appreciate the response/feedback

    :1591
  • I've been tinkering with the "regular expressions" in the content filtering definitions.

    I can type in:

    • "sh*t" which is blocked throughout
    • "\bsh*t\b" which blocks as a word - so "bullsh*t" would be skipped for scanning (unless another expression was added)
    • "\bsh*T\b" blocks "sh*t" as a word - it does not work case sensitively

    Based on this - any replies to Rish*T will still be blocked, as we get the typical "geniuses" who will enter "ssh*t" thinking they're out-smarting the system. In our case, we'd rather block and release, rather than be accused of not preventing cyber-bullying.

    I have also, now, looked deeper into "Except when recipient is:", finding that as expected, as it uses AD, groups can be used for exceptions as well as individual users. The problem here (although a decent feature to have) is that its an all or nothing option. What I'm hoping to get is something along the lines off:

    • Create policy by user group/type
    • Drill down to each user of a policy to allow certain words for that user (or potentially an OU)
    • The possibility to deny words outside of the range of the policy.

    In essence, when I mentioned modular, I really did mean it! Some words that possibly aren't offensive, would be deemed offensive to others. It would be a small step to making everyone happy - if the option was there, I for one would use it very often.

    (EDIT: Oops... foul language used. Hoping this works now! Please not - "*" denotes "i")

    :1607