Possibility of using remote SpamAssassin (spamd) instead of embedded one

[ramank775]

Thank you so much @mpaperno for your effort to create this amazing package!

I am exploring possibility to use SpamAssassin running on the remote server via spamd to be used along with the spampd.

To give more context, inspired by Mail-In-A-Box Architecture i have created a similar setup but docker based. Where spampd sits between the postfix and dovecot, analyse incoming mail for spam detection.

One of the problem i have faced using this architecture begin based on the docker, it loose the ability to train spam-assassin using sa-learn. While exploring for the solution i come across spamd. so i am currently exploring this possibility.

Based on the my understanding:

if we replace the Mail::SpamAssassin with Mail::SpamAssassin::Client and mades these following changes it should work

• Change initialisation of assassin

- $sa_p = Mail::SpamAssassin->new($sa_p);
+ $sa_p = Mail::SpamAssassin::Client->new($sa_p);

-  $spd_p->{sa_awl} and eval {
-    require Mail::SpamAssassin::DBBasedAddrList;
-    # create a factory for the persistent address list
-    my $addrlistfactory = Mail::SpamAssassin::DBBasedAddrList->new();
-    $sa_p->set_persistent_address_list_factory($addrlistfactory);
-  };
-
-  $sa_p->compile_now(!!$sa_p->{userprefs_filename});

• Instead of parsing the messages, pass it directly to check function

-    # Audit the message
-    if ($prop->{sa_version} >= 3) {
-      $mail = $assassin->parse(\@msglines, 0);
-      undef @msglines;  #clear some memory-- this screws up SA < v3
-    }
-    elsif ($prop->{sa_version} >= 2.70) {
-      $mail = Mail::SpamAssassin::MsgParser->parse(\@msglines);
-    }
-    else {
-      $mail = Mail::SpamAssassin::NoMailAudit->new(data => \@msglines);
-    }
-
-   # Check spamminess (returns Mail::SpamAssassin:PerMsgStatus object)
-    my $status = $assassin->check($mail);
+   my $status = $assassin->check(\@msglines);

• Change the default assassin options of client instead of spamassassin. Or we can add a flag weather to start spampd with remote SpamAssassin or embedded.

Is these approach make sense to you? if so i would like to raise a PR so the same although being a someone who never uses perl i understand it may be time consuming for you to review it.

[mpaperno]

Hi Raman, thanks for your interest!

So you're saying that just by invoking SpamAssassin::Client->new() there (and the other changes you show), it can work as a spamd client?

I'm guessing at least some options passed to Client->new() need to be different at least? This is kinda vague... https://spamassassin.apache.org/full/4.0.x/doc/Mail_SpamAssassin_Client.html

Also the return value from Client->check() is pretty different... we can't use it to rewrite the message, ASAICT.
SA->check() returns a Mail::SpamAssassin::PerMsgStatus object. https://spamassassin.apache.org/full/4.0.x/doc/Mail_SpamAssassin.html

If you think this would be useful, I'm open to seeing what some working code would look like. Any changes to SpamPD definitely need to keep all existing functionality, so this new feature would have to be behind some options. If you're up for it, a PR would be good, even if we end up tweaking it together.

My concern is that it may further (over)complicate the code and add yet more options to the current plethora. But maybe it's simpler that I'm thinking. Other option may be to create a forked/specialized version of SpamPD for this specific use ("SpamDPD?" :-) ).

I should also mention that I'm not currently using SpamPD for anything myself, and I'm not really up to speed with current versions, etc. In fact thanks to your post I just found out that SA 4 has been out for 2 years, and I have no idea if SpamPD works with it! So, caveat emptor.

Cheers,
-Max

[ramank775]

Hi Max,

i'll try to make changes and get back to you with a working code as soon as possible.

[ramank775]

Hi Max,
I have done the changes required to support remote spamassassin. It seem to be working fine with both embedded spamassassin as earlier as well as with remote spamd.

I have added new cli argument to use remote spamd

--[no]saclient    Weather to use remote spam assassin or not
-- sa-host           Address of remote spam assassin instance
--sa-port
--sa-socketpath  Unix socket path
--username

In order to abstract out the spam checking process, i have abstracted out by creating a new function audit which will return a standard response irrespective to which spamassassin is used.

Please review the PR whenever possible for you.
Thank you