New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Help me fix my email spoofing (MXRoute, Cloudflare, free beer if you find the issue)
Hello nerds,
Domain: ghost.org.za
Hosted: MXRoute
DNS: https://paste.bingner.com/paste/rqs64
I've checked:
- SPF
- DKIM
- DMARC
I've followed all the instructions I could find, yet when using mail spoofing tools I've found on Google, I am still able to receive mails sent to [email protected] from my own mail account.
Is anyone here able to assist in finding out what I'm missing?
Free beer to whoever spots the problem.
Mike Wazar
Comments
I don't understand what you're trying to accomplish or tell us,
Can you clarify this statement:
When using a tool such as https://www.kevlarr.io/email-test?lang=en
I enter my own email, and I receive an email that appears to have come from my own inbox as if I sent it from myself ([email protected]) to myself ([email protected]) which I understand as being spoofed. Am I incorrect?
Depends on the receiving side, if it checks for spf, dkim. Afaik, spf is relevant with google. Dkim/dmarc, blocking policy?
Maybe MXroute doesn't check for DMARC or doesn't enforce p=reject? You might want to check the headers in the mail
Thank you @FatGrizzly @LTniger and @sanvit - I will check.
Tried this for myself (I'm also on MXroute) and tried sending to my Gmail. Somehow, the SPF check is not being done on the domain but from
51.158.146.154
(Kevlarr's IP). It also passed DKIM, since Gmail checked with'PASS' with domain dmarc-checker.kevlarr.io
and not the DKIM in my actual domain.Interesting. I hope the solution is posted here if found, I would love to fix this on my end as well.
@jar - any input from your side?
You need to set DMARC policy to reject or quarantine.
https://dmarcian.com/dmarc-record-wizard/
I did, the record and policy set is outlined in the OP. Check the DNS records I posted.
To begin with, you probably do not want to use
rua=
andruf=
to human-readable e-mail addresses. They're not human-readable, they're reports meant to be consumed by a computer, since it's all sent in XML.ruf=
also includes personal identifying information, which means it'd be stored by Outlook. Mentioning this just in case.Everything else seems fine right now, anyway. https://www.kevlarr.io/email-test is already not allowing your e-mail address to be used, and it says it's well-protected, so something must have changed during the time you posted this.
Anyway, because of this, you should not worry about someone spoofing an e-mail from your address to another provider - validation will be done and since it won't even pass SPF to begin with... it should be rejected.
However, the issue that you are presenting is because MXroute is not validating the source when it comes from a registered domain. I can replicate it in my own service, too, which is on another node than London. It also works with sending from any address in the same mail server to other domains in there, which means that you could actually spoof e-mails. So no, it's definitely not validating SPF/DKIM/DMARC on their side. I don't think that's intended, @jar?
They're not spoofing, they're using an SRS-based envelope sender. I just tested their tool and here's the log entry:
The envelope sender was not [email protected], it was [email protected]. The From header is mostly considered cosmetic, the envelope sender is what matters and what is tested against at SMTP time. Makes perfect sense that 51.158.146.154 passed SPF for @dmarc-checker.kevlarr.io:
Looks to me like this is someone who has something to gain from telling you that your email system is broken, probably helps them generate business. Pretty convenient they won't let me test a Gmail address because I see no reason why that wouldn't "fail" just the same by their carefully shady "test." Nice way to lie to people and try to make a buck: https://www.kevlarr.io/kosten?lang=en
You are amazing. Thanks!
Took a second look at the Gmail email I received and yep, it has the
via
information. Makes perfect sense that it's using kevlarr's SPF and DKIM instead of my domain's.I just got an email about their sales team "seeing that I used their tool" and wants to do a sales pitch. Lol.
>
Yeah, me too. Good thing is that Rspamd allready got them them at around 8.x score without training
I mean, this seems like a pretty good reason to blacklist 51.158.146.154, doesn't it?
They got our emails because of misleading practices. I vote for slamming the blacklist hammer on it.
Nice explanation, thank you. That explains a bit from the service itself, at least.
So, how to mitigate srs based impersonation? Only by inspecting headers? In cisco cleanmail there is posibility to create rule against crap like this.
Tbh that sounds to me like a good way to create actual problems out of theoretical problems. Once you start getting into doing things like that, you're going to start breaking a lot of very legitimate and intended use cases.
That's why forwarding to Gmail can be problematic, because they do check DMARC against the From header, which means you usually can't even use SRS to forward emails from domains that have full reject in their DMARC record. On a rare occasion it might be helpful, but more often than not it just stops people from receiving things they wanted to and expected they would have.
That said, if you did want to force rejection based on the From header and it's correlation to DMARC, you could probably add this to your user_prefs file for SpamAssassin:
I "think" that will work.
But the whole point of DMARC is to check against the From header.
This reply sucked, I tried again below.
Let me try that reply again, I think I can do it better:
I do not globally enforce DMARC. SpamAssassin runs tests for it and users can adjust that as desired.
I do globally enforce SPF, which is tested against the envelope sender.
Unlike Gmail, I do care if users receive email that they forward from other services using SRS (even and especially email from PayPal, ebay, etc). And I don’t see an epidemic of users receiving SRS spam, but if I do we’ll talk.
But SRS forwarding wouldn't break a DKIM signature, so only those emails that only rely on SPF for DMARC would be affected (which, I guess, wouldn't include PayPal, ebay, etc.).