I just ran into this issue when one of my users complained that he receives to much spam, while on my own account everything works fine.

After testing extensively I can confirm that the default settings just work for the primary domain the mail-server is on. Additional domains are not “protected” by spamassassin. This has to do with the default setting 60-dms_default_config being wrong.

use strict;

@local_domains_maps = (
   read_hash('/etc/postfix/vhost')
);

1;  # ensure a defined return

This can not now all domains I configured in ldap.

The FAQ mentions a workaround considering all domains as local by changing the 50-user config:

[Why are SpamAssassin x-headers not inserted into my subdomain.example.com subdomain emails?](https://docker-mailserver.github.io/docker-mailserver/edge/faq/#why-are-spamassassin-x-headers-not-inserted-into-my-subdomainexamplecom-subdomain-emails)

In the default setup, amavis only applies SpamAssassin x-headers into domains matching the template listed in the config file (05-domain_id in the amavis defaults).

The default setup @local_domains_acl = ( ".$mydomain" ); does not match subdomains. To match subdomains, you can override the @local_domains_acl directive in the amavis user config file 50-user with @local_domains_maps = ("."); to match any sort of domain template.

This gave me some trouble to figure out… Of course this never takes any effect because the 60-dms_default_config file is still present and will directly overwrite the setting in 50-user 🤦 .

However replacing 60-dms_default_config with the workaround finally made it work 🥳

tl;dr

If you are using multiple domains via ldap configuration and want to have spam detection for all domains use @local_domains_maps = ["."]; in /etc/amavis/conf.d but make sure to place it so, that config files with higher numbers don’t overwrite it!

extra tip

If you mount the config-file from your host system make sure the user and group are correct otherwise amavis will not start correctly!

… and am not sure if I should let 25 open

Closing port 25 will ultimately block SPAM, but also all other legitimate mails 😉

I’m grateful for your meticulous look into this @williamdes because I am in the same situation; there are no added headers or any other indication that mail is being scanned and processed for spam; all spam blast straight through to my inboxes.

I’ll have a look at my config and test the tldr 60-dms...-modification suggested and report back with any findings.

@SnowMB you are my hero of the day. It took me a whole day to get apamassin now finaly with LDAP up and running. Thanks for description.

This issue has become stale because it has been open for 20 days without activity. This issue will be closed in 10 days automatically unless:

• a maintainer removes the meta/stale label or adds the stale-bot/ignore label
• new activity occurs, such as a new comment

Could you please update your initial post, with a short “tl;dr”, that contains the new findings. So that not everyone have to read the whole thread 😉.

Sorry, I don’t have an idea at the moment. Regarding the “cryptic” message:

The GTUBE (“Generic Test for Unsolicited Bulk Email”) is a 68-byte test string used to test anti-spam systems, in particular those based on SpamAssassin. In SpamAssassin, it carries an antispam score of 1000 by default, which would be sufficient to trigger any installation.

https://en.wikipedia.org/wiki/GTUBE

We do not have too many maintainers using LDAP. Maybe you can try and report back here @dumblob?

I wanted to try this container in LDAP setup but this issue scares me kind of. Is it still valid?

That a big no-no, and we should fix that. Can you solve this @williamdes?

Yes, but I m not sure what strategy to adopt

I understand. My advise would be to use the strategy that you think fits best. In the end, you can submit a PR, state the reasons for the change and we well review it, so in theory, nothing should go wrong.

That a big no-no, and we should fix that. Can you solve this @williamdes?

I would like to help, but I’m not using LDAP.

Maybe @casperklein can help you further with the cryptic XJSC4JDBQADN1.NSBN32IDNENGTUBE-STANDARD-ANTI-UBE-TEST-EMAILC.34X message.

I’d personally try this (if you haven’t done that already):

1. Add more capabilities
2. Remove the sed ... line in user-patches.sh to see whether this may interfere with SpamAssasin
3. Maybe try a non-LDAP setup to prove your hypothesis about /etc/amavis/conf.d/05-domain_id

You can turn notify verbose by enabling DMS_DEBUG=1😃