security check on inbound mail (SPF,DKIM, DMARC)

[martinw]

Hi,
I would like to request your input. I have a VPS-server who receives all mail for my domain. Directadmin is active with exim and spamassassin.
Mailflow in/out works fine but when testing with https://emailspooftest.com/ I am having doubts if incoming mails are tested.
Inbound testresults -- DMARC, SPF and DKIM test are failing. I get mail in the inbox when this shouldn't be accepted by the mailserver.

I checked the exim logs but can't find evidence in logfiles of security checks like DMARC, SPF, DKIM. (/etc/log/exim - mail/panic/reject.log)

Are the tests performed?
What has to be changed to enable inbound security checks?

Testresults of emailspoof:
SPF is not enforced.
Fix: Set email systems to reject email from servers that fail SPF checks.
DNS Settings for badSPF.com

This email should have been rejected by strict DKIM enforcement.
Fix: On inbound email systems set DMARC alignment for DKIM restrictions to deny email without a DKIM signature for domains that require DKIM via DMARC.
DNS Settings for badDKIM.com

This email should have been rejected by DMARC enforcement. DMARC Reject & SPF Deny All senders from this domain.
Fix: set inbound email servers to check DMARC for subdomains
DNS Settings for badDMARC.com

 

[Richard G]

I don't know for sure, in my case E1 went into inbox and E5 too. All others were green.
But there are totally no SPF, DKIM or DMARC entry's in the headers of that E5 mail.
Since they configured SPF as neutral and they did not sign with DKIM but they do have a DKIM record, the DMARC record should have taken care that the mail was refused.

So it seems indeed something is not checking as should be.

 

[martinw]

I don't know for sure, in my case E1 went into inbox and E5 too. All others were green.
But there are totally no SPF, DKIM or DMARC entry's in the headers of that E5 mail.
Since they configured SPF as neutral and they did not sign with DKIM but they do have a DKIM record, the DMARC record should have taken care that the mail was refused.

So it seems indeed something is not checking as should be.

Exactly, overall score was very bad. Normal mailflow goes oke (duhh) and other categories were F-grade. (worst grade)

What is wrong?
Can we reproduce with another test site?

 

[Active8]

OK, just tested on few servers of mine and managed to have only E1 in the inbox (that means that the filters works well )


What I did:
1. Install mailbaby rspamd rules here
2. Delete list.dnswl.org mentioned here (not sure if it helped or not but it looks to me that it would not hurt)

I know that that the topic starter use spamassassin but maybe this can help others

 

[Richard G]

So it seems rspamd with custom rules does a better check than exim with spamassassin at DA.
Because we get E5 also.

 

[mxroute]

The thing is, the base configuration has to be designed in the way that generates the least number of support requests. Allowing spoofed email generates less support requests than disallowing it. I know it's insane, but you have to think about the average hosting customer. They're not like us. Most of them have no idea what SPF or DKIM is, they want to send mail from every application they've every hosted anywhere, and they want it to land in their inbox without a second thought. For this reason, you'll want to tweak your spam filters more to your liking from the defaults.

I highly recommend reading over this. It's extensive, but you'll have a much better idea of what you want to do afterward: https://docs.directadmin.com/other-hosting-services/preventing-spam/incoming-spam.html

Most specifically I would call attention to this section: https://docs.directadmin.com/other-...asyspamfilter-threshold-for-rdns-dkim-and-spf

That section focuses on the opposite of what you want, but there's no reason you can't take what it shows there and go in the reverse direction. Increase those numbers, you're going to get less spoofed email.

 

[Richard G]

That section focuses on the opposite of what you want, but there's no reason you can't take what it shows there and go in the reverse direction. Increase those numbers, you're going to get less spoofed email.

That is not what we're talking about.

The problem here is that we have take such measures, but for incoming mail things like DMARC are not even checked.
That has nothing to do with lowering or raising values in ESF. And I already adjusted them to a higher value in the past.

But if a DMARC record isn't even checked, like in this test, then there must be something wrong and we can't find out where exactly.

The thing is, the base configuration has to be designed in the way that generates the least number of support requests.

I disagree about that. It's checking incoming mail. And if the sender is not using any DMARC or DKIM, there is no reason for support request as there will be no issue for the avarage hosting customer. No SPF/DKIM/DMARC in DNS then no check is done, no problem with the mail.
So imho it has nothing to do with average hosting customer.

If the sender IS using DKIM and DMARC, then this should be checked, which does not seem the case.
And that is our problem.

 

[mxroute]

That is not what we're talking about.

Thread title says "SPF,DKIM, DMARC", the content of the original post backs that up, and that link shows you how to edit the scores for ESF (which bridges exim and Rspamd) that directly relate to how it handles checks for SPF and DKIM, so I fail to see what you're on about. If you don't want me to offer advice feel free to message me that.

DMARC isn't anything other than telling you how to handle SPF and DKIM anyway, it's not a third enforcement mechanism but extended context for the other two.

As for the rest, the average hosting customer doesn't even know if or that they have these things (which they may to some degree by default by setting their NS to your DirectAdmin server, which is quite a standard expectation for a hosting company running DA). I'm obviously not talking about customers who explicitly go out of their way to not have SPF or DKIM, but the ones who don't know what they do or don't have and just want their random shit to work from their various hosted applications and SaaS applications that they lazily configure. Do you just like arguing or do you honestly not know what you're talking about?

I was a sysadmin at HostGator, DigitalOcean, and I have nearly 17,000 customers on a fleet of DA servers. I'd appreciate it if you'd stop talking to me like I don't know what I'm talking about Richard. I know exactly what creates more or less support tickets at scale, and I know exactly why those things happen.

 

[Richard G]

Thread title says "SPF,DKIM, DMARC", the content of the original post backs that up,

Where does the original post backs that up? I don't understand.
It says the test are failing on DMARC which should not fail. There is not a question about scores, but question why DMARC is not checked by our systems.

Ofcourse you should know I really appreciate your advise as you are very good in mail stuff and you helped me with some odd issue before. In other posts I also referenced to you as being more specialistic on this part.
So no problem there. I think we have a misunderstanding somewhere. Sorry if you feel offended that was certainly not my intention.

I just have a hard time to believe that only doing a SPF and DKIM check on incoming mail would raise that many tickets as I've seen 0 in my 14 years of hosting. And logically one can adjust settings for how hard you want to do the check. But the issue is no DMARC check is done at all!

DMARC isn't anything other than telling you how to handle SPF and DKIM anyway, it's not a third enforcement mechanism but extended context for the other two.

Exactly. So if DMARC is telling you that DKIM should be handled strict, and no DKIM is even found in the mail, then the mail should be refused, right?
And that is not what is happening, mail is arriving while it should not.
Now there is no DMARC in the header of that test mail, neither there is a DKIM record.
Unless Exim or ESF or Spamassassin never check for DMARC if there is no DKIM or DMARC record in the headers, then something seems wrong here.
It works correctly on rspamd with some rules, why not in DA?

Odd thing is that when there -is- a DKIM record present in the headers, the DKIM is checked.

I don't see how that could be improved by changing ESF values you linked to, that would only make the spam check more or less strict. It does not decide if there is a check done for DMARC or not as far as I know.
That is what we are talking about. Maybe I'm more clear now, or maybe now you can see that I'm missing something here or why I might go wrong if that is the case.

I don't know for Martinw but I have a default ESF and this custom file:
EASY_LIMIT == 50
EASY_DKIM_PASS == -30
EASY_DNS_BLACKLIST == 100

Now there is no DMARC in the header of that test mail, neither there is a DKIM record.

Again, sorry if I offended you, that was certainly not my intention, because I really respected you before and I still do.

 

[mxroute]

Where does the original post backs that up?

The original post here shows that SPF and DKIM are not being used to reject email, and that this is the root of the problem:

Inbound testresults -- DMARC, SPF and DKIM test are failing

Which makes sense, if you're trying to avoid receiving spoofed emails and you want to receive better results on a check like emailspooftest.com, you're going to want to increase the amount of email you reject based on SPF and DKIM failure. The tests make that clear:

Testresults of emailspoof:
SPF is not enforced.
Fix: Set email systems to reject email from servers that fail SPF checks.
DNS Settings for badSPF.com

This email should have been rejected by strict DKIM enforcement.
Fix: On inbound email systems set DMARC alignment for DKIM restrictions to deny email without a DKIM signature for domains that require DKIM via DMARC.

Now of course to get more specific into how the DMARC record suggests handling of DKIM you're going to want to move a bit further into things, but the number of emails that pass SPF and lack DKIM headers while the domain declares that anything lacking DKIM should be rejected isn't significant even for my exceptionally busy servers, so I doubt the average user is going to see a difference from focusing too heavily on that. If it passes SPF and has DKIM headers, then it still has to pass the DKIM test. So for DMARC to really matter there where ESF's SPF/DKIM checks wouldn't be sufficient, to be clear, would only be when SPF passes and there are no DKIM headers. Now my mail servers are busier than an oversold HostGator server and I can tell you that edge case isn't going to be one that makes any noteworthy difference. Certainly, it won't be something that pays you back for the time spent worrying about it.

So what you really want to do, to make a blanket action that impacts this heavily, is to make sure that both EASY_SPF_FAIL and EASY_DKIM_FAIL, independently, reach a score equal to EASY_HIGH_SCORE_DROP. So set both to 100 (as EASY_HIGH_SCORE_DROP is 100 by default), trust me you're not going to be seeing any spoofed email in the real world unless something isn't working as intended or the envelope sender wasn't actually what you thought it was (it doesn't have to match the From header, for example).

Personally, I set EASY_SPF_FAIL to 100 and EASY_DKIM_FAIL to 50, with EASY_HIGH_SCORE_DROP set to 150. This is because of what I was talking about with average users. Now you might have 5,000 or 10,000 customers and never see a ticket about this, you only need 5-10 users to drive you insane over it and start harassing you because they don't even know that they have SPF/DKIM defined by their DNS host and they just setup Random Support Ticket SaaS Notification App #587 to send email to themselves from their domain and it's driving them crazy. If you have a lot of small to medium SMBs that are slightly more tech focused with an international customer base, you start to see these types pop up more often than local coffee shops, restaurants, things like that. So like your SEO outfits, your web designers, your small time "app developer as a service" bunch, these are where that complaint pops up more if you enforce SPF/DKIM too strictly. You can argue that they're unreasonable for not wanting it enforced and you wouldn't be crazy, but it's also not crazy to not want to have to explain this to people every day because time = money and reducing support overhead can be more valuable than a slight increase in spoofed email, depending on the situation.

All that said, I'm pretty sure ESF can do something with DMARC if you really do want to go there, but I can't find any official documentation on it. You'll notice in variables.conf this bad boy right here:

.include_if_exists /etc/exim.easy_spam_fighter/variables.dmarc.conf

Now if exim could handle DMARC before Rspamd has to step in then we're done here right, that's the highest level solution in the stack. But the only documentation I can find on that file is this tutorial from 2018:

Integrate OpenDMARC with Exim to have DMARC checked and report sent out

Hi everyone, in last few days I have been playing around with DMARC because I wanted to be able to check it, and report it as many providers are already doing, so I started to work on it using OpenDMARC. Here it is a small How-To that will help you to make this integration, depending on the...

forum.directadmin.com

Now that tutorial may well function perfectly and may well be the perfect solution if you really want to hit that edge case where SPF passes, DKIM headers aren't in the email, and DMARC says to reject it without DKIM. I still think that's heavy handed, but to each their own. Of course Rspamd can handle DMARC stuff as well. Defaults should usually be lenient with room for admins to increase things, that's just a good practice when you don't want to scale up support too hard. Especially for DA themselves, if not the hosts. Because if the defaults are too heavy handed, DA devs are going to get more tickets than they do about users receiving too much spam. It's just natural that people run to the devs faster for "I'm not receiving important emails" than they do for "I'd like to receive less of these other emails." One feels like an emergency, the other feels like a feature request.

Again, sorry if I offended you, that was certainly not my intention, because I really respected you before and I still do.

You know I love you Richard.

 

[Richard G]

but the number of emails that pass SPF and lack DKIM headers while the domain declares that anything lacking DKIM should be rejected isn't significant

Correct, that was only used for testing to see if the mail would be refused. Normally one would not encounter such mail very soon.
It's just that maybe like @martinw, if it should work, I like it to work. Unless ofcourse it would take too much time. But sometimes for some things I'm just a bit of ... how is it called in English... hmz... kind of a perfectionist, even if the result doesn't matter much. Not always the smartest choice ofcourse.

you only need 5-10 users to drive you insane over it and start harassing you because they don't even know that they have SPF/DKIM defined by their DNS host

Whahaha LoL, I know. Even if I had 0 complaints, we recently had a whole team of voluntairy helpers on the ISP forums and some mods trying to figure out a guys issue why he wasn't able anymore to send mail via the big ISP's smtp server. Which was working before all the time.
He drove everybody crazy, and it was just by chance that I remembered to have him checked for SPF and DKIM... check what? Yeah lol indeed. So that was the cause, his provider changed ~all to -all and end of sending mail via the home ISP.
Indeed sometimes it takes only a few to make a support department go wild, no doubt about that.

I can understand with the many different kind of businesses you have to deal with, that in your case it's a totally different situation, as we mostly have the kind of average customers and businesses with wordpress sites and forums and that kind of stuff, no Sasl or whatever.

It's just natural that people run to the devs faster for "I'm not receiving important emails" than they do for "I'd like to receive less of these other emails." One feels like an emergency, the other feels like a feature request.

Yes you're right about that. Luckily I didn't have much of the "I'm not receiving important emails" tickets, but in that case I also feel the emercency to investigate why, and take care they can receive those mails, if it would not mean we will have a lot of more spam.

Thank you for your thorough (like always) explanation of these things and combined with your insights to it. Makes things clearer and less to worry about.

In summary can we say that what the mail said (the one with the DMARC not checked/enforced) stating:

This email system failed to reject this fraudulent email.
This security issue can be used to compromise users.

We can safely ignore (at least now) because such kind of mails will almost never see the light of day, so not to worry about it. Is that correct?
Because enforcing this, if I read correctly, will be a lot of work, or one will have to change from Spamassassin to Rspamd which we don't like to do for the time being.

You know I love you Richard.

That goes both ways as you know!

Thank you again!

 

[Richard G]

You'll notice in variables.conf this bad boy right here:

Ofcourse I still was a bit curious and I found someting about that one:

Index of /services/easy_spam_fighter/dmarc/check_dmarc/

It contains a file called check_dmarc-1.0.conf with this content:

#DMARC Checks
#VERSION=1.0
  warn
    dmarc_status         = accept : none : off
    !authenticated       = *
    log_message          = DMARC DEBUG: $dmarc_status $dmarc_used_domain

  warn
    dmarc_status         = !accept
    !authenticated       = *
    log_message          = DMARC DEBUG: '$dmarc_status' for $dmarc_used_domain

  warn
    dmarc_status         = quarantine
    !authenticated       = *
    set acl_m_quarantine = 1
    # Do something in a transport with this flag variable

  deny
    condition            = ${if eq{$dmarc_domain_policy}{reject}}
    condition            = ${if eq{$acl_m_mailing_list}{1}}
    message              = Messages from $dmarc_used_domain break mailing lists

  deny
    dmarc_status         = reject
    !authenticated       = *
    message              = Message from $dmarc_used_domain failed sender's DMARC policy, REJECT

  warn
    add_header           = :at_start:${authresults {$primary_hostname}}

I'm not sure what exactly this will do, if this is the file neede for checking DMARC records and if this is to be renamed to variables.dmarc.conf because unfortunately as you also discovered... no documentation to be found.
Is it only checking incoming or doing outgoing... or doing something completely different, I don't know.

But I posted it, maybe you find this interesting too.