Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Desperately need some help here. I've been using Google Apps for my domain (2qubed.co.uk) for over 2 years now with no problems at all until recently.

For the past few months I have been getting lots of bounced emails from my domain that i never even sent from non-existent email addresses I haven't even created. I'm sure Google is suppose to pick this up as spam but for some reason it is not. I get at least over 50 of these emails every day. I don't whether my account has been hacked in anyway??

This is an example of a typical email i get:

from Mail Delivery Subsystem to aypyvagef9461@2qubed.co.uk date 12 November 2010 10:35 subject Delivery Status Notification (Failure) mailed-by mail-yw0-f66.google.com hide details 10:35 (31 minutes ago) Delivery to the following recipient failed permanently:

174224736.79436842626079@fsumsg6.ferris.edu

Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.1.1 <174224736.79436842626079@fsuimail.ferris.edu>: Recipient address rejected: User unknown in relay recipient table (state 14).

----- Original message -----

Received: by 10.90.57.3 with SMTP id f3mr2950105aga.120.1289558131998; Fri, 12 Nov 2010 02:35:31 -0800 (PST) Received: by 10.90.57.3 with SMTP id f3mr2950104aga.120.1289558131975; Fri, 12 Nov 2010 02:35:31 -0800 (PST) Return-Path: Received: from [77.126.207.119] ([77.126.209.114]) by mx.google.com with ESMTP id r45si7415460yhc.84.2010.11.12.02.35.30; Fri, 12 Nov 2010 02:35:31 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning aypyvagef9461@2qubed.co.uk does not designate 77.126.209.114 as permitted sender) client-ip=77.126.209.114; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning aypyvagef9461@2qubed.co.uk does not designate 77.126.209.114 as permitted sender) smtp.mail=aypyvagef9461@2qubed.co.uk Received: from alt1.aspmx.l.google.com (localhost [127.0.0.1]) by alt1.aspmx.l.google.com (8.14.4/8.14.4) with SMTP id 04df6C1c8059Dd for <174224736.79436842626079@fsuimail.ferris.edu>; Fri, 12 Nov 2010 12:35:28 +0200 (envelope-from aypyvagef9461@2qubed.co.uk) Message-Id: <201011121235.dBB78231005f63@[77.126.207.119]> Subject: Hi 174224736.79436842626079, Sale-Over Reminder. throughout Date: Fri, 12 Nov 2010 12:35:28 +0200 Mime-Version: 1.0 From: "Pfizer PillsTrader" To: 174224736.79436842626079@fsuimail.ferris.edu Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit

----- End of message -----

I've been researching and read about SPF records and have added one which is: "v=spf1 include:_spf.google.com ~all"

but this doesn't seem to have made any difference. Is it correct? I've also changed the Google apps password and my email password but this hasn't helped.

Anybody please have any ideas?

Also I wondered in Google apps should I have a seperate account for the administrator and the users? At the moment I have just one account which is for my emails and it is the administrator.

Thanks

share|improve this question

3 Answers 3

I don't think there is much you can do. What is happening is this:

Somebody is connecting to Google's MX servers and delivering Spam addressed to a Google Apps domain with a forged envelope From address using your domain. Since your domain is also hosted with Google Apps, you end up getting the bounce.

What I don't understand is why the heck Google is doing accept-then-bounce. They should be giving the Spammer a 5XX hard error instead. Maybe there is some forwarding going on?

Your SPF records make the forgery obvious, but even with a hardfail, Google will still accept the mail.

Even if you disable your catch all, this can still happen if somebody forges a valid envelope From address.

Google is still going to deliver Blowback/Backscatter to you, but anybody else not doing accept-then-bounce should hopefully just reject the mail without accepting it when the SPF indicates forgery.

If your account activity report is not showing anything suspicious, your account has not been hacked.

share|improve this answer

I have found that some spammers like to use a "from" address where the from domain is configured with a catch-all email address - perhaps it speeds up their spamming? I'm not sure if that's what's going on in your case, but you might want to try disabling the catchall address if possible for a day or so.

Are all the messages using the same from: address, or are they all different? If they're the same, you might be able to set up an account for that address - that way you won't have to deal with them.

share|improve this answer
    
I do have catch-all set up to deliver to my address, so that's why i'm getting these. But if I set to discard them then I'll lose other ones like info@ etc. The catch-all is worth having. Also the catch-all has always been there, this is only started happening recently. –  hems77 Nov 12 '10 at 13:34
    
Well, you can set up aliases for the ones you use - I found that disabling the catch-all for 24-48 hours was usually all it took. –  chris Nov 12 '10 at 23:56
    
I don't see how the domain in the forged envelope From being configured with a catch all speeds up a spam run. –  Mark Johnson Dec 25 '12 at 5:03

An spf record that ends

~all

is essentially useless in preventing joe-jobbing, because it tells the remote system that you (the domain controller) don't know what it should do with the email (which doesn't come from your approved systems), and it is therefore likely to accept it.

Once you are confident with your SPF setup, you should change the

~all

to

-all

which is much more positive statement; that says to a recipient who consults the SPF that an email which is not from your list of approved systems is not from you at all, and should be refused. From the output you've pasted above, it looks as if the recipient in this case is checking the SPF, so at that point they should refuse the email at SMTP RCPT TO: stage, and the annoying bounce message will never be generated.

share|improve this answer
    
I'll give that a try. Thanks. –  hems77 Nov 12 '10 at 11:38
    
I changed this SPF record yesterday as suggested but doesn't seemed to have made much difference. Overnight and this morning I have still got bounced emails from random non-existent emails. How do I know if my SPF is correct? I just went by what google say on their google apps help pages. I wonder if it's to do with SPF at all or something else? I never had an SPF record in my DNS before. Or could it be the catch-all? Again ive had this from day one too?? Very frustrating!!! Any ideas??? –  hems77 Nov 15 '10 at 9:58
    
SPF isn't going to do anything in this case - ferris.edu is hosted with Google Apps and Google does not refuse mail based on SPF failures, even hardfail. Why Google is doing-accept-then-bounce on an unknown user instead of just rejecting with a 5XX is the real question here. –  Mark Johnson Dec 25 '12 at 4:58
    
Mark, it's interesting to know that google doesn't use SPF to filter incoming mail, but I'm not sure it's relevant in this case. ferris.edu may well be hosted by gmail, but it's everyone else - all the people who are getting the original joe-jobbed emails - whose SPF filtering choices are of interest. –  MadHatter Aug 3 at 7:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.