Mailcow-dockerized: Whitelist contacts from contact lists

[jmthackett]

Hello!

I'm very happy with mailcow so far, and have had a great experience. It is a fantastic project.

The problem I'm having is that people I definitely want to talk to get dumped into spam, especially when messages are encrypted. I'd like to be able to blanket allow everyone in my contacts list and never have them go to spam.

With that in mind, my feature request is this: a checkbox in the mailcow user interface where spam currently is, which would let me tick a box for "permit mail from contacts".

In terms of implementation, this could be done with a small CLI utility to read from SOGo's database directly for a named user. That could then be invoked with another script to insert those contacts into the mailcow database as exemptions for spam. There might be an issue with assuming the stability of SOGo's table structure over time, though.

[andryyy]

Hi,

Can you post Rspamd logs of those msgs to be filed into junk? Maybe there's something wrong we could fix.

As for your feature request; that's actually a funny idea we could think about.

[jmthackett]

I'll be able to get logs later, but the problem is reasonably clear to me - I have friends who don't have SPF/DKIM/DMARC and who send me GPG encrypted messages. It's _always_ GPG encrypted messages.

If it sounds feasible that's great! The biggest problem I have with email is contacts getting spam binned (and being spambinned by people I am a contact of).

[andryyy]

I think something like this can work:

source mailcow.conf
docker-compose exec mysql-mailcow mysql -u${DBUSER} -p${DBPASS} ${DBNAME} -e "select distinct(sogo_folder_info.c_path2), GROUP_CONCAT(sogo_quick_contact.c_mail) from sogo_folder_info inner join sogo_quick_contact on sogo_quick_contact.c_folder_id = sogo_folder_info.c_folder_id group by c_path2;"

I have only tested it on a small dev box, can you check your results for errors?

[jmthackett]

It looks good to me: I have two users including my primary mail and contacts list, and it returns the correct list of contacts for each one.

[andryyy]

I've implemented it.

[jmthackett]

That's awesome! Thank you. Is it going to be in the next release?

On 7 November 2018 08:57:38 GMT, "André Peters" [e-mail] wrote:

I've implemented it.

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/mailcow/mailcow-dockerized/issues/1983#issuecomment-436551320

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[andryyy]

Yes. :-)

[hachre]

This is a great feature! Thank you!

[andryyy]

Let me know if it works for you guys. Edit: Pushed it.

[hachre]

Do I have to enable this somewhere or is it automatically enabled for all Mailboxes?

[andryyy]

It is auto-enabled. You can check the Rspamd settings map and post it here (censored) if it is not working as expected.

[hachre]

Looks great so far!

I noticed the exceptions are tied to specific recipient addresses right now. I think if Mailcow is used as a company mail server, it would make sense to have an option where those generated exceptions are not tied to rcpt statements at all. This way anyone's contacts would not land in anyone`s spam server-wide.

Would this be an option to consider?

[andryyy]

I thought about it. :) But I was unsure. A custom blacklist still overrides the SOGo whitelist, so it _should_ be okay. Hm. But you will always know someone has it on its whitelist due to the symbol. We could rename it to MAILCOW_WHITE.

[mkuron]

This way anyone's contacts would not land in anyone's spam server-wide.

I don't think that's a good idea. One of your users might have a spammer's address in their address book and another user might wonder why an obvious spam message never is marked as such. In general, one user's actions should never affect another user's.

But you will always know someone has it on its whitelist due to the symbol. We could rename it to MAILCOW_WHITE.

Knowing that some other user in your organization has someone as a contact might be a problem in some business situations. Renaming the symbol to MAILCOW_WHITE doesn't help because people can just log into the Mailcow UI and check whether that address is whitelisted for the entire server or their domain. If it's not, it must be in someone's address book.

Another problem just came to my mind, @andryyy: have you checked whether your solution scales? If you have 200 users with 200 contacts each, the settings map will be approximately 1 MB in size. Does rspamd deal with that efficiently?

[andryyy]

Another problem just came to my mind, @andryyy: have you checked whether your solution scales? If you have 200 users with 200 contacts each, the settings map will be approximately 1 MB in size. Does rspamd deal with that efficiently?

It indeed does. I have setups with larger settings maps and it works flawless.

[hachre]

Thanks, @mkuron, good points!

[clemenstyp]

This change can lead into a spamming problem: I just received a Mail, where the spammer faked my recipients address into the sender address. But this change just overruled all other Anti-Spam features.

[andryyy]

We could remove the From header check.

[protree]

We could remove the From header check.

@andryyy Please take a look at it. I'm having the same problem as @clemenstyp. All mails with faked recipient address pass the spam filter.

Example Mail Header (My reciepient changed to "[email protected]", My Mailserver changed to "mail.domain.tld", My domain changed to "domain.tld"):

Return-Path: [e-mail]
Delivered-To: [email protected]
Received: from mail.domain.tld ([fd4d:6169:6c63:6f77::d])
by mail.domain.tld with LMTP
id AZxrJfZ8OlzKYwAA83qGlg
(envelope-from [e-mail])
for [e-mail]; Sun, 13 Jan 2019 00:49:10 +0100
Received: from ip-168.232.67.161.centralnetsurubim.com.br (unknown [168.232.67.161])
by mail.domain.tld (Postcow) with ESMTP id 4A2165E874
for [e-mail]; Sun, 13 Jan 2019 00:48:58 +0100 (CET)
Message-ID: <302A8BCC77916D302A8BCC77916D302A@NPMRXM2NP>
From: [e-mail]
To: [e-mail]
Subject: Nachricht vom Sicherheitsdienst. Der Zugang zu Ihrem Konto erfolgt uber Dritte.
Date: 12 Jan 2019 16:29:47 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0022_01D4AAB8.06F67F3D"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109
Authentication-Results: mail.domain.tld;
spf=fail (mail.domain.tld: domain of [email protected] does not designate 168.232.67.161 as permitted sender) smtp.[email protected]
X-Spamd-Result: default: False [-979.85 / 2000.00];
SOGO_CONTACT(-999.00)[];
RBL_SPAMHAUS_XBL(4.00)[161.67.232.168.zen.spamhaus.org : 127.0.0.4];
TO_DN_NONE(0.00)[];
HFILTER_HELO_IP_A(1.00)[ip-168.232.67.161.centralnetsurubim.com.br];
HFILTER_HELO_NORES_A_OR_MX(0.30)[ip-168.232.67.161.centralnetsurubim.com.br];
FUZZY_DENIED(2.00)[1:da490ed463:0.53:txt,1:da490ed463:0.91:txt];
MX_GOOD(-0.01)[smtp-backup2.portunity.de,mail.domain.tld,smtp-backup1.portunity.de];
HAS_X_PRIO_THREE(0.00)[3];
RCVD_COUNT_ZERO(0.00)[0];
TO_EQ_FROM(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
R_DKIM_NA(0.00)[];
RCPT_MAILCOW_DOMAIN(0.00)[domain.tld];
MIME_TRACE(0.00)[0:+,1:+];
BAYES_HAM(-7.26)[93.43%];
ONCE_RECEIVED(0.10)[];
ARC_NA(0.00)[];
R_SPF_FAIL(0.00)[-all];
ASN(0.00)[asn:264935, ipnet:168.232.64.0/22, country:BR];
RBL_NIXSPAM(4.00)[161.67.232.168.ix.dnsbl.manitu.net];
IP_SCORE(0.13)[country: BR(0.63)];
TO_MATCH_ENVRCPT_ALL(0.00)[];
MIME_GOOD(-0.10)[multipart/alternative,text/plain];
DMARC_NA(0.00)[domain.tld];
RCPT_COUNT_ONE(0.00)[1];
RBL_VIRUSFREE_BOTNET(2.00)[161.67.232.168.bip.virusfree.cz : 127.0.0.2];
FROM_NO_DN(0.00)[];
MID_RHS_NOT_FQDN(0.50)[];
HFILTER_HOSTNAME_UNKNOWN(2.50)[];
RCVD_TLS_ALL(0.00)[];
SPF_FAIL_NO_DKIM(10.00)[]
X-Rspamd-Queue-Id: 4A2165E874

[andryyy]

I think we already removed it.

It does not help when you remove every single address in your example by “user@domain”.

[mkuron]

2079 only checks for R_SPF_SOFTFAIL and R_SPF_PERMFAIL. Your message has R_SPF_FAIL, which we should probably add. R_SPF_PERMFAIL is used if the SPF policy is invalid, so we probably shouldn't check for that.

[andryyy]

Could you create a PR?

[protree]

Sender and reciever are the same because it was faked by the sender. In the original Mailheader sender and reciever are the same in every occurence of [email protected]. So no information should be lost.

Last update of m instance was on " Mon Jan 7 14:13:56 2019 +0100". I can't find any related commit since then...

EDIT: Thank you for looking at it!

[andryyy]

I see. I misunderstood. Sorry.