Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Help me fix my email spoofing (MXRoute, Cloudflare, free beer if you find the issue)
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.

Help me fix my email spoofing (MXRoute, Cloudflare, free beer if you find the issue)

mikewazarmikewazar Member
edited April 2023 in General

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

  • FatGrizzlyFatGrizzly Member, Host Rep

    I don't understand what you're trying to accomplish or tell us,

    Can you clarify this statement:

    I am still able to receive mails sent to [email protected] from my own mail account.

    Thanked by 1mikewazar
  • @FatGrizzly said:
    I don't understand what you're trying to accomplish or tell us,

    Can you clarify this statement:

    I am still able to receive mails sent to [email protected] from my own mail account.

    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?

  • LeviLevi Member
    edited April 2023

    Depends on the receiving side, if it checks for spf, dkim. Afaik, spf is relevant with google. Dkim/dmarc, blocking policy?

    Thanked by 1mikewazar
  • Maybe MXroute doesn't check for DMARC or doesn't enforce p=reject? You might want to check the headers in the mail

    Thanked by 1mikewazar
  • 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.

  • @definitelyliam said:
    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?

  • amarcamarc Veteran

    You need to set DMARC policy to reject or quarantine.

    https://dmarcian.com/dmarc-record-wizard/

    Thanked by 1mikewazar
  • @amarc said:
    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.

  • JeDaYoshiJeDaYoshi Member
    edited April 2023
    TXT _dmarc.ghost.org.za. 5m00s   "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s;"
    

    To begin with, you probably do not want to use rua= and ruf= 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?

    Thanked by 1mikewazar
  • jarjar Patron Provider, Top Host, Veteran
    edited April 2023

    They're not spoofing, they're using an SRS-based envelope sender. I just tested their tool and here's the log entry:

    2023-04-08 13:42:30 1pl8po-00DQGu-1w <= [email protected] H=dmarc-checker.kevlarr.io [51.158.146.154] P=esmtps X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=no S=17933 DKIM=dmarc-checker.kevlarr.io [email protected] T="Kevlarr - The spoofing result" from SRS0=STQw=77=mxroute.com=jarland@dmarc-checker.kevlarr.io for [email protected]

    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:

    jarlanddonnell@Jarlands-Air ~ % dig TXT dmarc-checker.kevlarr.io +short | grep spf
    "v=spf1 ip4:51.158.146.154 include:spf-breaks-email.bit.nl -all"

    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

  • @jar said:
    They're not spoofing, they're using an SRS-based envelope sender. I just tested their tool and here's the log entry:

    2023-04-08 13:42:30 1pl8po-00DQGu-1w <= [email protected] H=dmarc-checker.kevlarr.io [51.158.146.154] P=esmtps X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=no S=17933 DKIM=dmarc-checker.kevlarr.io [email protected] T="Kevlarr - The spoofing result" from SRS0=STQw=77=mxroute.com=jarland@dmarc-checker.kevlarr.io for [email protected]

    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:

    jarlanddonnell@Jarlands-Air ~ % dig TXT dmarc-checker.kevlarr.io +short | grep spf
    "v=spf1 ip4:51.158.146.154 include:spf-breaks-email.bit.nl -all"

    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!

    Thanked by 1jar
  • 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.

    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

    I just got an email about their sales team "seeing that I used their tool" and wants to do a sales pitch. Lol.

    Thanked by 1jar
  • amarcamarc Veteran

    @definitelyliam said: 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

    Thanked by 1jar
  • jarjar Patron Provider, Top Host, Veteran

    I mean, this seems like a pretty good reason to blacklist 51.158.146.154, doesn't it?

  • @jar said:
    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.

    Thanked by 3jar mikewazar dystopia
  • JeDaYoshiJeDaYoshi Member
    edited April 2023

    @jar said:

    Nice explanation, thank you. That explains a bit from the service itself, at least.

    Thanked by 1jar
  • LeviLevi Member
    edited April 2023

    So, how to mitigate srs based impersonation? Only by inspecting headers? In cisco cleanmail there is posibility to create rule against crap like this.

    Thanked by 1jar
  • jarjar Patron Provider, Top Host, Veteran
    edited April 2023

    @LTniger said:
    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.

    Thanked by 1Levi
  • jarjar Patron Provider, Top Host, Veteran
    edited April 2023

    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:

    score KAM_DMARC_REJECT 100

    I "think" that will work.

    Thanked by 1Levi
  • @jar said: 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.

    But the whole point of DMARC is to check against the From header.

    DMARC protects the domain name of the RFC5322:From field against spoofing.

  • jarjar Patron Provider, Top Host, Veteran
    edited April 2023

    This reply sucked, I tried again below.

  • jarjar Patron Provider, Top Host, Veteran

    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.

  • @jar said: 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).

    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.).

Sign In or Register to comment.