Implement spamassassin support

[fajfer]

via #61

Spamassasin should run on it's own container and on OTRS there should be only the code and env vars to enable this feature.

I'm currently having it working somehow on a test environment, I declared to tidy my setup up and then send a pull request reflecting this functionality

[juanluisbaptiste]

Hi,

Cool, I will look into it when you send the PR. Just as a side note, IMO the spamassasin image should be separate of this project, and the PR should contain the needed modifications to OTRS startup script and docker-compose files to use it only.

[fajfer]

Sure, we're exactly on the same page, don't want the project to get bloated by something like this - that's why I'm talking about support not the spamassassin itself.

[Tendanf]

Hello,
I've battled with OTRS+spamassassin for a while, but haven't managed to find a solution that'd work without adding anything to the OTRS image. I've tried using docker client + docker.sock inside otrs to call docker daemon and then onto the Spamassassin binary, but that seems to be a bit heavy handed solution. There's also the option of image inheritance, but I'm not sure if this is the way. Do you perhaps have any ideas how to make OTRS run on the spamassassin binary despite it being on a different container?

[fajfer]

Haven't really found a good idea to execute Spamassassin without tinkering with the image itself this given how OTRS does this:
/usr/bin/spamassassin | grep -i "X-Spam-Status: yes"
@juanluisbaptiste this is a good point, do you have any suggestions?

[juanluisbaptiste]

I'm sorry I missed this !

What about mounting the OTRS container volumes into the spamassassin container ? that would give that container access to the same data and could do any operation on it.

[fajfer]

He's referencing the built-in spamassassin support from the OTRS. It runs the SA binary from within a local folder - hence the question on how we should proceed without getting the binary inside the image.

Mounting the OTRS volume for SA container would be require us to ignore the intended approach (running the binary), which could be misleading to some (might be just a minor problem) and require us to examine the messages for X-Spam headers so we could act accordingly. This would work only on POP3 and, unless I'm mistaken, require some ready-to-use rules on the image already (configurable via env vars?). Maybe a readme do the latter.

I'm unsure about the usage statistics but we could also (instead?) do isbg (Imap Spam Be Gone) as well. It might not require much more work and would be better for smaller installations.

We could go for this approach with SA container accessing the emails. I just would need to get back to this and try mimicking the approach here:

---
CMD: '/usr/bin/spamassassin | grep -i "X-Spam-Status: yes"'
Module: Kernel::System::PostMaster::Filter::CMD
Set:
  X-OTRS-Queue: spam
  
---
CMD: '/usr/bin/spamassassin | grep -i "X-Spam-Status: yes"'
Module: Kernel::System::PostMaster::Filter::CMD
Set:
  X-OTRS-Ignore: yes

I don't really feel like an OTRS guru but I think it should be doable with PostMaster filter after SA has successfully tagged the email. I need to check if it's not providing any overhead and if it actually works that way.

[juanluisbaptiste]

I was talking from complete ignorance on the matter. I thought SA was always run as an external process that would classify emails and put spam in a separate email queue or delete them so OTRS would only receive the non spam email, not OTRS do the classification by it self using the SA binary.

I still think that is the way to go, email processing and OTRS should be separated duties. If you have more services that also receive email you should centralize the spam processing in one place instead of letting each of those services handle the task for themselves.