Redirect by subject

[simonwelch]

We have a anti-spam service that sometimes marks suspected spam with a new subject header e.g. **Suspected SPAM** but the message is delivered to the indtended recipient. Is there a way that this can be redirected to an administrators address? Therefore the original recipient doesn't receive the suspected message but neither is the message discarded. I have looked at the rules that can be applied to the service router but this just seems to give the options to defer, reject etc. Also it seems that sxaa can only be applied to individual users.

This would be a temporary measure until our banned word list etc. is settled and would allow access to genuine emails. Using Scalix 10, RHEL 4.

Regards

Simon

[Valerion]

You will have to create this for individual users. Both the web interface and Outlook rules wizard allows for better granularity than sxaa.

One way to automate this is to do this for yourself (create a redirect rule), then copy your user's 3d file to all the other users' user directories. That will let them lose all their current rules, though.

Alternatively you can edit each of the 3d files you want to preserve with tf.browse.

Or you can read through sxaa and see how to write rules, then write your own script to automate this. Or run sxaa in a loop.

[ScalixSupport]

Both the web interface and Outlook rules wizard allows for better granularity than sxaa.

I'm always looking for feedback on what to add to sxaa. Can you explain more about the granularity ? Bear in mind that I don't plan to add an "all users" feature as this is a simple loop via omshowu -m all so I figure that I can make better use of my time by adding other features.

Cheers

Dave

[Valerion]

Dave,

I think I wasn't clear here :) With granularity I meant what you can do with a rule. sxaa seems to be aimed at the kind of action you'd want to do with every email (forward all mails to my cellphone, irrespective of wher they come from, falls in here). The other two wizards (Web and Outlook), seems to be aimed at detailed mailbox management (forward all mails from "Scalix Support" to my cellphone, and discard all messages from yahoo.com addresses).

In this case I believed he was trying to do detailed mailbox management, instead of just working with everything, which is why I stated it that way.

Of course, if you can build that level of detailed management capability into sxaa, you'd be one of my favorite people ever :)

[ScalixSupport]

Dave,

I think I wasn't clear here :) With granularity I meant what you can do with a rule. sxaa seems to be aimed at the kind of action you'd want to do with every email (forward all mails to my cellphone, irrespective of wher they come from, falls in here). The other two wizards (Web and Outlook), seems to be aimed at detailed mailbox management (forward all mails from "Scalix Support" to my cellphone, and discard all messages from yahoo.com addresses).

In this case I believed he was trying to do detailed mailbox management, instead of just working with everything, which is why I stated it that way.

Of course, if you can build that level of detailed management capability into sxaa, you'd be one of my favorite people ever :)

Currently, sxaa has the following conditions available to use (from the readme) :

Code: Select all

Specifying Conditions
---------------------
It is also possible to specify a simple condition to apply to a rule. There are a number of possible conditions: --subject, --sender, --header and --itemclass.

    sxaa --user user --file "foldername" --subject "SPAM"
    sxaa --user user --file "foldername" --sender "dave@scalix.com"
    sxaa --user user --file "foldername" --header "X-Spam-Status:***"
    sxaa --user user --file "foldername" --itemclass "IPM.Schedule"


It's a thin line that we walk trying to get the product to meet everyone's needs and, inevitably, we end up disappointing people.

sxaa was written to handle the majority of the cases where simple rules management was required by the administrator and no password was required. When I introduced conditions to the script, I did think about adding a parser so that unlimited conditions could be entered but I decided against it because the tool is meant to be straightforward and can be used with command line parameters. So, based on the feedback from the field engineers that have spoken with customers, I added the most requested general conditions.

Cheers

Dave

[Valerion]

It's a thin line that we walk trying to get the product to meet everyone's needs and, inevitably, we end up disappointing people.

Oh, don't get me wrong, I think sxaa is a great tool as it is now. And I see it has evolved a lot since the early days. I believe it will become even better over time, like many of Scalix's components.

I am not in the least disappointed with it, having a tool with that kind of abilities by itself has been useful time and again.

One request I do have, though, is to roll sxaa into the Scalix distribution in /opt/scalix/bin (or maybe adm?) I don't see it as a script that's going to be modified by the end users a lot, or as an example/rarely-used/special-purpose tool, like many of the tools in the Admin Resource Kit, but a fully-fledged component of Scalix.