emailspooftest results and fails

PaleForest ●

I have the same concern. Does this means that I cannot trust the "from" field in mailbox.org to know if it’s a legitimate email as it can be spoofed? And there’s no warning or anything.

I wanted to increase my spam protection settings but it seems like those emails would just get rejected instead of landing in spam: "Whenever an e-mail has been flagged as spam by our systems, it will be rejected. That means our server will deny accepting the e-mail message and the system at the other end (the client) will issue a delivery failure notice to the sender (the message „bounces“)." Source

Reply URL

This comment is in trash! Restore

1

grass glass ●

Hello, I'm a new mailbox.org user with similar concerns.

Regarding your concern, mailbox.org actually had a literal 6 year long vulnerability (first still-existing English report on the forums I could find), where you could send email as another mailbox.org user. But, this appears to have been fixed, at least from basic attacks, as shown by EM's post and mine.

Regarding the E9 email of emailspooftest.com passing through, I believe that is not necessarily as concerning as the wording of the email might seem. First, let me do a slight recap on DMARC: you can set

p=reject

to instruct mailservers to reject any email, whose sender claims to be from your domain, but fails SPF and DKIM checks. So, a properly configured mailserver --- in accordance with the RFC specs --- would not have allowed the email through to the end-user (recipient). You can't control whether your recipients' mailservers are compliant or not, so I don't think this is something you can do anything about and isn't mailbox.org's fault (whether recipients are spoof resistant when the sender alleges to be from your domain). However, it --- E9 passing through --- is the fault of mailbox.org for having mailservers that don't comply with the DMARC records of their users' domains.

Now for the rest of the emails E3, E5, and E7. First, E5 (no DKIM and no SPF); we see that

$ dig _dmarc.baddkim.com TXT
...
_dmarc.baddkim.com.	3600	IN	TXT	"v=DMARC1; p=reject; rua=mailto:baddkim@ignitecyber.co; ruf=mailto:baddkim@ignitecyber.co; fo=1:d:s; adkim=s; aspf=r; sp=reject"
...

so, again, it seems to be a similar issue of mailbox not respecting DMARC records. But this time, instead of disrespecting the mailbox user's DMARC records, its disrespecting the sender's DMARC records.

Now, onto E7 (failed SPF + no DKIM):

$ dig _dmarc.badspf.com TXT
...

We see that no DMARC record is present. In this situation (and more generally when SPF and DKIM validation fails), the recieving mailserver should reject the email or at least quarantine it in spam, for spam and phishing protection, to my understanding.

Lastly, E3 (failed SPF + no DKIM):

$  dig _dmarc.baddmarc TXT
...

Same as above.

As a user, there are further actions you can take to protect yourself from spoofed emails. I use FairEmail (FOSS) on Android; here, you can enable

Settings -> Display -> Advanced -> Show authentication warnings -> Show authentication status indicator

which shows a different symbol for differing levels of compliance with 'best' email practices. Furthermore, tapping on the icon tells you exactly which security features passed and which did not; DKIM, SPF, DMARC, and TLS are all indicated. It also shows a warning, in the form of a yellow flag icon, when DMARC authentication doesn't pass. Enabling these features should give you a very robust indication of the validity of inbound mail.

Furthermore, you can even enforce that FairEmail must connect to the respective IMAP and SMTP servers only with successful DNSSEC and DANE validation, in addition to the default (non-opportunistic) TLS connection used. From what I've gathered, its pretty rare to mess with TLS certificates successfully (i.e. without alarms blaring off), so its unlikely that you will end up in a situation to need DANE's protection. But more security at the flick of a button*? Why not, right?

If I got anything wrong, please correct me. I'm not an expert in any subfield of computing, and certainly not email. I'm just a layperson who has been reading up and setting up my own custom domain email. But, I hope my response was useful!

*Tangent. If you connect to a network whose DNS resolvers are DNSSEC incapable, you will get errors on DANE validation, if you enforced DANE validation. (You can check that your DNS resolver is DNSSEC incapable with https://dnscheck.tools/.) In my case, I discovered that my mobile network

1. Uses a DNSSEC incapable DNS resolver by default

2. Seems to block DNS-over-TLS lol

That's no problem, though. Just use another DNS resolver. On my Android phone, I'm using personalDNSfilter, which allows you to both

1. Use whatever DNS resolver you want over whatever protocol (UDP/DoT/DoH).

2. Enforce a domain blocklist (e.g. for adblock and anti-tracking)

Hello, I'm a new mailbox.org user with similar concerns.

Regarding your concern, mailbox.org actually had a literal 6 year long vulnerability (first still-existing English report on the forums I could find), where you could send email as another mailbox.org user. But, this appears to have been fixed, at least from basic attacks, as shown by EM's post and mine.

Regarding the E9 email of emailspooftest.com passing through, I believe that is not necessarily as concerning as the wording of the email might seem. First, let me do a slight recap on DMARC: you can set

p=reject

to instruct mailservers to reject any email, whose sender claims to be from your domain, but fails SPF and DKIM checks. So, a properly configured mailserver --- in accordance with the RFC specs --- would not have allowed the email through to the end-user (recipient). You can't control whether your recipients' mailservers are compliant or not, so I don't think this is something you can do anything about and isn't mailbox.org's fault (whether recipients are spoof resistant when the sender alleges to be from your domain). However, it --- E9 passing through --- is the fault of mailbox.org for having mailservers that don't comply with the DMARC records of their users' domains.

Now for the rest of the emails E3, E5, and E7. First, E5 (no DKIM and no SPF); we see that

$ dig _dmarc.baddkim.com TXT
...
_dmarc.baddkim.com.	3600	IN	TXT	"v=DMARC1; p=reject; rua=mailto:baddkim@ignitecyber.co; ruf=mailto:baddkim@ignitecyber.co; fo=1:d:s; adkim=s; aspf=r; sp=reject"
...

so, again, it seems to be a similar issue of mailbox not respecting DMARC records. But this time, instead of disrespecting the mailbox user's DMARC records, its disrespecting the sender's DMARC records.

Now, onto E7 (failed SPF + no DKIM):

$ dig _dmarc.badspf.com TXT
...

We see that no DMARC record is present. In this situation (and more generally when SPF and DKIM validation fails), the recieving mailserver should reject the email or at least quarantine it in spam, for spam and phishing protection, to my understanding.

Lastly, E3 (failed SPF + no DKIM):

$  dig _dmarc.baddmarc TXT
...

Same as above.

As a user, there are further actions you can take to protect yourself from spoofed emails. I use FairEmail (FOSS) on Android; here, you can enable

Settings -> Display -> Advanced -> Show authentication warnings -> Show authentication status indicator

which shows a different symbol for differing levels of compliance with 'best' email practices. Furthermore, tapping on the icon tells you exactly which security features passed and which did not; DKIM, SPF, DMARC, and TLS are all indicated. It also shows a warning, in the form of a yellow flag icon, when DMARC authentication doesn't pass. Enabling these features should give you a very robust indication of the validity of inbound mail.

Furthermore, you can even enforce that FairEmail must connect to the respective IMAP and SMTP servers only with successful DNSSEC and DANE validation, in addition to the default (non-opportunistic) TLS connection used. From what I've gathered, its pretty rare to mess with TLS certificates successfully (i.e. without alarms blaring off), so its unlikely that you will end up in a situation to need DANE's protection. But more security at the flick of a button*? Why not, right?

If I got anything wrong, please correct me. I'm not an expert in any subfield of computing, and certainly not email. I'm just a layperson who has been reading up and setting up my own custom domain email. But, I hope my response was useful!

*Tangent. If you connect to a network whose DNS resolvers are DNSSEC incapable, you will get errors on DANE validation, if you enforced DANE validation. (You can check that your DNS resolver is DNSSEC incapable with https://dnscheck.tools/.) In my case, I discovered that my mobile network

1. Uses a DNSSEC incapable DNS resolver by default

2. Seems to block DNS-over-TLS lol

That's no problem, though. Just use another DNS resolver. On my Android phone, I'm using personalDNSfilter, which allows you to both

1. Use whatever DNS resolver you want over whatever protocol (UDP/DoT/DoH).

2. Enforce a domain blocklist (e.g. for adblock and anti-tracking)

URL

This comment is in trash! Restore

1

grass glass ●

Correction for E3:

$ dig _dmarc.baddmarc.com TXT
...
_dmarc.baddmarc.com.	3600	IN	TXT	"v=DMARC1; p=reject; rua=mailto:baddmarc@ignitecyber.co; ruf=mailto:baddmarc@ignitecyber.co; fo=1:d:s; adkim=s; aspf=s; sp=reject"
...

Its the same issue with mailbox.org as E5, I believe.

Oh, and also, you can add some rules to have higher phishing protection, by automatically flagging out mails with any one of SPF, DKIM, or DMARC failing.

One reason why mailbox.org might not enforce

p=reject

is that they're trying to minimise the number of rejected legitimate mails (with misconfigured DNS records), which could pose a headache to end-users of mailbox.org who are confused why they're not recieving critical emails. But perhaps mailbox.org should consider directing such mails to spam instead, to strike an arguably better balance, since these mails now have no direct indication of being suspicious.

Correction for E3:

$ dig _dmarc.baddmarc.com TXT
...
_dmarc.baddmarc.com.	3600	IN	TXT	"v=DMARC1; p=reject; rua=mailto:baddmarc@ignitecyber.co; ruf=mailto:baddmarc@ignitecyber.co; fo=1:d:s; adkim=s; aspf=s; sp=reject"
...

Its the same issue with mailbox.org as E5, I believe.

Oh, and also, you can add some rules to have higher phishing protection, by automatically flagging out mails with any one of SPF, DKIM, or DMARC failing.

One reason why mailbox.org might not enforce

p=reject

is that they're trying to minimise the number of rejected legitimate mails (with misconfigured DNS records), which could pose a headache to end-users of mailbox.org who are confused why they're not recieving critical emails. But perhaps mailbox.org should consider directing such mails to spam instead, to strike an arguably better balance, since these mails now have no direct indication of being suspicious.

URL

This comment is in trash! Restore

emailspooftest results and fails

Replies (1)