Ignore multimap whitelist from when email sent with several recipients

When sending emails, if the list of recipients has an address with a domain from the white list, then all other recipients are ignored by the rules(all emails and attachments go unchecked to any addresses without obeying filters)

Hi Kirill, welcome to NethServer community!

I agree it is an unexpected behavior, maybe a #bug, not sure of that. I cannot verify it now, hopefully @stephdl can confirm it. It could be an effect of applying the allow-list checks in the “pre-filter” stage.

Please consider that when sending with authentication, checks are more permissive to avoid blocking legitimate messages.

So what could be the “right” behavior if a message considered spam is sent and one recipient is in the allow-list: accept for all, or reject for all? (generating a bounce is not an option)

I’d say accepting is a good compromise. I know the answer could be not satisfactory, however this is one more reason to not rely too much on allow/deny lists.

I have set up a list of conversations roughly only inside mydomain.com(internal mail). If, for example, you make several recipients in the same outlook, mozilla. And among these recipients will be user@mydomian.com then other recipients with any domains will also be sent, but the same should not be?

Hum need to check but I would prefer to create a group of email or use a mailling list like sympa, rather to send an email with several recipients

Eg : send email to commercial@domain.com and redirect to all members of this group

I am not sure that we can propose a no verification for the whitelisted and reject in case of spam for all others.

At least we should document this behaviour

1 Like

Unfortunately, this option is not quite suitable, and you do not want to give up a great product because of such a small thing. Maybe there is an option to configure this directly in the rspamd configs?


Multimap is the engine of this in rspamd

Well I guess what you want is not possible, the email sent is analysed just one time by rspamd then if good it is sent. In short each mesage is analysed one time, maybe the only trick you can do is to disable the whitelist multimap if you do not find the symbol RCPT_COUNT_ONE

in short add to the multimap /etc/rspamd/local.d/multimap.conf

#whitelist the email address of recipients
    type = "rcpt";
    map = [
    prefilter = true;
    filter = "email:addr";
    action = "accept";
    description = "Accept SMTP recipient by exact email address";
    symbol = "TO_WHITELIST";
  require_symbols = "RCPT_COUNT_ONE";

this should disable the whitelist from prefilter if you find more than one recipient in the message

1 Like

I don’t quite understand why I need this? I need that the letter would not go to an unauthorized address, in extreme cases, if the list of recipients has an unauthorized address, then the letter was not sent to anyone at all. The option that there is a black and white list, but it is ignored during mass mailing(if at least one of the recipients is allowed) seems very strange. Even more strange is that it can’t be solved…

This is what I proposed

Disable whitelist recipient for mass mail sending, then the email is analysed by rspamd, if something wrong is found then the email is not sent by our postfix

Enable whitelist recipient when you have only one recipient to the email, then the email is not analysed and sent like this without any checks

Like we said previously, when you send an email via the postfix, you are an authenticated user and a lot of checks are not more performed by rspamd, I mean dns check, spf, oletools, clamav timeout and some others…

In simple word we cannot honor during a mass mail sending the whitelist and reject the email for all others however I can obviously be wrong and I am opening to pull request :slight_smile:

I wonder if he would have treated the recipients in the first place not allowed addresses, and if any is in the list, the transfer is not passed to anyone, and if incorrect there is no address, the letter was gone. It is strange that this is a huge problem, zimbra can do it almost " out of the box"

Please could you reword your answer with detailed behavior, I wonder if we do not understand each other

Sorry for my bad english. I’m trying to eliminate the possibility of accidental forwarding to unapproved addresses

1 Like

Therefore you want a list of blacklist recipient and a list of whitelist recipient

If one address is in the blacklist recipient, even in a mass mail sending, we do not send the mass email sending, do I right @Nikotinee

EDIT: in that case we do not have a TO_BLACKLIST_*, this is a feature request

Do not be shy with your english, except for few english mothertongue in this forum all others are non english native writers

The thing is that in the NethSrv settings there is no block to function, there is only block from

1 Like

Thanks a lot for your inputs

I will have to share two things with @dev_team

A blacklist_to rule : block to send email to address or domain (this can be done at the postfix level, not only at the rspamd level)

Whitelist_to might have a bug when I send mass mailling with whitelisted_to inside

1 Like

Do we have a template-custom?

We could fix that behavior as you said with the RCPT_COUNT_ONE approach: if multiple recipients are present, the “allow to” list is ignored.

However this kind of fix changes the behavior, thus requires a safe upgrade path… I’m not sure that’s worth the effort.

1 Like

to block to communicate with other domain address/domain

we set the rule in multimap after the TO_WHITELIST in /etc/e-smith/templates/etc/rspamd/local.d/multimap.conf/10base (create a template-custom)
we create map (one address per line in /etc/rspamd/)
we do a force action in /etc/rspamd/local.d/force_actions.conf, use /etc/rspamd/override.d/force_actions.conf to override

in brief it needs time to be studied and tested

Can we expect to eliminate this problem in the foreseeable future?

ATM the only change proposal is:

if the message has multiple recipients, do not consider the “allow to” list

The “block to” feature was never asked before, I think because the whole mail-filter component is not designed to enforce restrictive policies against internal users. When somebody asks a new feature/goal addition we usually start by building a template-custom.

For the proposed “block to” @stephdl did a brief analysis and said that “it needs time to be studied and tested”…

What about implementing the template-custom at the Postifx level?

smtpd_relay_restrictions = check_client_access cidr:/etc/postfix/access.cidr,
 check_recipient_access hash:/etc/postfix/internal_access,

…a new check_recipient_access directive could be inserted before permit_sasl_authenticated to be sure some recipients are not allowed, even by authenticated clients.


only @jfernandez asked for it IIRC : Migrating from MDaemon to nethserver-mail

Maybe he can help in this topic