Misc Tasks

[graemef]

I have finally got spamassassin running on our server, but some spam still comes through, even with a score higher than the 5. This is OK as I wanted to catch spam and isolate it in case something useful was wrongly tagged. What I wanted to know is whether is it possible to perform the following tasks on a server wide basis without the users having to do each mailbox.

1. Create a SPAM folder in all profiles
2. Create a server side rule that moves all emails with the spam flag in the header to the SPAM folder.
3. Delete all files in everyone's SPAM folder over 1 week old

any help would be appreciated.

Cheers

[mhanisch]

1. Create a SPAM folder in all profiles

2. Create a server side rule that moves all emails with the spam flag in the header to the SPAM folder.
3. Delete all files in everyone's SPAM folder over 1 week old

Any updates here yet?
I'm very interested in this, too.

Especially re. #1 - adding folders - I have not been able to find out how this
is done...

#2 should be possible using "sxaa" (from the admin resource kit), but I haven't tried it (yet).

#3 would be very helpful for me as well; in addition, I've been thinking about having spam assassin learn from the spam mails, i.e. using IMAP (or some other mechanism) to retrieve the "Spam" folder, then retrieving the Inbox folder (as "ham") and then invoking sa-learn... Anyone else who tried this?

[florian]

Well, at least some.

While there is no simple programmatic way of creating folders (other than using IMAP), you can just rely on server-based rules to do that; if a rule addresses a non-existing folder as the target of a copy or move, the folder will automatically be created. Rules can be created by manipulating the "3d" auto action file; sxaa can be seen as an example of how such stuff can be coded. An upcoming version of sxaa that our support team is currently working on will have the option to create file-to rules based on subject.

Deleting old stuff can usually be done using the omtidyu command. It can be applied to items over a certain age and located within a specified Top-level folder.

So yes.. will require some refinement, but i believe full automation of this is well possible in the powerful world of Scalix scripting.

Cheers,
Florian.

[mhanisch]

Hi Florian,
thanks for the quick reply!

While there is no simple programmatic way of creating folders (other than using IMAP), you can just rely on server-based rules to do that; if a rule addresses a non-existing folder as the target of a copy or move, the folder will automatically be created.

Ok, that's good enough for what I intend to do...

Rules can be created by manipulating the "3d" auto action file; sxaa can be seen as an example of how such stuff can be coded. An upcoming version of sxaa that our support team is currently working on will have the option to create file-to rules based on subject.

Then I'll use sxaa as an example and maybe factor out the code for parsing, so I can reuse it. (BTW, it would be nice if there were some published scripting API for accessing the "3d" file - that would probably also help to move some of the workload from the scalix team to the community, and would spare everyone the time involved to cut&paste from sxaa...)

That being said, if I read you correctly, I can only delete the emails in users' spam folder (using omtidyu etc.), but not access the folder contents and feed them back to spam-assassin.
To be able to access these emails from my program, I would either

• try to make all spam folders accessible to my program's "user" via IMAP
  (using delegation, or ACIs/ACLs or whatever)
  However, I'm not sure of this can be done, but it is worth looking into.
• write a web interface etc. for the user to allow them to invoke spam
  assassin on their own instead of just deleting these emails
  (because we need to get their authentication credentials to access the
  folder...)

I'm wondering if I'm the only one who wants to do this... Has anyone else implemented something similar he wants to share?

[florian]

Just a few further thoughts that might be helpful.

Then I'll use sxaa as an example and maybe factor out the code for parsing, so I can reuse it. (BTW, it would be nice if there were some published scripting API for accessing the "3d" file - that would probably also help to move some of the workload from the scalix team to the community, and would spare everyone the time involved to cut&paste from sxaa...)

Absolutely; we would love to do that; however, creating - and maintaining, documenting - such an API needs some resource on our side as well; at the same time you might know that our product was originally based on a very reliable and stable platform known as HP OpenMail; while this legacy is core to our enterprise-ready positioning in terms of scaleability and other good properties, we're also looking into changing a number of things from an architectural point of view, especially as standards in Internet world evolve. Part of that necessarily involves changing some of the background structures as well; the file format of the infamous "3d" file is called Transaction File format (TF) and is one of these core components; building an officially supported and public API for it would possibly involve having to provide compatibility in future releases - which is something we obviously want to avoid while planning for more major change.

Having said that, we're planning to provide further API access to our system in forthcoming releases and I believe you'll see the first elements of this sometime later this year.

That being said, if I read you correctly, I can only delete the emails in users' spam folder (using omtidyu etc.), but not access the folder contents and feed them back to spam-assassin.
To be able to access these emails from my program, I would either ...

That's correct, there is currently no programmatic access other than the ways mentioned to mailbox contents. Some pointers here:

* IMAP delegate access is currently not available yet. IMAP provides access to the user's own mailbox and the public folder structure. We will be providing IMAP-based delegate access in a future release.
* How ever, we will provide a way to login to *ANY* mailbox with IMAP through an Admin-level ("mboxadmin") user with the *next* Scalix release coming very soon (actually a few pre-release customers are putting their hands on this as we speak!). This can be used for the purpose listed; then, the Spam training data can be kept in user's private folders.
* Most commonly, such structures are currently implemented using public folders - which are accessible through normal IMAP - in combination with SpamAssassin's built-in training features; this has been done by a number of customers already.

Hope this is enough to get you going, tell us how it went![/list][/list]