I recently setup a mail-in-a-box instance to host my own mail. This includes several domains and an external DNS server. The whole setup in general worked fine and also mails are successfully sent & received to other mail servers.
Now I noticed that all Mail-in-a-Box Status Check & Usage Report mails end up in the Spam folder.
This seems odd to me, as I do not see a reason why the own system generated mails are not whitelisted and how they could even end up in the Spam folder.
I noticed the X-Spam header fileds:
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
**redacted**.space
X-Spam-Flag: YES
X-Spam-Level: ******
X-Spam-Status: Yes, score=6.5 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FROM_SUSPICIOUS_NTLD,FROM_SUSPICIOUS_NTLD_FP,
HTML_MESSAGE,PDS_FRNOM_TODOM_NAKED_TO,PDS_FROM_NAME_TO_DOMAIN,
PDS_OTHER_BAD_TLD autolearn=no autolearn_force=no version=3.4.2
X-Spam-Report:
* -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
* 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
* [URI: **redacted**.space (space)]
* 0.0 HTML_MESSAGE BODY: HTML included in message
* -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
* author's domain
* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
* valid
* 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
* 1.6 FROM_SUSPICIOUS_NTLD_FP From abused NTLD
* 2.0 PDS_FROM_NAME_TO_DOMAIN From:name looks like To:domain
* 1.5 PDS_FRNOM_TODOM_NAKED_TO Naked to From name equals to Domain
X-Spam-Score: 6.5
It seems like my TLD (.space) is generating a spam score of 4.1 on its own which seems odd. Also I wonder why those internal mails generated by mail-in-a-box itself are not whitelisted.
Is there any way to get these mails whitelisted so I do not have to look for them in the Spam folder?
Also any other hint on what I could try to solve this issue without interfering with the mail-in-a-box installation in a unsupported way (which would be reverted during some updates if I understood that correctly) would be really appreciated.
It seems like some relatively recent update to Spamassassin has made it more aggressive than ever before. I have known good TLDs being declared as spam for just normal email, and it is getting very aggravating. I have wondered why most modern mail admins have been switching to rspamd and although I haven’t looked into it, these are the kinds of problems that will spur an admin make substantial changes to mail server components.
Your .space TLD is clearly a bad one for email, and there are many others treated the same way. Whenever avoidable, do not use the bad TLDs for email. You can see a list of known bad TLDs in the MiaB Setup page, but the list is not by any stretch exhaustive.
I did quick search and although I haven’t tried this, it seems like good info as at least a place to start:
Note that it is suggested to use welcomelist instead of whitelist in the future. Both work at the moment (and yield an identical result) but whitelist might be removed in the future. I could not really find a good source for this besides people talking on different boards & mailinglist, but wanted to point it out here anyways in case someone else stumbles across this issue and the deprecated warning in the email:
* -0.0 USER_IN_WELCOMELIST user is listed in 'welcomelist_from'
* -100 USER_IN_WHITELIST DEPRECATED: See USER_IN_WELCOMELIST
It does not matter which term I use right now, this warning always appears. So it is probably ok to not worry about the warning too much.
Anyways I am not sure if this change survives a mail-in-a-box update, as it directly changes a config file.
I know that .space seems to be a bad choice for email and also have other .com and .de domains to use, but still wanted to get it working to a level where at least the internal mails are not blocked anymore.
Generally in MiaB, updates only changes edited files when the update changes the file that was edited, with a few exceptions, so you would need to either manually verify the file was not edited or keep up with PRs included in the update.
I would likely create a separate conf file with an include filename in the main conf file, that way I don’t have to update the conf file. I don’t recall specifically how to do this in Spamassin, but note the config files are Perl, IIRC.
The real key is don’t use the bad domains for your mail server domain (e.g., box.example.space) because this will negatively impact every domain the mail server hosts.
Oh, I also found that this same list of “bad” TLDs is also used for a lot of plugin “bad guy” email lists for signup forms, so many very popular sites or people using some external service will flat reject any attempt to sign up for their service when such TLDs are used. (Fortunately, Akismet does not seem to do this, yet.)
Do you know how this list of “bad” TLDs is created in the first place?
I checked the “badness” score of some TLDs here https://www.spamhaus.org/statistics/tlds/ and noticed that even .com has a worse score than .space has.
Some numbers I just picked out of there today (2021-01-27):
com = 4.3% bad (score 0.54)
org = 1.5% bad (score 0.12)
space = 3.4% bad (score 0.23)
net = 7.1% bad (score 0.74)
eu = 3.8% bad (score 0.27)
cn = 15.8% bad (score 1.74)
us = 16.0% bad (score 1.47)
de = 0.3% bad (score 0.02)
fr = 0.8% bad (score 0.05)
I know I am comparing it to “old” TLDs here, but it seems like .space is quite average and in a similar range to .com, .org or .net. So how is the distinction made between “good” and “bad” regarding the TLDs?
It is indeed possible to move it to a different file. All *.cf files within /etc/mail/spamassassin/ are used by spamassassin and analyzed in alphabetical order.
Therefore I reverted all changes to local.cf and simply created a new file /etc/mail/spamassassin/90_box.example.space.whitelist.cf
# Whitelist system mail from administrator
welcomelist_from_rcvd administrator@box.example.space localhost
Please replace box.example.space with the FQDN of your mail-in-a-box installation. The filename can be chosen freely. Just make sure it is any stays unique.
As long as any update in the future does not create this file or change the path where it looks for such files it should be safe. Just wanted to leave this for anyone else running into a similar problem.
Edit: change filename to be unique even in the future as suggested by @openletter
I might change it to some unique name nobody would ever use such as 90_box.example.space_whitelist.cf because eight years from now when I still have the same config but have otherwise completely forgotten about it, some MiaB dev will add the feature using the same name and I won’t review PR and then lose all my stuff I added the file over the years and the baby is crying and the wife is upset and I’m running late for work.
I could use some help making this change to my install. I have a mailbox@xxx.xyz. The .xyz TLD is caught as spam so, spamassasin scores it really high, and all of my maintenance messages get sent to spam. I have tried dragging them to inbo, it doesn’t learn it. I tried setting a filtering rule in roundcube, that doesn’t work. My next step is manually adding the address to welcomelist, but i’m not sure how to do that. Like, where is the file in the mailinabox system, how do I find it and how do I change it. I assume at some point I run nano and open a conf file to modify it, but I couldn’t find the right folder/file. I have a very small amount of linux knowledge, basically just enough to be really dangerous.
Any help would be greatly appreciated.