Wildcard configured emails allow spammers to deliver mail? (SPF: "softfail")

Question

I have a Google Apps account set up for one of my domains. Wildcard email delivery is enabled on this domain for all emails (ie. [email protected] passes emails along to [email protected]), and the records related to email delivery are configured as follows (to the best of my knowledge, configured to Google's recommendations):

MX: ASPMX.L.GOOGLE.COM with priority 10
TXT: v=spf1 include:_spf.google.com ~all
TXT: v=DKIM1; k=rsa; p=xxxxxxxxxxxxxxxxxxxxxxxxx

Recently, however, I have begun to receive an increased number of bounces/"out of office" emails from people who are apparently being spammed with people using email addresses from my domain. From the bounces, some headers:

Return-Path: <[email protected]>
Received-SPF: softfail (google.com: domain of transitioning 
    [email protected] does not designate 41.230.231.130
    as permitted sender) client-ip=41.230.231.130;
Authentication-Results: gmr-mx.google.com; spf=softfail (google.com:
    domain of transitioning [email protected] does not designate
    41.230.231.130 as permitted sender) [email protected]
From: "Secure.Message" <[email protected]>
To: <[email protected]>

(I can provide additional headers if needed.)

I looked into softfails but am not completely sure I understand it. I do wildcard emails to the domain so simply disabling wildcarding would probably not be a solution. Because emails to this domain are then forwarded on to a different email address (also within Google Apps, though), I would preferably also need to be able to send emails using Google's "send email as" ("on behalf of") feature.

Any ideas what to do now? Most importantly I am concerned about the reputation of my domain; I would very much want to keep it off of any spam lists.

score 5 · Accepted Answer · answered Jan 12 '13 at 01:57

5

When you use the SoftFail qualifier (the ~) in an SPF mechanism, you indicate that a matching sender should be treated with suspicion, but not outright rejected.

The Fail qualifier (the -) on the other hand, encourages receiving MTAs to reject the SMTP transfer immediately with a 5.1.7 DSN.

So when you are using ~all in the end of your record, you are only partially preventing spammers from abusing your domain and your reputation.

Read more about how check_host() results should be treated according to the RFC Specification here: IETF RFC 4408 §2.5 "Interpreting the results"

answered Jan 12 '13 at 01:57

Mathias R. Jessen

25,161
4
63
95

In other words, would it be recommended for me to change the qualifier to the "fail" qualifier? – Brandon Wang Jan 12 '13 at 04:26
I would definitely say so, yes! – Mathias R. Jessen Jan 12 '13 at 04:32
It's interesting that Google makes no recommendation to use Fail as opposed to SoftFail in their documentation... do they not see this as a problem? – Brandon Wang Jan 13 '13 at 16:33
I think they keep the discussion within http://www.maawg.org/ in collaboration with other interest groups as opposed to having a "google-way" of doing things – Mathias R. Jessen Jan 13 '13 at 16:35
I completely understand... it's the language that Google uses: "Publishing an SPF record that uses -all instead of ~all may result in delivery problems." – Brandon Wang Jan 13 '13 at 16:37

score 4 · Answer 2 · answered Jan 12 '13 at 02:22

In addition to what Mathias said (which is good), note that key word encourages in his second sentense: "The Fail qualifier... encourages receiving MTAs to reject the email".

I would also recommend looking into DMARC. Once you have SPF and DKIM records in place, which it sounds like you do, DMARC is a way for you to tell receiving mail servers what to do with email that fails both the SPF and DKIM test.

When an email fails those tests, AND a receiving MTA honors DMARC records, then you can control what they do with that email: Reject it outright, mark it as a spam, or deliver it.

score 0 · Answer 3 · answered Jan 12 '13 at 02:26

0

I am in the exact same situation, and changed my SPF records to perform a hard fail. It doesn't help. The administrators of the domains that send the bouncebacks seem to look at the spf record, see that it fails, and then ignore it. I am not worried about my domain reputation, since they are going to continue to send these emails whether or not I am here to see the bouncebacks. There is nothing you can do but make a rule to ignore the pattern of the reply to address.

answered Jan 12 '13 at 02:26

Edwin

1,041
7
17

... Actually, there is. See my answer for how to implement DKIM and DMARC records. Not every mail server honors DMARC, but for the ones that do, this makes a big difference. I was successfully able to greatly reduce the amount of phishing emails our employees AND business points-of-contacts were receiving "from" our domain. – David W Jan 12 '13 at 03:32
Thanks, I will definately look more into it. I sign all my outgoing messages with DKIM, and I use SPF, of course. I'm still reluctant to say that it will work, though. Researching some of the domains that I get bounce backs from leads me to believe that they will not honor DMARC. Always looking to tighten up though. I'll give it a go on my personal domain tonight. – Edwin Jan 12 '13 at 04:24
I've implemented DMARC and configured it to drop emails that do not pass the test. I set it up to request DMARC reports. So far, I have not seen a reduction of the kind of emails described in the question. I received four DMARC reports so far, two each from Google and Yahoo. I would recommend DMARC, but it is not helping in this particular situation. – Edwin Jan 14 '13 at 07:01

Wildcard configured emails allow spammers to deliver mail? (SPF: "softfail")

3 Answers3

Linked