How do I stop mail identified as spam getting deleted?

Kal

Verified User
Joined
Nov 18, 2019
Messages
128
Location
Australia
In my personal account's SpamAssassin Setup, I had the spam deletion option set to:
Yes, block all spam scoring higher than: 20


It seemed like a good idea at the time, but… well I'm quickly learning how many people (big companies even) have poorly configured SPF or DKIM (which is probably worse than no validation at all!), resulting in spam scores over 100. So I just turned the delete option off and asked someone to resend.

To my surprise however, their emails are still bouncing. The Exim Rejectlog says:
… rejected after DATA: Your message to <my@address> was classified as SPAM. Please add more content, cut down on HTML links, use fewer naughty words etc. Also, ask your IT dept to make sure your mailserver has REVERSEDNS, SPF, DKIM, and is not on any black lists. Your score: 160


For another sender, it just says this:
… A=plain:my@address rejected RCPT <client@address>


Why would this be, when SpamAssassin is set to not delete spam? Am I right in saying that Easy Spam Fighter just calculates a spam score—that it doesn't actually delete anything? What else do I need to check?
 
how many people (big companies even) have poorly configured SPF or DKIM
So I always tell my customers to complaint with these company's or tell them to get an account with me or another good hosting company who know what they are doing. :)
However, this does not solve your problem.

Chances are that not Spamassassin but Easy Spam Fighter is still throwing the mail into spam.

Maybe it's a better solution to just keep your good settings, and put the bad adresses you want to ignore into the /etc/virtual/esf_skip_senders file.
It probably does not exist, but you can create it yourself:

It's way better then shutting down your anti-spam measures.
I would also notify the company's they should take care their stuff get fixed.
 
  • Like
Reactions: Kal
I'm quickly learning how many people (big companies even) have poorly configured SPF or DKIM
So true. Its because they don't have some of us working for them... RichardG and others would straighten the out...:cool:. It's like in your other post "I mean some say why keep stuff up to date."

They all work together.
By default in EasySpamFighter, a rDNS, DKIM or SPF that fully fails is dropped right away.
They all use a default score of 100, while the drop score is 100.
So you might want to change your default scores

Code:
cat /etc/exim.easy_spam_fighter/variables.conf
EASY_LIMIT = 55
EASY_IS_SPAM = 20
EASY_HIGH_SCORE_DROP = 100
EASY_SPF_PASS = -30
EASY_SPF_SOFT_FAIL = 30
EASY_SPF_FAIL = 100
EASY_DKIM_PASS = -20
EASY_DKIM_FAIL = 100
EASY_NO_REVERSE_IP = 100

EASY_FORWARD_CONFIRMED_RDNS = -10
EASY_DNS_BLACKLIST = 50
EASY_SPAMASSASSIN_MAX_SIZE = 200K

The info links ar in here as well. Makes sure you scroll down on the ones in Info on easy_spam_figher (ESF) and BlockCracking (BC).
 
  • Like
Reactions: Kal
So I always tell my customers to complaint with these company's or tell them to get an account with me or another good hosting company who know what they are doing.

Thanks Richard. Yes I agree. One of the senders is a certain near-monopolistic hardware chain in Australia that is failing DKIM. I gave the staff member feedback to pass on to their IT department. The other sender is actually a potential customer who is wanting to switch away from their current provider anyway. The thing is, we need to communicate in the meantime! :)

Maybe it's a better solution to just keep your good settings, and put the bad adresses you want to ignore into the /etc/virtual/esf_skip_senders file.
It probably does not exist, but you can create it yourself:
https://help.directadmin.com/item.php?id=628

Good advice I think. I've added them to /etc/virtual/esf_skip_senders and /etc/virtual/whitelist_senders. Let's hope that does the trick.


Ah, that answers the question for certain! Thanks Brent. That's really critical information about how EasySpamFighter works, which I somehow missed. I think it should be made clearer in the docs and something you can edit in DirectAdmin, perhaps under Server Manager > Administrator Settings > E-mail Settings.
 
The other sender is actually a potential customer who is wanting to switch away from their current provider anyway. The thing is, we need to communicate in the meantime!:)
I understand. It's not always possible to just block bigger company's, especially not if you want them as customer. Hence the idea to use the ignore list, at least temporarily.

I also know about the settings Brent is talking about, however these are global, so I wouldn't fuzz with these for just one company as this makes other spam again options to enter again.
However, I've changed them a bit too, to make things more tight so my variables.conf.custom looks like this:
Code:
EASY_LIMIT == 50
EASY_DKIM_PASS == -30
EASY_DNS_BLACKLIST == 100
which makes it start a tiny bit sooner (50 instead of 55), validates dkim pass a bit more (-30 instead of -20) but also takes care that blacklisted get refused due to the change from 50 to 100.
This setting is however not possible for everybody, because it will block a very lot. :)
 
  • Like
Reactions: Kal
Yes, I agree. On reflection, I don't think we should water down EasySpamFighter for the sake of a few poorly configured servers… I mean, if we all did that, what's the point of SPF, DKIM and DMARC? I just think the behaviour could be better documented and easier to configure.
 
Exactly. So I didn't water it down but even fired it up. :)
But for that reason my advise to eventually whitelist a couple of bad configured servers for the time being.
I hope you get them as customer so they can experience how things should run. ;)
 
  • Like
Reactions: Kal
Looking a bit closer at the Easy Spam Fighter page, and what each of the settings do, I notice there's no reference to DMARC policies. With DMARC, there shouldn't really be a distinction anymore between an SPF soft fail (~all) and hard fail (-all)—either is an SPF fail, and the task of declaring rejection policy should fall to the DMARC record. But ESF is configured (by default) to score an SPF soft fail with 30 and an SPF hard fail with 100 (instant rejection). And as far as I can tell, it ignores DMARC entirely.

Is this your understanding too? Is ESF due for a DMARC-honouring update…? EASY_HIGH_SCORE_DROP might instead be called something like EASY_HIGH_SCORE_FAIL, and messages which fail the test are acted on in accordance with the DMARC policy (if it exists)—so a message is only dropped when 'p=reject'.
 
Another question… How should I go about editing the dropped mail message? By default, it says:
Your message to <$recipients> was classified as SPAM. Please add more content, cut down on HTML links, use fewer naughty words etc. Also, ask your IT dept to make sure your mailserver has REVERSEDNS, SPF, DKIM, and is not on any black lists. Your score: $acl_m_easy69

'Add more content' and 'use fewer naughty words', really? Since the cause (for a legit sender) is almost certainly a poorly configured mail-server, implying there's something wrong with the sender's message is disingenuous and unprofessional IMO.

This message comes from the /etc/exim.easy_spam_fighter/check_message.conf file. I could edit it there, but I guess it's going to get overwritten by DA. The config file checks for check_message.conf.custom.pre at the beginning, and check_message.conf.custom.post at the end. I'm not familiar with exim config files, but it looks like the order is important, so I'm not sure that duplicating bits of the code in either of these custom files is a good idea?
 
Is this your understanding too? Is ESF due for a DMARC-honouring update…?
I don't think so. Because it's not ESF's task to check DMARC records and interfere with user settings for DMARC. For testing purposes, users can start using DMARC with the policy of "none" which takes care that nothing happens with the mail if they configured it incorrectlyu.
So it's not up to ESF to still block the mail then against the policy set by the user configuring DMARC.
IMHO that is the reason it doesn't bother with it.

Next to that, on setting up DMARC, DA advises to use -all and not ~all on SPF.

I've just seen 2 messages, Brent is posting at the same time I'm writing this. :)
But this is my answer to your question in posting #10.
 
Add more content' and 'use fewer naughty words', really? Since the cause (for a legit sender) is almost certainly a poorly configured mail-server, implying there's something wrong with the sender's message is disingenuous and unprofessional IMO.
Probably not in all cases otherwhise this wat not mentioned. I guess this also catches mail containing words as Buy Viagra, call for sex and such things.
More content is probably (not sure) as counter measure to mailbombs or mails with lots of spaces, not sure about that.
I'm not worried about that text so I reather leave it as is, because I like things as default as possible..... if possible. ;)

Well, I like helping Kal...
That's no problem. I like it too. I just had to look if you wasn't posting the same as me because then I could cancel my post and prevent doublepost. :)
I don't think you make mistakes, or at least rather a few, so in that case you can help me with my mistakes too. :)
 
Thanks guys. You two need a stage name or something. ;)

That's for setting up DMARC on your own domains, which I've already done (and it works great). It doesn't address the issue of dealing with mail from other servers. It does open by saying that DMARC gives remote servers 'a better idea of what your intention is for messages that fail [DKIM and SPF]', but it doesn't say how DirectAdmin does that when it is the remote server.

I did see the other discussion you linked to, but it looked pretty full-on. I'd love to see ESF handle DMARC natively.

Because it's not ESF's task to check DMARC records and interfere with user settings for DMARC. … So it's not up to ESF to still block the mail then against the policy set by the user configuring DMARC.
I disagree. That's exactly what DMARC is supposed to do—inform the remote mail server what to do with mail that fails SPF and DKIM.

Next to that, on setting up DMARC, DA advises to use -all and not ~all on SPF.
That document is outdated IMO. (It was last updated in 2015.) It was the original intention of SPF to declare policy on how to deal with validation failures, but these days DMARC is the recommended way to do that. (See: What is the difference between SPF ~all and -all? and Myths and Legends of SPF.)

DMARC has three fundamental roles in validating email:
  1. It checks whether the domain of the header ‘from’ address (which is visible to the recipient) matches (aligns with) the domain of the sending address from the SPF check or the domain in the DKIM signature
  2. It declares a policy on how to handle messages that fail SPF, DKIM, and/or domain alignment.
  3. It can request that reports be emailed back to the administrator of the domain.
Number 2 is what we're talking about here, but number 1 could be a really useful addition to ESF as well.

… I like things as default as possible..... if possible.
Me too! Unless the default sucks… which it kind of does in the case of that message. Here, I'll try to be more constructive… This is my suggestion for a more professional and informative message…

Your message to <$recipients> was classified as SPAM. If this is a mistake, please contact your IT department or hosting provider and ask them to make sure your outgoing mail server is not on any blacklists and that it is configured correctly. Common errors include incorrectly configured SPF or DKIM records, or no reverse DNS lookup. Your spam score: $acl_m_easy69​

Wouldn't you agree, that would be a genuine improvement? Firstly it acknowledges that the spam assessment could be a 'mistake'. No one likes being told that their legitimate email is spammy. Secondly, it doesn't patronise the writer by telling them to add unnecessary words, or remove 'naughty words' when they probably haven't used any to begin with. Finally it clarifies the server config suggestions, with improved English.

Why does it matter? It matters because I'm seeing this message going out more than I would like, which tells me misconfigured mail servers are all too common. The most responsible thing we can do, as server admins, is to educate people, and that means choosing our words more carefully. How does it help things if we muddy the waters with unhelpful information like 'add more content, cut down on HTML links, use fewer naughty words'? If we're trying to help the spammers, maybe that's helpful! If we're trying to help legit users, not so much I would say.
 
Back
Top