Disable plugin

[pjebs]

Is there a way to dynamically disable/enable the spamassassin plugin.

Let's assume hypothetically I want the spamassassin plugin to only run 50% of the time. (In my actual case it's based on an entry in a database for a particular user).

[smfreegard]

No - you'd have to copy it your your $HARAKA_INSTALL/plugins directory and modify it as necessary to do that.

Also note that post-DATA plugins like SpamAssassin are more difficult to disable by user because you might have multiple recipients and in that case if you disable it for one - you disable it for all, so you have to account for that scenario.

[pjebs]

Could you explain the final paragraph please.

My use case is I am creating an email forwarder. The user can register an alias for forwarding. i.e xyz@[my-domain.com] ---> their@real.email.to.forward.to.com

The user also sets if they want spamassassin to run before the forwarding takes place. (i.e. if it's detected as spam, then it gets dropped and doesn't get forwarded).

[pjebs]

There's an enhancement for v3

[smfreegard]

Sure:

Let me illustrate the issue - here's a typical SMTP transaction:

EHLO mail.foo.bar.com MAIL FROM:blah@foo.bar.com RCPT TO:rcpt1@company.com <---- This recipient wants SpamAssassin to be run RCPT TO:rcpt2@company.com <----- This recipient DOES NOT want SpamAssassin to be run DATA .... data here .... .

At this point the data_post hooks will run, but you have two recipients that have conflicting requirements. The problem comes when SpamAssassin wants to reject the message because it scored too highly.

At that point you can only reject, defer or accept the message to ALL recipients.

There are some workarounds for this:

1) At RCPT TO - once you've accepted the first recipient, DENYSOFT (defer) any other recipients which have conflicting preferences (this is what I do here). The sending host will then retry the deferred recipients again later. This method causes delays to some of the recipients.

2) In the example above - if SpamAssassin was going to reject the message, then you could remove rcpt1@company.com from the transaction.rcpt_to array and deliver the message only to rcpt2 ignoring the SA result. This is pretty horrible (and definitely not RFC compliant) because the sender will never know that delivery failed to rcpt1@company.com - you're effectively throwing the message into the bitbucket for that user.

My use case is I am creating an email forwarder.

Then be sure you look at writing an SRS plugin then, otherwise you'll have all sort of deliverability issues. https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme

[msimerson]

Adding to Steve's list of workarounds:

1. Leave the SpamAssassin plugin enabled for all (since you can't selectively enable a plugin for certain users). When you get to queue time, deliver the messages that have a) SpamAssassin enabled and b) low spam scores and then drop messages that have spam SpamAssassin enabled and high spam scores.

Although Steve is right that the sender will never know about the dropped deliveries, it's little different than delivering it to the users spam folder that they never check. Whose preferences matter most here, the senders or recipients?