Koozali.org: home of the SME Server

Spoofed local address ignores SME SPF, DKIM and DMARC policy

Offline CmdLn

  • **
  • 57
  • +0/-0
Spoofed local address ignores SME SPF, DKIM and DMARC policy
« on: August 17, 2017, 09:01:37 AM »
We often get messages with spoofed from address that are in our own domain. eg Mail From:someone@sme-mail-domain.foo To:someone@sme-mail-domain.foo

I have noticed that in the message headers for these messages our SPF, DKIM and DMARC DNS records are ignored. The headers say something like authentication-results: spf=none dkim=none, however this is not the case and these records exist in public DNS. I am guessing this is because these records are not SME's version of the DNS records for our email domain. Is there a way add these records to SME's DNS?

Offline mmccarn

  • *
  • 2,627
  • +10/-0
Re: Spoofed local address ignores SME SPF, DKIM and DMARC policy
« Reply #1 on: August 17, 2017, 02:27:20 PM »
Specific answer:
djbdns uses a single quote in its root data file to indicate a TXT record (according to http://thedjbway.b0llix.net/djbdns/tinydns-data.html )

To create your own TXT record, you will need to create a custom template fragment because tinydns reloads the templated config every time it restarts and there is no db setting to create TXT records that I know of.

I'm guessing, but I think this would do it for you:
Code: [Select]
mkdir -p /etc/e-smith/templates-custom/var/service/tinydns/root/data/
cd /etc/e-smith/templates-custom/var/service/tinydns/root/data/
echo "'sme-mail-domain.foo:v=spfv1 blah blah blah -all:7200:" >81SPF
sv t tinydns
sv t dnscache
* I picked "81..." to put the new txt record at the end of the tinydns data file, after the "80..." entry created by Sogo on my server
* adjust the content of 81SPF to fit your configuration
* sme-mail-domain.foo must be defined as a domain on the SME server or tinydns won't respond to queries for the domain

Remove this customization using:
Code: [Select]
'rm' /etc/e-smith/templates-custom/var/service/tinydns/root/data/81SPF
sv t tinydns
sv t dnscache

More notes not addressing your specific question...
There are so many factors that could be involved in your issue.

Are you using fetchmail?  If so, are your SPF, DKIM, DMARC records recognized by the server that the email is delivered to?

If not, are your SPF, DKIM and DMARC records recognized by your SME server itself?  That is, at the SME server shell, do you get what you expect if you check "nslookup -type=txt sme-mail-domain.foo"?

If that's all right, does your SME server require authentication for email relay("config getprop qpsmtpd RelayRequiresAuth")? Have any of your accounts been compromised?

Are your local networks set appropriately/securely, or have you modified the local networks to solve some other problem (thereby possibly allowing unauthenticated relay)? Review qpsmtpd's sense of what is local using "ls -l /var/service/qpsmtpd/config/peers"

Have you looked at /var/log/qpsmtpd/current to see what is actually happening when one of these messages is received?  (You might find that the problem is a compromised workstation or network device, for example...) Some pointers can be found at https://wiki.contribs.org/Mail_log_file_analysis

Are you running any web applications (drupal, wordpress, etc) on your SME server?  If so, are they patched and up-to-date, or could one of them have been compromised by an attacker? A compromised web app might appear in qpsmtpd/current as an email source of "127.0.0.1", or your server's LAN IP.



Offline CmdLn

  • **
  • 57
  • +0/-0
Re: Spoofed local address ignores SME SPF, DKIM and DMARC policy
« Reply #2 on: August 17, 2017, 04:47:12 PM »
I was able to add the records according to your template instructions. I used the following site to generate the records. https://anders.com/projects/sysadmin/djbdnsRecordBuilder

I am not sure how to test this? It seems I would need to setup and open relay to accept the message which is a lot of effort. I will probably just monitor the system for the next spoofed from address, although if this works that message should be blocked in theory. I suppose I could relax the DMARC policy internally.