The feature Spam filtering cannot be disabled

Submitted by martin@mewes.tv on Sat, 10/16/2010 - 09:23

The feature Spam filtering cannot be disabled, as it is used by the following virtual servers : zahnaerzte-hh-qm.de mewes.tv mistralbande.de ferienhaus-fenja.de mamemu.de

I assume that these domains do have connections to /etc/procmailrc. Could Virtualmin being involved to correct this for itself?

When I try to enable Spam filtering for the other domains the miniserv.pl shows up with this error, that Virtualmin will install spamfiltering on domain basis and does not need /etc/procmailrc.

What would be a sufficient way to get around with this, as the system does not "repair" these conflicts automagically.

cheers -f

Martin

Status: 
Closed (works as designed)

Comments

Submitted by JamieCameron on Sat, 10/16/2010 - 19:08

That error means that the spam feature is still enabled for those domains. You need to turn it off on their Edit Virtual Server pages. Then you can disable it on the Features and Plugins page.

Submitted by martin@mewes.tv on Sat, 01/08/2011 - 06:47

Well, it took a while ... I have had a look at "mamemu.de" again, but this option is not set.

Submitted by martin@mewes.tv on Sat, 01/08/2011 - 07:01

This is what I tried ... (image two) List all domains with spam filtering turned on .. (image three) select all - update selected - deselect spam filtering - GO! (image four) seems to be ok (image five) have a look what happens after (image six) (image seven)

???

Anyways: Happy New Year!

Submitted by JamieCameron on Sat, 01/08/2011 - 10:48

OK, in this case what you need to do is :

  1. Go to System Settings -> Features and Plugins, and enable the "Spam filtering" feature.
  2. Disable that feature on all domains that have it enabled.
  3. Go back Features and Plugins, and disable the "Spam filtering" feature.

Submitted by martin@mewes.tv on Sat, 01/08/2011 - 12:06

Now this is what happened. (image8) (image9) ??

Submitted by andreychek on Sat, 01/08/2011 - 13:10

What output do you receive if you log onto the command line as root, and run the following command:

postconf -n

Submitted by martin@mewes.tv on Sat, 01/08/2011 - 17:10

To: martin@mewes.tv Subject: postconf From: root@ds80-237-210-29.dedicated.hosteurope.de (root) Date: Sun, 9 Jan 2011 00:09:08 +0100 (CET)

alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes config_directory = /etc/postfix content_filter = scan:127.0.0.1:10024 delay_warning_time = 4h home_mailbox = Maildir/ local_destination_concurrency_limit = 10 mailbox_command = /usr/bin/procmail -f- -a "$USER" mailbox_size_limit = 0 message_size_limit = 20480000 mydestination = $myhostname, mail.$mydomain, server,localhost.$mydomain, localhost, localhost.localdomain, $mydomain mydomain = dedicated.hosteurope.de myhostname = ds80-237-210-29.dedicated.hosteurope.de mynetworks = 127.0.0.0/8 myorigin = /etc/mailname receive_override_options = no_address_mappings recipient_delimiter = + smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd smtp_sender_dependent_authentication = no smtp_use_tls = no smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks smtpd_etrn_restrictions = reject smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks smtpd_recipient_restrictions = permit_sasl_authenticated, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, reject_unauth_destination, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client sbl.spamhaus.org, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $myhostname smtpd_sender_restrictions = reject_unknown_sender_domain smtpd_use_tls = no strict_rfc821_envelopes = yes unknown_local_recipient_reject_code = 450 virtual_alias_domains = /etc/postfix/virtual_domains virtual_alias_maps = hash:/etc/postfix/virtual_alias

I know that the last two lines are the error ... But if I delete either one, postfix will go crazy ..

Submitted by JamieCameron on Sat, 01/08/2011 - 19:22

You should remove the virtual_alias_domains entry, and then restart Postfix.

Submitted by martin@mewes.tv on Sun, 01/09/2011 - 03:31

After altering this, the next step was, that /etc/procmailrc is set to run spamassassin. After puttung some ## into that file, I needed to do

chgrp root /usr/bin/procmail

followed by

chmod 4755 /usr/bin/procmail

and then I could finally disable the settings.

Those modifications could have been done by Virtualmin automatically.

Submitted by JamieCameron on Sun, 01/09/2011 - 18:39

So were you setting up procmail to run spamassassin globally, rather than on a per-domain basis like Virtualmin does?

Submitted by martin@mewes.tv on Mon, 01/10/2011 - 00:08

Absolutely ... as most of my domains are "mine" and only one is a "foreign" one. Settings in /etc/procmailrc where the first things I wrote back in 2008. I think I played with the settings and messed them up a bit?

Submitted by JamieCameron on Mon, 01/10/2011 - 00:42

Could be .... virtualmin assumes that it has control over the procmail config.

So is it working ok now?

Submitted by martin@mewes.tv on Mon, 01/10/2011 - 02:07

Hi Jamie,

well, yes and no ... In order to delete SpamAssassin on Domain basis I had to delete

virtual_alias_maps = hash:/etc/postfix/virtual_alias

as advised. Then I had to change some procmail stuff according to the error messages on screen.

But ... in order to get Postfix serve mails again I had to insert

virtual_alias_maps = hash:/etc/postfix/virtual_alias

back again.

This now causes a Virtualmin Configuration Check to fail, when it comes to check of Postfix.

Because ...

virtual_alias_maps = hash:/etc/postfix/virtual_alias

which is to be deleted :-/

For me this case file is closed ... Thanks again!

Martin