I’ve been getting these “Your account is hacked! Modify your pswd right away!” emails sent from myself (so from:chris@hichris.com, to:chris@hichris.com). Source of email here. My understanding is that the spf record on my domain (hichris.com) is set so that only MIAB (box.neonorb.com) can send email, so why aren’t these dropped or sent to spam?
I’m seeing this too - I have inbound messages with fake from address, SPF failure, no DKIM, strict DMARC settings with a 100% signing and reject policy, spam rating of 19.2 (including hits on blacklists) - and they still make it to my inbox. What’s the point of ignoring a DMARC reject policy? Is there some policy set to only mark messages as spam rather than rejecting them?
Here’s a set of example headers:
Return-Path: <regis@baladamixrestaurante.com.br>
Delivered-To: user@example.com
Received: from mail.example.co.uk ([127.0.0.1])
by mail.example.co.uk with LMTP id kI9GCANkbFxwLgAAcuvPBw
for <user@example.com>; Tue, 19 Feb 2019 20:16:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
mail.example.co.uk
X-Spam-Flag: YES
X-Spam-Level: *******************
X-Spam-Status: Yes, score=19.2 required=5.0 tests=BAYES_00,BITCOIN_EXTORT_01,
BITCOIN_SPAM_02,BITCOIN_SPAM_03,BITCOIN_SPAM_07,FORGED_MUA_MOZILLA,
LOCALPART_IN_SUBJECT,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_SBL_CSS
autolearn=no autolearn_force=no version=3.4.2
X-Spam-Report:
* 3.3 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
* [177.126.159.149 listed in zen.spamhaus.org]
* -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000]
* 1.1 LOCALPART_IN_SUBJECT Local part of To: address appears in
* Subject
* 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in
* bl.spamcop.net
* [Blocked - see <https://www.spamcop.net/bl.shtml?177.126.159.149>]
* 5.0 BITCOIN_EXTORT_01 Extortion spam, pay via BitCoin
* 2.5 BITCOIN_SPAM_03 BitCoin spam pattern 03
* 3.0 BITCOIN_SPAM_07 BitCoin spam pattern 07
* 2.5 BITCOIN_SPAM_02 BitCoin spam pattern 02
* 2.3 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla
X-Spam-Score: 19.2
X-Greylist: delayed 902 seconds by postgrey-1.36 at mail.example.co.uk; Tue, 19 Feb 2019 19:30:59 UTC
Authentication-Results: mail.example.co.uk; dmarc=fail (p=reject dis=none) header.from=example.com
Received: from hm1481-23.locaweb.com.br (hm1481-23.locaweb.com.br [201.76.49.145])
by mail.example.co.uk (Postfix) with ESMTP id 86C0B601FE
for <user@example.com>; Tue, 19 Feb 2019 19:30:59 +0000 (UTC)
Received: from mcbain0015.correio.biz (201.76.49.38) by hm1481.locaweb.com.br id hdhcn0169v07 for <user@example.com>; Tue, 19 Feb 2019 16:15:46 -0300 (envelope-from <regis@baladamixrestaurante.com.br>)
Received: from proxy.email-ssl.com.br (bartf0041.email.locaweb.com.br [10.31.120.73])
by mcbain0015.correio.biz (Postfix) with ESMTP id 40F6640033A
for <user@example.com>; Tue, 19 Feb 2019 16:15:48 -0300 (-03)
x-locaweb-id: F03MVIvp7JRyLbgqNlYTsPtCf7chdLMdJ31cXwqroOWHwvZztVgfsX8J1N6Zjv08QlQJR8mbyvdx7GFu2zBjgv0HnVXNkKEo03Rs0aserwx71eKRmnbstvojIxBrPXv2DgDiRoJYevi4Y4_MGR0z5SIRNuR4dOcN9LqbHh_IAtojsclvD0pAzQnJtkg_3UW8gG_gMt9Tt-Phg3Gzta1POFr0aIIdrW67Tcq6_rPEjgo= NzI2NTY3Njk3MzQwNjI2MTZjNjE2NDYxNmQ2OTc4NzI2NTczNzQ2MTc1NzI2MTZlNzQ2NTJlNjM2ZjZkMmU2Mjcy
X-LocaWeb-COR: locaweb_2009_x-mail
X-AuthUser: regis@baladamixrestaurante.com.br
Received: from [177.126.159.149.voatelecom.net.br] (177.126.159.149.voatelecom.net.br [177.126.159.149])
(Authenticated sender: regis@baladamixrestaurante.com.br)
by proxy.email-ssl.com.br (Postfix) with ESMTPSA id 28A0C1A003FC
for <user@example.com>; Tue, 19 Feb 2019 16:15:46 -0300 (-03)
X-Mailer: Webgalamb 5.3
To: user@example.com
Date: Tue, 19 Feb 2019 20:15:46 +0100
X-Priority: Critical
Subject: user
Message-ID:
<0657561161.4918.9126166.JavaMail.app@w3qupob-app31053.baladamixrestaurante.com.br>
X-Sender-Info: regis@baladamixrestaurante.com.br
List-Subscribe:
<http://baladamixrestaurante.com.br/mailman/listinfo/baladamixrestaurante.com.br>,
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8
Feedback-ID: 07405370 cqcvtthh dud n List(72115):255306:cmyxhk
X-aid: 1886549600
X-Abuse-Reports-To: <abuse@mail.baladamixrestaurante.com.br>
From: <user@example.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120615
Thunderbird/13.0.1
X-CSA-Complaints: whitelist-complaints@baladamixrestaurante.com.brTo clarify: is example.com hosted by example.co.uk?
Quick sanity checks
- Are you confident a mail user agent e.g. Thunderbird is not intervening by moving messages from Spam Folder back to Inbox?
- Do you have any sieve filters that may move mails from yourself back to Inbox?
Assuming no to the above, then there appear to be two separate issues
- Message flagged as spam not getting sent to Spam Folder
- SPF/DKIM not rejecting this message since it was not sent from an “authorized server”
Lets tackle them one at a time…can you try sending a spam email to a user at each domain (example.co.uk and example.com)? To do this, send a message with the following plain text content (subject line is irrelevant) to a user at each domain
XJSC4JDBQADN1.NSBN32IDNENGTUBE-STANDARD-ANTI-UBE-TEST-EMAILC.34X
This is a predefined / agreed-upon test string that all spam filters should catch (SpamAssassin gives this a score of 1000!).
1 Like
You system (for domain hichris.com is not setup to reject mails that fail SPF checks. You have
v=DMARC1; p=quarantine
This means your policy is not to reject but rather to accept such mails and quarantine them. I assume you would then need some sort of filter to put these messages into a quarantined folder somewhere.
I notice that mine does too (hosted at Linode)…is this a default setting from within MiaB or somewhere else (DNS provider, maybe)?
@brschroeder note that the site formatting modified the spam string. The correct one is here: https://en.wikipedia.org/wiki/GTUBE#Contents
I tested sending this (the spam string) from one of my other MIAB’s (box.givingtools.com) to my personal one (box.neonorb.com) and the email goes straight to my inbox. No filters setup in Thunderbird:
p=quarantine is set by MIAB, perhapse this should be changed to p=reject? Kinda odd that it detects an illegal sender but “quarantines” it rather than rejecting it?
Last I checked Mail In A Box does not properly check the SPF state of incoming mails.
If DMARC is working properly mails will be passed provided either DKIM is passed or SPF is passed (assuming the domains used for the two checks align with the domain in the From: address.
I think @JoshData decided to do this to be on the cautious side, as SPF is known to break when mail passes through mail forwarders. Personally I would like to see SPF checked properly on incoming mail as well. I’m going to see if I can add openspf to my box, But I am very much an amateur in this regard.
I think it’s time to try adding it, but we should use DMARC and not SPF. I don’t think anyone is really implementing SPF alone anymore. DMARC is used instead.
I actually agree with you there Josh. However you do also need to be aware how SPF works in the absence of a sender address. (e.g. for NDR’s)
In such a circumstance the EHLO identity is used e.g. box.example.com and the SPF example does recommend setting up a separate SPF record to specifically cover this.
DMARC uses the results of SPF and DKIM so I’m presuming it’s a similar application where an SPF Milter is applied to the postfix config to get the authentication results in the first place.
Tim
Is it the case that DKIM, SPF and DMARC on our DNS tell others how to behave and not how MIAB should behave?
Is it the case that MIAB would reject failing messages that come from other domains not matching their policy ?
Is it the case that MIAB would reject failing messages from its own domains not matching the domain’s policy?
I have a customer complaining about spam coming to their mailbox, spoofing their own mailbox. The mail message claims to have hacked their mailbox and is demanding bitcoin, so as its from them to themselves then clearly someone has hacked their account - right? 
It seems like at the moment Dmarc and SPF don’t work. This lets anyone spoof us and send us mail to our users! Not good. From what I can tell quarantine doesn’t even do anything.
I did an email test on https://mxtoolbox.com/deliverability/ and SPF Authenticated failed, anyone know why this is failing and what I can do to make it succeed. I tried searching but couldn’t find anything that could help me. I am using an external DNS and copied everything from the status page.
My SPF record: v=spf1 mx -all
@Glennmen You may get a better response by creating a new topic. Also, it may be difficult to troubleshoot your issue without more information, such as the domain of email as well as the domain of the MiaB server.
I have to agree … this is a topic about incoming mail and you seem to be talking about outgoing mail … please create a new topic and include your MiaB hostname, and the domain of the user that you are sending the test with.
I did a try with my email hosted on the last version of MIAB and I received 4 of spoofed emails…
How can I do to improve this ?