mpaperno / spampd

SpamPD - Spam Proxy Daemon. A spam-filtering SMTP/LMTP proxy server using SpamAssassin in Perl. Since 2002.
GNU General Public License v3.0
34 stars 10 forks source link

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

Open ramank775 opened 2 weeks ago

ramank775 commented 2 weeks ago

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

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 commented 2 weeks ago

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 commented 1 week ago

Hi Max,

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

ramank775 commented 2 days ago

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