Ignore multimap whitelist from when email sent with several recipients

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
TO_WHITELIST {
    type = "rcpt";
    map = [
    "${CONFDIR}/whitelist_to.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,
 permit_mynetworks,
 permit_sasl_authenticated,
 reject_unauth_destination,
 check_recipient_access hash:/etc/postfix/internal_access,
 reject_unverified_recipient

…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.

2 Likes

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

Maybe he can help in this topic

3 Likes

Hello @stephdl, I was able to come up with a solution for the post you linked thanks to @saitobenkei. As you can see he helped me create a custom template.

3 Likes

Thank you for sharing the link @jfernandez, it looks promising!

I hope @Nikotinee can find some good hints to adjust his system configuration.

Great, but the method described by @fernandez. solves only the issue of local mail and its control within the same domain as far as I understand( this can be solved even more primitivny, prohibit the postfix service to go to the red interface). I have a list of white addresses that are located in different external domains. Is there any way to solve my problem? I will repeat that there was no hole in the plan of mailing on a set of mailboxes. If the mailing list contains at least one address from the white list, then all other addresses are not checked.

We have a card on it but we are still checking the pro and the cons to change the actual behavior.

No eta

Hello! is there any news on the issue?

There is still no interest to change the current behavior by my side. Disabling whitelisting with multiple recipients could be correct IMO but requires a bit of QA work.

The Block-to is a separate new feature.

For that sake I’d like seeing some custom templates.